FlClash Troubleshooting
Connections, Subscriptions & DNS

No Internet Access: Find Where the Problem Starts

“The client is running” only means the local service may have started. It doesn’t confirm that your subscription, remote connection, or system routing is working. Pick one site that normally works without a proxy and one service that requires one. Test both in the same browser and note the exact error: DNS lookup failure, connection refused, certificate error, or timeout. Don’t assume the entire network is down just because one page won’t load; the service could be down, your session may have expired, or access may be restricted by region.

Disable Traffic Routing and Check Your Network

Pause FlClash, turn off the system proxy and TUN, then confirm the system proxy settings have actually been restored. If your browser still points to a local port after you exit, clear the leftover proxy setting—otherwise, this isn’t a direct-connection test. Try a trusted network and a regular website; if needed, compare results using a phone hotspot. If direct access still fails, check Wi-Fi authentication, your router, cables, or ISP connection first. On hotel or campus networks, complete the captive portal sign-in before testing.

If direct access fails on just one device, check its system clock, network adapter, and security software alerts. If every device on the same network fails, the problem is more likely upstream. Reimporting the subscription repeatedly won’t usually help. Once the basic connection is back, start FlClash and retest the same site so a different test target doesn’t skew the result. Existing browser connections may keep using their old state, so start a fresh request when testing.

Check the Active Configuration and Proxy

Open the configuration page and confirm the successfully imported profile is selected as the active configuration. A file appearing in the list doesn’t mean the core is using it. On the proxy page, check that the policy groups used by your rules have available proxies. If selecting one manually, don’t leave a failed option selected. Test in rule mode first, then briefly switch to global mode for comparison. If global mode works but rule mode doesn’t, check rule matching and policy groups. If both fail, investigate the remote connection and local port.

Direct mode sends requests without a proxy; it isn’t a more reliable way to connect. Switch modes only to isolate the issue, then return to your usual rule mode. If the logs show a missing policy, configuration parse error, or failed port listener, address that specific error first. The interface may still show details from an older configuration after a load failure, so don’t rely on the profile name alone. Restart the core, check the latest startup log, and confirm it loaded the expected configuration.

Use an Explicit Proxy to Isolate System Routing

Run the request below in a desktop terminal. This example assumes the default mixed port, 7890; if you changed it, use the port shown in the client. On Windows, use curl.exe instead of curl to avoid aliases in some terminals. The command specifies the local proxy directly, without relying on the browser’s system proxy settings. It tests this request only—it doesn’t prove that all apps are routed through the proxy.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

If it can’t connect to the local port, check whether the core is running, the port matches, and another process hasn’t claimed it. If the proxy connects but the request times out afterward, check the outbound proxy or DNS. If the command gets a response but the browser still fails, check browser extensions, built-in proxy settings, and the system proxy. A response doesn’t have to be a successful web page: a service returning “access denied” still shows that part of the connection worked. Check the response rather than treating every non-success status as a network outage.

Choose the Next Step Based on Your Results

Keep these comparison results and go to the relevant section. After recovery, test a direct-connection site, a proxy-only service, and the app that originally failed. Make sure the pages aren’t loading solely from cache. If you can’t narrow it down, check the FAQ for basic concepts. Don’t enable every traffic-routing option just to make the interface look right; the smallest set of necessary settings is easier to maintain.

Node Timeouts: Distinguish an Unreachable Server from a Failed Handshake

A timeout means a step didn’t finish within the allotted time; it doesn’t tell you why. The subscription may contain an outdated server address, or DNS resolution, the transport handshake, or the target service may be stuck. Note the active outbound proxy, network, and test target, then check the logs for the same time. If the client only reports “timeout,” expand the surrounding log lines to see whether it stalled during name resolution, dialing, or after starting a secure connection. Then decide whether you need to change the outbound proxy.

Check Subscription Status and System Time

Check the provider’s account page to confirm your service is active, you have quota remaining, and the connection details haven’t recently changed. A successful subscription update only means the content was downloaded; it doesn’t mean every listed server is reachable. After updating the subscription, confirm the active profile refreshed and check whether the original policy group still selects an outdated entry. Avoid repeatedly deleting and recreating profiles—you could lose useful rules, manual selections, and overrides that help with comparisons.

Enable automatic date and time in your operating system, then check the time zone and displayed time. Secure connections rely on certificate validity checks. If your device clock is significantly off, the handshake may fail or the interface may report a generic connection error. Once the time is corrected, reconnect; there’s no need to reinstall the client. If logs mention a certificate name or chain issue, check the subscription parameters and whether the network is intercepting authentication. Don’t disable certificate verification to hide the underlying risk.

Compare One Outbound, the Whole Group, and Another Network

On the same network and with the same test target, select a different outbound proxy and change nothing else. If one fails while the others work, check that server. If they all fail, the issue could be with your local network, the subscription as a whole, or public DNS. Repeat the test using a trusted phone hotspot. If the hotspot works but the original network doesn’t, the problem is more likely related to that network’s policies, routing, or upstream restrictions—but one test alone can’t identify exactly how traffic is blocked.

Don’t rely only on the built-in test button to decide whether a service works. Its test URL and timeout may differ from the actual service you’re using. A successful test also doesn’t guarantee that an app’s login API or live connection works. Try the real target in a browser or with an explicit proxy request. If only one site fails, check whether a direct-connection rule matched it first or the service restricts your current exit location. Don’t keep troubleshooting it as if all proxy nodes were unreachable.

Follow the Connection Stage Shown in the Logs

For errors such as no such host or a DNS timeout, check resolution of the proxy server’s domain first. connection refused usually means the destination address or an intermediary actively rejected the request; check the server port and service status. A timeout may indicate an unreachable route or an unresponsive peer. Error text is a clue, not a substitute for the full context. Don’t confuse a target website refusing access with the proxy server refusing a connection.

If the logs clearly show a handshake failure, check the protocol, transport, server name, and any additional subscription parameters. Some conversion services may drop protocol-specific fields, and manual edits can introduce indentation or type errors. Restore the provider’s original configuration intended for mihomo and test again. Don’t change the server name, fingerprint, or transport parameters based on an unrelated guide; these fields must match the server configuration, and random alternatives won’t make the connection work.

Rule Out Local Blocking and Keep a Reproducible Record

Check whether your firewall or endpoint security software started blocking the client or core after an update. Review its block logs and add a necessary rule for the program path rather than disabling all protection. Company-managed devices may have centrally enforced policies that standard users can’t change; follow your organization’s network rules. If another VPN is running, disconnect it and retry to avoid competition over the default route or virtual adapters. Run only one proxy core during testing.

Record three comparisons: “original network vs. hotspot,” “one outbound vs. several,” and “test URL vs. actual service.” These results usually point to the right team to contact. For a step-by-step checklist, see the Node Timeout Troubleshooting Notes. If every server fails on multiple networks while your basic connection works, contact your subscription provider instead of masking an unreachable server by increasing the timeout.

Subscription Issues: Separate Download, Parsing, and Activation

Importing a subscription involves three steps: the client downloads the remote content, the core parses the configuration, and you select and activate it. Each failure needs a different fix. “Download failed” points to the network or URL; a “parse error” means you should check the response and format; “no proxies after import” calls for a look at the configuration structure and active selection. Keep the full error message instead of noting only a failure icon. Identifying the failing step helps you avoid repeating import methods that won’t work.

Check Whether the URL Returns the Right Content

Copy the full subscription URL from your provider. Messaging apps may insert line breaks, drop trailing parameters, or include surrounding instructions. Remove spaces at the start and end, but don’t delete query parameters. If you have a web sharing link instead of a subscription URL, the client may download a login page. Opening a page in your browser doesn’t prove the client received a proxy configuration. Check whether the provider requires a login, specific request headers, or a dedicated subscription URL.

Use the response to narrow down the cause. Unauthorized or forbidden responses usually involve credentials, account status, or access policies. A missing resource may mean the link has expired. If requests are being rate-limited, stop refreshing and wait for the provider to restore access. A network timeout is different from these responses; don’t label every failure a password problem. Some subscription domains require an existing proxy to access. You can use a still-working profile to update once, but don’t make subscription downloads that depend on that same proxy your only way to get started.

Check the Format After Downloading

A complete configuration for mihomo is usually YAML, but not every text file containing proxy addresses can be used as a configuration. Some URLs return another client’s format, an encoded list of links, or an error page. The download can succeed while parsing fails. Use an endpoint the provider explicitly identifies as compatible with Clash or mihomo. The client may support multiple import methods; check the current interface and core capabilities to confirm which formats work.

If the error includes a line and column number, check indentation, colons, list markers, and field types around that location. YAML indentation uses spaces, not tabs; full-width punctuation can’t replace syntax characters. The example below shows only the structure of a rules section, not a complete subscription. It depends on a Proxy policy group that already exists in the configuration. Importing this fragment on its own won’t create working outbound proxies.

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

Configuration Imported but Not Activated

Return to the configuration list and confirm the imported profile opens, then select it as the active configuration. If you imported a local file, updating a remote subscription later may not change that file. Check whether you’re using a linked profile, a file copy, or a configuration with overrides. Start the connection and check the latest logs for parse errors. A timestamp in the list only reflects an operation; it doesn’t prove that the running core switched to the new content.

If the profile activates but the proxy page is empty, check whether it contains proxy entries or proxy providers, and whether the policy groups reference them. Some configurations load outbound proxies from remote providers, so the main file can download successfully while a secondary resource fails. That can leave groups empty if the secondary resource has a domain, permission, or format issue. Check the logs for the provider name and update error instead of only refreshing the main subscription. Redact provider names and download URLs before sharing logs.

Avoid Update Overwrites and Duplicate Rules

For local settings you need to keep, use the client’s override mechanism where possible instead of editing content that a subscription update will replace. Overrides can also cause conflicts: duplicate rules, references to missing policy groups, or fields replaced with the wrong type. To troubleshoot, disable custom overrides and test the original subscription first. If it works, restore overrides one at a time. Don’t change both the subscription conversion service and override file at once, or it’ll be hard to tell which layer altered the configuration.

After recovery, run a manual update to confirm the configuration reloads and your rules and outbound selections still work as expected. If only automatic updates fail, check background execution requirements and the network path used for downloads. Subscriptions may contain private domains and authentication data; don’t upload them to public online parsers. For initial setup, see Importing a Subscription and Setting Up a Connection. If traffic routing doesn’t behave as expected, check the Rules Matching Order Guide.

Slow Speeds & Disconnects: Separate Bandwidth, Routing, and Service Limits

Break “slow” down into observable symptoms: pages take a long time to open, downloads stay slow, video buffers frequently, or the connection drops after running for a while. Each may have a different bottleneck. Repeat the test on the same device, network, and target, and pause system updates, cloud syncing, and other high-bandwidth tasks. Don’t compare download results from different sites or use a built-in connection test as a substitute for the actual app experience.

Compare Direct and Proxy Connections Under the Same Conditions

First test a reliable site that allows direct access to confirm that Wi-Fi and your basic connection are stable. Then test a target that requires a proxy. If direct access is also slow, check router load, wireless interference, and upstream bandwidth first; try a wired connection or move closer to the access point. If only the proxy is slow, compare another outbound in the same group. Observe the connection over time so short-lived congestion or a cached page doesn’t look like a real improvement. Don’t change networks while switching outbounds.

Different test targets may be in different regions or use different content delivery networks, so their results will naturally vary. A fast large-file download doesn’t prove that a live meeting or game will have a stable connection. For frequent disconnects, note whether they occur after the screen locks, the network changes, the device sleeps, or a consistent period of inactivity. If the issue follows the same system event, look at background policies, virtual adapters, and connection recovery rather than remote bandwidth.

Check the Rule That Matched and the Exit Used

In the connection records or logs, find the rule, policy group, and final outbound used for the target domain. A browser homepage and video assets may load from different domains, so a fast homepage and slow playback don’t necessarily point to the same connection. Rules are evaluated in order; a broad rule earlier in the list may prevent a later, more specific rule from running. Create a new connection to test any change. Existing connections usually won’t move to a different outbound automatically when rules change.

An automatic selection group may choose a poor exit if its probe target differs from the service you’re using. Temporarily pin one outbound manually and see whether the issue goes away before changing the probe strategy. The target service may also throttle your account or limit access based on exit region or concurrent connections; adding a local port or changing an interface setting won’t fix that. If just one service is slow, compare its different resources and clients instead of adding lots of exceptions to the entire configuration.

Understand Protocols, Packet Loss, and Network Changes

Slow sustained downloads can be caused by remote server load, a congested route, or packet loss. A slow first request may also involve DNS, the handshake, or connection reuse. Mobile and public Wi-Fi performance can vary by time of day. Don’t turn on every protocol, connection reuse, or transport option at once; settings must match what the server supports. For UDP traffic, confirm the outbound and routing path support it. A working HTTP proxy doesn’t mean every UDP application uses the same path.

If websites work but some apps stall, compare system proxy and TUN while keeping all other conditions the same. If only TUN fails, check routing, DNS, and virtual adapters rather than immediately changing the remote proxy. An unsuitable MTU can stall some requests, but test it only when you have clear evidence, such as fragmentation or a path issue. Record the original value, change one thing at a time, and keep a rollback plan. Lowering the MTU at random is not a general speed fix.

Use Logs Briefly; Avoid Long, High-Load Diagnostics

To trace a specific request, temporarily increase log detail, reproduce the issue once, and then restore your usual level. Verbose logging, repeatedly probing every outbound, and running several clients at once can all burden your device and skew comparisons. When checking system resources, compare changes before and after the issue and identify the relevant process; memory use alone doesn’t prove a leak. Record whether the client slows down gradually over time or is slow from startup.

Once you’ve confirmed the improvement, restore normal logging, stop repeated tests, and check your usual apps. If the issue only happens during busy hours, sharing the time and network conditions helps your provider investigate more than a screenshot labeled “slow.” If you can’t reproduce it reliably, collect the conditions first. Repeatedly changing settings just to get an immediate answer may break a route that was working.

DNS Issues: Check Resolution Paths and Domain Rules

DNS issues often show up as some sites failing to open, a long wait on the first visit, or a “host not found” error in the logs. First distinguish three domains: the subscription download host, the proxy server host, and the target website. They may use different DNS paths. A successful lookup for the target website doesn’t prove the proxy server’s domain can be resolved. Identify which domain is involved and check that request instead of replacing every resolver at once.

Separate System DNS from Core DNS

Your operating system, browser, and mihomo may each use different DNS settings. A successful system lookup only confirms that query path works. A browser with Secure DNS enabled may bypass system resolution, while TUN DNS interception may route requests to the core. Before troubleshooting, note the current settings for browser Secure DNS, system DNS, core DNS, and TUN. Temporarily use a consistent, easy-to-understand test path, then restore the settings you need.

The commands below compare the system resolver with an explicitly selected one. They aren’t a recommendation to permanently use a particular public DNS on every network. If the second command fails, your current network may block direct DNS requests. Windows, macOS, and most Linux systems support nslookup. If a minimal system doesn’t include it, use an available system diagnostic tool instead of downloading an executable from an unknown source just to test DNS.

nslookup example.com
nslookup example.com 1.1.1.1

Check Encrypted DNS and Startup Dependencies

If the address for an encrypted DNS service is a domain name, you may still need a basic lookup before connecting to it. A proxy server can also use a domain name. If its lookup is forced through a proxy that hasn’t connected yet, you can end up with a dependency loop. This often causes timeouts during startup, while connections may occasionally work when a cached address is available. Check that the configuration has a suitable bootstrap resolver and a DNS path for proxy server domains. Avoid relying entirely on an outbound connection that hasn’t been established yet.

This partial DNS configuration example shows how ordinary lookups and proxy server domain lookups can use separate resolvers; it isn’t a complete configuration for every network. Before merging it, check whether the original file already has a dns field—don’t paste in a duplicate at the same level. Encrypted DNS also requires network access to the selected service. If the core reports an unsupported field after import, restore the original configuration and check the actual core capabilities. Don’t ignore a load failure and keep testing.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

Understand fake-ip and App Compatibility

With fake-ip, the core returns a mapped address so it can identify the original domain on later connections. This isn’t the target website’s real public IP, and it doesn’t mean DNS is broken. An app may fail if it gets a mapped address and then bypasses the core for a direct connection, or passes that address to another device. First confirm the traffic follows the same routing path end to end. Only then consider a filter rule for a specific incompatible domain; don’t add every domain to an exception list.

After changing DNS mode, networks, or traffic routing, your system or browser may still have an old address cached. Close the affected app and make a fresh request. If necessary, clear the DNS cache using your operating system’s method. On Windows, you can use ipconfig /flushdns when appropriate. Commands differ on other systems depending on the resolver. Clearing the cache won’t fix an upstream error. If you have to do it every time to get brief access, keep checking whether address mapping and traffic routing are consistent.

Distinguish DNS Problems from Geo Rules Not Matching

GEOSITE mainly classifies domains, while GEOIP classifies IP addresses using a database; they aren’t the same kind of DNS feature. A domain can resolve correctly but still use the wrong outbound because a database is missing, the category name is wrong, or an earlier rule matched first. Check the actual matched rule in the connection records, and review database loading and update logs. The fallback policy at the end of the rules must also exist, or requests that match none of the preceding rules may still fail.

After fixing the issue, test the proxy server domain, target domain, and app that originally failed. Also check the first connection after a restart. For database updates and category troubleshooting, see the GeoIP and GeoSite Update Guide. If DNS only fails on a particular network, document its restrictions rather than applying a temporary test configuration to every device.

System Proxy Not Working: Check Whether the App Reaches the Core

A system proxy usually provides an HTTP proxy endpoint to apps that read the system settings; it doesn’t force all traffic through the proxy. Some terminals, games, services, and apps with their own network stack won’t use it. TUN routes more traffic through a virtual network interface, but depends on permissions, drivers, and routing. First use an explicit proxy request to confirm the local core works, then check whether the app honors the system proxy. This avoids mistaking differences in routing coverage for a client startup failure.

Check the Listening Address, Port, and Conflicts

Check the mixed port in FlClash and compare it exactly with the proxy port entered in the app. Local apps usually use 127.0.0.1, which refers to this device—not a computer on your local network. The default port doesn’t guarantee that the listener started; another client or background process may already be using it. Use the commands below to check listening processes. On Windows, run the first command in a terminal; on macOS or Linux with the relevant tool installed, run the second.

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN

Make sure the process ID in the results belongs to the expected program. Don’t terminate an unknown process just because it’s using the port; first confirm its name and purpose. A system service or another user’s process may have a legitimate task. Try quitting other proxy clients and restarting FlClash, or change the port and update the app settings to match. The mixed port accepts both HTTP and SOCKS5 requests, but that doesn’t tell every app on your system where to connect.

Check the App’s Proxy and Bypass Settings

Browser proxy extensions, developer tools, download managers, and command-line environment variables can override system settings. Temporarily disable the relevant extension or restore the app’s “use system proxy” setting, then restart the app and test again. Proxy environment variables set in a terminal won’t disappear when you close the client. Different terminal sessions may inherit different values, so if one window works and another doesn’t, compare their environments before changing the core configuration.

With a SOCKS5 proxy, check whether the app resolves domain names locally or through the proxy. In an environment with curl, use the syntax below to resolve the domain through the proxy and compare it with the local DNS path. Don’t assume that changing an HTTP proxy URL prefix to SOCKS makes the behavior identical. System or app bypass lists may also send local domains or specific addresses directly; note those exceptions before troubleshooting.

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

TUN Is On, but the App Still Isn’t Routed

Check the core startup logs for permission errors, virtual interface creation failures, or failed route updates. On platforms that need administrator privileges or a helper service, grant access as prompted by the client; don’t rely on the toggle’s appearance alone. If you recently upgraded or moved the program, check whether the service still points to the right path. Another VPN, virtual machine network, or corporate security tool may also change routing. Disable conflicting components for comparison—more routing tools don’t automatically mean better coverage.

If the browser works through the system proxy but not through TUN, check TUN routing and DNS interception. If only TUN works, the app probably ignores the system proxy. Some Windows Store apps may be affected by loopback isolation, which can restrict access to the local proxy. Check the specific app and system prompt for loopback permissions; don’t disable isolation for every app. Testing with an ordinary browser can help narrow down whether the local endpoint works.

Local Network Sharing and Restoring Settings on Exit

When a phone connects to a computer’s proxy, enter the computer’s current local network address and mixed port on the phone—not the phone’s own loopback address. Enable LAN connections on the computer, and allow the required port through the firewall only on trusted networks. Guest Wi-Fi or access point isolation may prevent devices from communicating. Even if both devices show the same Wi-Fi name, they may not be able to reach each other. Check the computer’s address again after switching networks.

For detailed steps, see the Mixed Port and LAN Connections Guide. Turn off traffic routing before exiting the client. If the network fails after an unexpected exit, check whether the system proxy still points to the now-closed local port, then check virtual adapters and routes. Once the network is restored, verify connectivity both while the client is running and after it exits. Your connection shouldn’t depend on leaving the app open.

Client Crashes: Separate UI, Core, and Configuration Issues

A startup failure can mean at least three different things: the app window never appears, the interface opens and immediately closes, or the interface stays open while the core keeps stopping. Each points to a different layer. Note the installer source, processor architecture, operating system, and recent changes—including client updates, imported configurations, moved folders, and security policy changes. Don’t clear app data before making a backup; configuration and logs from a crash are often the most useful clues.

Check the Installer and Runtime Environment First

Choose a client from the Downloads page that matches your operating system and processor architecture. Don’t rely only on whether the filename mentions your platform. For macOS, distinguish Apple Silicon from Intel; for Android, match the device ABI; and for Linux, consider your distribution’s package manager. An architecture mismatch can prevent installation or cause issues when the app runs through a compatibility layer. If the problem started after an OS upgrade, check client compatibility with the current environment first.

Check whether the installation, configuration, and temporary directories are writable and whether there’s enough disk space. A read-only location, network share, or restricted folder can prevent files from being written. If security software quarantined a component, review the specific alert and source before restoring or reinstalling it; don’t disable all system protection. Company-managed devices may prohibit virtual adapters or background services, in which case the restriction needs to be addressed through the management policy.

Determine Whether the Window or the Core Exited

If the interface is still open but the connection has stopped, check the core log for configuration errors, port conflicts, or startup permission errors. A bad imported profile stopping the core doesn’t mean the entire app is broken. Disable automatic connections and try starting with a previously working profile. If the window itself disappears, check system app crash reports and client logs. Match the timestamps so you don’t mistake an older error for the cause of this crash.

On Windows, check Application Error entries in Event Viewer. On macOS, look for the relevant crash report in Console. On Linux, check the startup output and user logs for the desktop environment or service manager that launched the app. Log locations vary by installation method, so use the client’s own log access where available. When reporting the issue, include context around the error rather than your entire user directory. Logs may contain domains, paths, and subscription details; redact them first.

Test a Copy of the Configuration and Data Directory

Export or copy your current configuration, subscription details, and necessary settings before trying to disable recently added overrides, rule providers, or scheduled tasks. If the original subscription starts but an extended configuration crashes, restore add-ons one at a time to find the smallest trigger. Don’t restore everything at once and guess. If the client supports a separate data directory, you can test one while keeping the original intact. Use the current client’s documented option; don’t assume unknown launch parameters apply.

If you need to rebuild the data, fully quit the client and any remaining core processes first. Rename the original data directory to keep it as a backup instead of deleting it. A fresh environment is only useful for checking whether the old data is involved; it won’t create a working proxy on its own. After testing, don’t overwrite the new directory with the entire old one, or you may bring back the file that triggered the issue. Migrate configuration, rules, and settings separately, recording the result at each step.

Distinguish Background Termination from a Reproducible Crash

If the window disappears after running for a long time, possible causes include low system resources, a logged-out session, or a power policy terminating the process. Check whether other apps closed around the same time and whether the device entered sleep. Analyze memory growth in context of runtime, connection count, and log level; a single high reading doesn’t prove a persistent leak. If opening a specific page or loading a particular profile always causes an exit, record the shortest steps to reproduce it. That’s easier for maintainers to verify than random restarts.

Before reinstalling, confirm that your backup is readable and note your current settings. After installing the new package, first verify startup with a minimal configuration, then restore your existing data. If you temporarily need another client, see the Client Comparison. For a cross-platform option, consider Clash Plus first, then evaluate Clash Verge Rev or FlClash based on your operating system and existing configuration. Client settings and override methods differ, so don’t copy an entire private data directory between clients.

After fixing the issue, test a cold start, a configuration update, and a normal exit. If it fails again only after restoring old data, narrow it down to a specific setting instead of reinstalling repeatedly. For intermittent crashes, note the time and what you were doing, then wait for more evidence. Without reproducible conditions, don’t treat a network parameter as a confirmed root cause.

Mobile Troubleshooting: VPN Permissions, Background Activity, and Network Changes

Mobile issues can stem from subscriptions and outbound proxies, but are often affected by VPN permissions, battery management, app routing, and switching between Wi-Fi and cellular. This section focuses on FlClash for Android. For iOS clients, see iOS Installation Options, with Clash Plus as the top recommendation. Don’t apply Android menu paths to iOS, and don’t assume that a successful browser request means every app is using the same proxy route.

Check VPN Permission and Avoid Competing VPNs

The first time you start a connection, Android usually asks you to confirm VPN access. If you tapped Cancel, return to the client, start the connection again, and grant access when prompted. Check the system VPN status alongside the core logs: a VPN icon in the status bar doesn’t confirm that the remote outbound works. If another VPN, filtering tool, or enterprise network app is installed, check whether it’s using the same VPN slot. Two apps may repeatedly compete for the connection.

In Android’s VPN settings, check options such as Always-on VPN and Block connections without VPN. These affect what happens after the client stops. If blocking is enabled, losing direct access after disconnecting may be expected behavior, not a broken Wi-Fi connection. Note the original settings before temporarily changing them for diagnosis, then restore the protection you need after testing. Organization-managed devices may prevent changes; follow your device management policy.

Check Background Restrictions Only If It Fails After Screen Lock

Keep the screen on and test the connection for a while, then lock the screen and repeat the same test. If it disconnects only while locked and recovers when you wake the device, check battery optimization, background activity, and auto-start permissions first. Settings names vary by manufacturer, so look in the system app settings instead of following menu paths from another phone. Allow necessary background activity and test again; you don’t need to remove power restrictions for every app on the device.

Distinguish “the system killed the client” from “the process is still running but the remote connection went idle.” If the system ended the process, you may see the notification disappear, the process restart, or VPN status change. An idle connection may recover when you make a new request. Wi-Fi sleep or cellular data restrictions can look similar while the screen is locked. Track changes to notifications, the VPN icon, and actual app requests to decide whether to check power management or connection recovery. The main screen toggle alone isn’t enough.

Recheck the Route After Switching Between Wi-Fi and Cellular

A network change alters the device’s IP address, default route, and DNS. Existing connections may not survive. Wait for the new network to stabilize, reconnect in the client, then close and reopen the target app. If Wi-Fi works but cellular doesn’t, check whether the client is allowed to use mobile data and whether the subscription URL is reachable over cellular. If only Wi-Fi fails, check for a captive portal, device isolation, and network-specific access restrictions.

Some apps use IPv4, IPv6, or UDP differently from a browser. Don’t permanently disable system IPv6 just to test. First check logs for the failed request, routing coverage, and outbound support, then compare one setting at a time. Android Private DNS may also affect the resolution path; note the original value before temporarily changing it. If only one app is affected, check its own Secure DNS, built-in proxy, and background data restrictions.

App Routing and the Limits of LAN Proxy Settings

If per-app proxy routing is enabled, check whether you’re using an allowlist or a blocklist. An app installed in a work profile, clone, or other user space may be a separate instance; selections in the main profile may not apply to it. After changing the list, restart the affected app or reconnect the VPN so old connections don’t keep using the previous route. System download services and browsers may use different processes, so checking the browser alone doesn’t prove that all downloads are routed.

When a phone connects to a computer’s shared proxy, the HTTP proxy in Wi-Fi settings usually affects only apps that honor that setting. It doesn’t create a full VPN connection on the phone. Enter the computer’s local network address and actual port, and make sure both devices are on a trusted network that allows them to communicate. If you leave that network with the manual proxy still enabled, the browser may keep trying to reach an unavailable computer. Manage the setting per network instead of using your home proxy address on every hotspot.

After making changes, test with the screen on, while locked, when switching from Wi-Fi to cellular, and after stopping the client. If only foreground browsing works, test background sync and other apps separately. For first-time setup, return to the Getting Started Guide to verify the connection. To understand how the core and client work together, see An Overview of the Clash Open-Source Ecosystem. Keep a record of the final working settings and rollback steps so you can troubleshoot the same way after the next network change.