Clash Troubleshooting
Connections, configuration, and traffic routing

No internet: separate local network issues from proxy issues

Note when the problem started and what it affects: are all apps offline, or just the browser? Are all sites failing, or only one domain? Does the connection recover when you close the client? Don’t start by changing nodes, DNS, TUN, and the client all at once—you’ll lose useful evidence. Save a copy of your current configuration and note the proxy mode, selected policy group, and system proxy status. Repeat the same test after each step so you can tell whether a change helped.

Restore a direct-connection baseline

Turn off the system proxy and TUN in the client, then exit it normally. Check your system network settings for a leftover manual proxy or auto-config script. Test a site that normally works without a proxy, and check whether your router, Wi-Fi, and other devices are working. If other devices on the same network are also offline, troubleshoot the network connection first. If only this device is affected, check the network adapter, default route, captive portal, and other VPNs. Public Wi-Fi may require you to sign in through a browser before connecting; proxy routing can interfere with that step.

Once direct access works again, start the client. Check that its status shows the core is running—not merely that the window is open. Look in the logs for configuration load errors, port conflicts, or permission issues. If the core hasn’t started, changing nodes or modes won’t have any effect. Fix the first clear error in the log before addressing follow-on errors. If the network still doesn’t recover after the client exits, check the system proxy address again rather than repeatedly force-quitting processes.

Test the proxy endpoint with an explicit request

The example below uses local mixed port 7890. Check the actual port in the client settings and update the command before running it. example.com is for illustration; replace it with a known-reachable HTTPS address related to the issue. On Windows, use curl.exe to avoid command alias differences. Explicitly specifying the proxy bypasses differences in how system proxy settings are read, though TUN routing can still affect the request when enabled.

# Use the local HTTP proxy explicitly
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

# Ignore proxy environment variables; turn off TUN before testing a direct connection
curl --noproxy "*" --connect-timeout 10 --max-time 25 -I https://example.com

If the connection to the local port fails, check the core, listening address, and port. If the local connection succeeds but the remote request times out, investigate the node and egress. If you get an HTTP status code, the request reached the destination service at least in part—it isn’t simply a total network outage. Some sites don’t support HEAD requests, so a method error doesn’t necessarily mean the proxy failed; try again without -I. Don’t diagnose a network-layer problem based only on a blank browser page.

Check where rules and policy groups actually send traffic

If an explicit proxy request succeeds but regular browsing fails, open the connections panel and find the request to the same domain at the same time. Check the matched rule, destination policy group, and final node. In rule mode, traffic may be assigned to DIRECT or REJECT. A correctly named policy group doesn’t mean it has a working node selected. Temporarily switching to Global mode can help as a comparison, but only for traffic that reaches the core; it won’t automatically capture apps that aren’t using the proxy.

If only one or two apps are affected, check their own proxy settings, extensions, and cache rather than changing the entire system network. If all HTTPS requests fail with certificate errors, verify the system date and time zone first, then check whether security software is inspecting HTTPS traffic. Don’t disable certificate verification as a permanent fix. Record the time, rule, and error text for one complete failed request; you can use that evidence in later sections instead of guessing at the whole network path again.

Node timeouts: distinguish failed checks from failed connections

A timeout in the node list only means that a particular check did not finish within the allotted time. It doesn’t prove that every service is unreachable. The test address may be inaccessible, the node may not support the connection method required by the test, or the timeout may simply be too short. Select a node manually, test the actual destination in a browser and with an explicit proxy command, then review the connection log. Focus on node connectivity, credentials, and egress only if both the test and the real request fail.

Compare under the same network and destination

Keep the network, destination, and mode fixed, then test two different nodes. If only one fails, suspect that node, its route, or its configuration. If they all fail while direct access works, check your subscription account, server hostname resolution, and client-core compatibility. If the same node works on another network, the current network may restrict its port or protocol. After switching networks, reconnect before testing; existing connections aren’t a reliable measure of the new network.

Connection timeouts, connection refusals, authentication failures, and TLS handshake errors occur at different stages. A timeout often points to an unreachable route or unresponsive service. A refusal means the destination address is reachable but nothing is accepting connections on that port. Authentication failures call for checking the account, password, or server configuration. Handshake errors may involve the system clock, server name, certificate, or protocol parameters. Keep the full error text; it’s more useful than a red status indicator alone.

Check the node source and protocol fields

Refresh the subscription from a trusted source and check whether the affected nodes are still available. Don’t fill in protocol fields based on snippets you find online: even nodes using the same protocol may require different transports, server names, or extra parameters. For a manual configuration, verify the server address, port, credentials, and indentation. The port must be the one the server actually listens on, not your local proxy port. A configuration that parses successfully is only syntactically valid; it doesn’t prove the remote account or protocol settings work.

If the error says a protocol or field isn’t supported, check which core is running rather than relying on the client’s name alone. Clash Plus, Clash Verge Rev, and FlClash provide configuration management, but network handling still depends on the core and how the client integrates it. Don’t use a complete mihomo configuration with an incompatible older core. See the downloads page if you need another client. Clash for Windows and ClashX Meta are no longer maintained, so consider compatibility and OS integration when troubleshooting.

Adjust how nodes are tested; don’t fake a healthy status

This example shows an automatic URL-test policy group and assumes your complete configuration contains nodes named 线路甲 and 线路乙. The test URL is illustrative and may not be reachable on every network. When merging this snippet into your configuration, use your own node names and a verified test URL. Don’t overwrite other policy groups from your subscription.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Node A
      - Node B
    url: https://example.com/
    interval: 300
    tolerance: 50

interval sets the check interval in seconds. tolerance is the switching tolerance in milliseconds; it helps prevent frequent changes caused by small latency fluctuations. Checking more often won’t fix an unusable node and may increase request volume. Treat automatic and manual groups separately: if a manually selected node works but the automatic group keeps switching, check the test URL and group members rather than blindly adding more nodes.

If an app still fails after the node recovers, close its persistent connections or restart it before testing again. Switching policies generally affects new connections; existing sessions aren’t guaranteed to move to a new egress. For reliable everyday use, keep a backup node that you’ve tested with your actual services. See how to choose a node for the trade-offs between latency, traffic multiplier, and location, and policy group examples for automatic strategies.

Subscription failures: check retrieval, response content, and configuration parsing

Importing a subscription involves two separate steps: the client fetches remote content, then parses it as configuration. A download failure and a parsing failure need different fixes. Open the subscription details or logs and identify whether the issue is DNS resolution, a request timeout, an HTTP status error, or YAML parsing after the content was downloaded. Keep the last working configuration when an update fails instead of deleting every subscription. It may still work for comparison tests, though whether the server accepts connections depends on your account status.

Make sure the URL wasn’t changed while copying

Copy the subscription URL again from your provider’s account page. Watch for line breaks added by messaging apps, smart punctuation, leading or trailing spaces, and missing query parameters. Parameters in a subscription URL may be required for authentication; don’t remove anything just because it looks unnecessary. After importing a QR code, check the configuration name and import result—successful scanning alone doesn’t mean the subscription works. Don’t post a full subscription URL in public forums, screenshots, or online converters. If you need help, redact authentication details in the path and all sensitive parameters first.

For an unauthorized or forbidden response, check whether the account has expired, the link was reset, or the provider restricts the request source. For a not-found response, make sure the URL wasn’t truncated and retrieve it again from the original source. If the server returns an error or requests are being made too frequently, stop clicking Update and try again later; also check the provider’s announcements. Changing a local port won’t fix a remote account rejection. Don’t mistake a server-side error for a damaged local configuration.

Test direct and proxied subscription retrieval separately

Some subscription URLs require a proxy, but if the current subscription is unavailable, relying on a node from that subscription creates a deadlock. Check which network path the client uses for updates: it may use a direct connection, system proxy, a specified policy, or its own download logic. Don’t assume that a URL opening in your browser means the client can fetch it too. Keep a working old connection, or update from another network where the URL is accessible, then import the new configuration. Use the client settings and logs to determine the actual path.

If the URL opens to a sign-in page, access verification page, or error page instead of configuration text, the client will often report a parsing failure. The YAML error is a symptom; the root cause is an unexpected response from the server. The response could also be a collection of node links, encoded text, or another client’s format rather than a complete Clash configuration. Confirm that the provider offers a subscription type compatible with your client. Changing indentation won’t fix an entirely different input format.

Check configuration merges near the reported line

When you get a line number, inspect the surrounding lines, not just the line itself. YAML uses spaces for indentation; tabs, duplicate top-level keys, and misplaced colons can all cause parsing errors. A policy group that references a nonexistent node, or a rule that references a missing rule set, can still trigger configuration errors after the syntax is fixed. Client overrides, global extensions, and scripts are merged into the final configuration, so a valid source subscription doesn’t guarantee that the core receives valid configuration. Temporarily disable personal overrides for comparison and keep a copy of the original file.

After a successful update, confirm that the new configuration is active, that policy groups still have a valid selection, and that a real request works. An “update complete” message alone doesn’t mean the active configuration changed. If the client restores old content every time it restarts, check write permissions for the persistent data directory and any personal overrides rather than importing the subscription again. For initial setup, see the Getting Started guide. This section covers retrieval and parsing issues; you don’t need to reinstall the entire client to update a subscription.

Slow speeds: separate latency, throughput, and app-side limits

First identify what’s slow: pages taking a long time to open, slow sustained downloads, frequent video buffering, or unstable game response. These symptoms don’t share a single metric. Node speed checks usually measure the round-trip time of a small request; they don’t tell you large-file throughput or whether the destination is throttling you. Choose one real destination, record connection setup time and sustained transfer performance, then compare direct access and a backup node. Use the same site for every test so server differences don’t mask route differences.

Control variables to avoid skewed speed tests

Pause bandwidth-heavy syncing, downloads, and system updates, then test one task at a time. Weak Wi-Fi, a congested channel, or device power-saving settings can affect your local connection. If direct downloads are just as slow, check your LAN and ISP connection first. On a desktop, compare with a wired connection; on a phone, test both Wi-Fi and mobile data. Run comparisons at roughly the same time—results from peak and off-peak hours can’t be attributed directly to a configuration setting.

Confirm which node the traffic actually uses. The node selected in the interface may belong to one policy group, while the current site is routed by another group or a DIRECT rule. The policy chain in the connections panel is more reliable than the selection at the top of the client. Automatic groups may also switch egress after a check, so consecutive tests might use different routes. During troubleshooting, use a manual group to pin a node, then restore the automatic policy when you’re done. Frequent egress changes can trigger session checks on the destination service, causing retries or slow loading.

Identify the bottleneck by connection stage

If DNS resolution takes a long time but transfers are fast once connected, check DNS first. Slow TCP setup or TLS handshakes followed by steady downloads may indicate route latency or retransmissions. If the connection starts quickly but transfer speeds stay low, consider server-side limits, route congestion, and local bandwidth. The command below uses an explicit proxy and reports several timings to help compare the same destination. With an HTTP CONNECT proxy, these timings show what the client observed; they aren’t direct measurements of remote DNS or node RTT.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

This example uses Unix-style line continuations and the null device path. On Windows, put the command on one line, use curl.exe, and replace /dev/null with NUL. The total time for a small page helps compare connection setup, not throughput. For sustained transfer tests, use a file from a known source with a known size, and make sure testing is permitted. Avoid stress-testing public services; run two or three tests and compare the results, since a single peak does not reflect typical performance.

Use care when troubleshooting UDP, MTU, and protocol differences

Video apps and browsers may prefer QUIC, which runs over UDP. How well it works depends on node support, the network route, and how traffic is captured. If TCP websites work but one app is unstable, temporarily disable QUIC in that app if it offers the option, and compare. Don’t treat disabling it as a universal optimization. A node supporting UDP doesn’t guarantee that the server or upstream route allows it. Whether the corresponding traffic appears in the logs says more about the actual route than the protocol name alone.

If small requests work under TUN but large ones stall, the path MTU or packet fragmentation may be involved. Record the current MTU, test the proxy entry point without TUN, and rule out DNS and node issues first. Adjust related parameters one at a time only if the difference is consistently reproducible. There’s no single MTU value that works for every adapter, tunnel, and network. Changing stack type, MTU, and routes all at once makes it hard to know what helped—and harder to maintain the setup on another network.

If only one service is slow, check the service region, egress IP risk controls, sign-in status, and app download limits. If every node slows down at the same time, check your local connection and the provider’s capacity. Reconnect after switching egress before comparing; existing connections may still use the old route. See how to compare latency, traffic multipliers, locations, and protocols. There’s no need to delete your entire rules configuration to troubleshoot speed.

DNS issues: trace resolution sources and Fake-IP mappings

DNS problems often show up as domains that won’t load, network errors in certain apps, or no improvement after switching nodes. Check the logs for resolution failures, then distinguish the website’s domain from the node server’s hostname. The first affects the service connection; the second can prevent the proxy itself from connecting. If the node hostname won’t resolve, changing website routing rules won’t fix the entry point. Also check whether the app uses system DNS, core DNS, browser Secure DNS, or its own resolver—they may all be active at once.

Know where system resolution ends and core resolution begins

nslookup example.com generally shows the response from the DNS server selected by the system. It doesn’t prove that the mihomo core can resolve domains. If the core listens on its own DNS port, query that address and port directly with a tool that supports custom ports. The example below uses local port 1053 for illustration; it only applies if your configuration actually listens there. If you don’t have a DNS testing tool installed, check the core logs and connection records instead—you don’t need to install an entire toolchain just to troubleshoot.

# Query the system's default DNS server
nslookup example.com

# Use dig to query the example core DNS listener port
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

If system lookups work but an app fails, check the app’s own DNS, proxy route, and destination connection. If core lookups fail, check whether its upstream resolver is reachable and review the startup logs. Accessing an IP address over HTTPS isn’t a reliable substitute because certificates and virtual hosting still depend on the hostname. Adding an entry to hosts may temporarily bypass resolution, but can hide address changes and routing issues. Use it only for a short-term comparison when you know the address and purpose, then remove it.

Understand how Fake-IP works

Fake-IP returns a synthetic address and saves a mapping between that address and the domain so the core can restore the hostname for later connections and rule matching. An answer in a reserved address range isn’t necessarily an error, and it shouldn’t be saved as a real server address in another device’s permanent settings. If an app gets a synthetic address but its connection doesn’t pass through the core that holds the mapping, the connection may fail. System proxy, TUN, DNS interception, and app caching need to form a consistent path; enabling only some of them won’t work.

This is a partial example of local DNS settings to show how the listening address, mode, and upstream relate. It isn’t a general-purpose fix. The upstream must be reachable on your network and shouldn’t create a loop through system forwarding. Keep a copy of the full configuration before merging anything. Binding to a loopback address avoids exposing the DNS service to your entire LAN while troubleshooting on this device. A client may override these settings, so check the final running configuration, not just the original subscription file.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Handle compatibility exceptions and caches

LAN device discovery, some games, and apps that need real IP addresses may not work well with Fake-IP. Identify the specific affected domains first, then add the narrowest exceptions supported by your current core. Don’t exclude every domain at the outset; that changes domain mapping and routing behavior. Local network names may depend on router DNS, search domains, or multicast discovery. They aren’t the same as public DNS, and switching to a public resolver may not resolve a printer or internal host.

After changing modes, old system and browser caches or app connections may still use previous results. On Windows, run ipconfig /flushdns to clear the system cache; the steps for other systems depend on the resolver in use. Then restart the affected app and use a client-supported action to rebuild the core’s mappings. Don’t repeatedly switch between Fake-IP and other modes while many old connections are still active, or old addresses and new mappings may mix and make the issue intermittent and hard to reproduce.

If IPv4 works but IPv6 fails, inspect A and AAAA responses, node support, and actual routing separately instead of relying on a single toggle. Browser Secure DNS can also bypass system settings, making browser and terminal behavior differ. Temporarily use one resolution source while troubleshooting, then decide on a long-term setup based on the result. If only one domain still fails, check its routing target and the resolver response instead of repeatedly changing every DNS parameter.

System proxy not working: check how each app connects

A system proxy isn’t a switch that captures all device traffic. It usually provides an HTTP or SOCKS entry point for apps that read system proxy settings; whether and how an app uses it depends on the app and OS interface. TUN uses a virtual adapter and routing to capture traffic sent along the relevant path, but is still subject to routes, exclusions, and permissions. First identify whether you need to capture a browser, terminal, game, or LAN device, then choose the right checks. Don’t treat system proxy and TUN as two names for the same switch.

Check system and browser settings first

Open the system network proxy settings and confirm the address and port match the client. A typical local proxy uses 127.0.0.1; that address refers to this device and won’t let another device connect to it. Check for a manual proxy, auto-config script, or another proxy tool running at the same time. Browser extensions may override system settings, enterprise policies may prevent changes, and some browsers use their own proxy settings. Temporarily disable relevant extensions to compare, then check whether the destination request appears in the core’s connections panel.

Run an explicit proxy command against the same destination. If it succeeds but the browser has no connection record, check the browser’s proxy entry point. If the browser request appears but is routed to DIRECT, the issue is with the rules, not the system proxy toggle. If the request reused an existing connection, reopen the page or restart the browser after changing settings to get a valid comparison. A private window can reduce extension interference, but it won’t necessarily bypass enterprise policies or system-level network software.

Configure terminal proxies separately

Many command-line tools read environment variables rather than system proxy settings. The example below applies only to the current Unix-like shell session; update the port to the actual value. Using an HTTP proxy address in HTTPS_PROXY is fine: the tool can use HTTP CONNECT to establish an HTTPS tunnel. Some tools read only lowercase variables, custom settings, or command-line options. Check the tool’s documentation rather than assuming the same variables work for every process.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

curl -I https://example.com

# Clear the current session settings after testing
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

In PowerShell, use $env:HTTPS_PROXY='http://127.0.0.1:7890' to set the environment for the current process, then run Remove-Item Env:HTTPS_PROXY when you’re done. Set the variable before launching a child process; an editor, terminal, or service that’s already running won’t pick up the new value automatically. Check whether NO_PROXY includes the destination hostname or an overly broad match. Also look for old lowercase and uppercase variables, which can cause different programs to use different proxy entry points.

Check routes even when TUN is enabled

First confirm that the service component is installed and the virtual adapter has been created. Check the core logs for permission errors or failed route updates. Follow the client’s instructions for administrator authorization or system permissions; don’t leave system security protections disabled as a substitute. Other VPNs, virtual machine adapters, and corporate tunnels may change the default route. Temporarily disable other tools of the same kind for comparison, but follow your administrator’s policy on managed networks and don’t override managed routes.

If LAN access fails under TUN, check route exclusions and whether the local subnet is correct rather than sending every destination through the proxy. Internal company domains may also depend on corporate DNS and split tunneling. Some configurations can use system proxy and TUN together, but testing each separately at first makes it easier to identify where the problem lies. If only UDP apps fail, confirm that the node and egress support UDP and that the traffic actually reaches the core. An HTTP proxy isn’t a general-purpose UDP entry point.

After testing, remove temporary environment variables, restore browser settings, and keep only the proxy entry points you actually need. For a more detailed browser and terminal walkthrough, see System proxy is enabled but not working. If the destination appears in the connections panel but won’t load, check the node or DNS sections instead of repeatedly toggling the system proxy.

Client crashes: isolate the UI, core, and service components

A client crash, frozen interface, and core shutdown are different problems. The UI displays and manages settings, the core handles network connections, and a service component may handle permissions and TUN. First check whether the window disappeared, whether a system proxy was left behind, whether the core process is still running, and what the last log entry says. A tray icon alone doesn’t prove the network is working; a window that won’t open doesn’t necessarily mean the configuration is damaged. Note the time of the failure so you can match it to system events later.

Restore network access before collecting evidence

If you lose internet after a crash, first turn off any leftover proxy in system settings and confirm that direct access works again. Use the client’s normal exit option whenever possible; end its processes only if you can’t use the interface. Copy your configuration, subscription data, and personal overrides before considering a reset. Subscription URLs, node credentials, and full URLs in logs may contain sensitive information; redact them before sending feedback. Don’t start by clearing app data—that can erase both the evidence and the known working recovery path.

If the logs report a configuration parsing error, see the subscription section. If a port is in use, check whether two proxy clients are running or a core process was left behind. Identify what owns the port before closing an extra instance or changing the listening port, then update the system proxy and app settings to match. Changing only the core port without updating the app entry point will turn a startup error into a new connection failure. Don’t terminate a system service just because of its process name; enterprise software and developer tools may legitimately use the same port.

# Windows: check the example proxy port; use the PID in the output to identify the process
netstat -ano | findstr ":7890"

# Linux: inspect listening ports and visible process information
ss -lntp

# macOS: check the example TCP listening port
lsof -nP -iTCP:7890 -sTCP:LISTEN

Rule out configuration and UI state with minimal changes

If enabling a particular configuration causes a crash, return to the last working one and compare with personal scripts, overrides, and extra rule providers disabled. Don’t fetch a large batch of resources during recovery; that can introduce unrelated remote changes. If the client only freezes when you open the connections panel, check the number of connections, log level, and UI refresh overhead. Temporarily reduce log detail and disable frequent refreshes, then see whether networking still works. Enable verbose logging only briefly while troubleshooting.

If the client crashes even while idle, check available disk space, write permissions for the user directory, security software logs, and system events. The installation directory and data directory may be separate, so reinstalling the app may not clear corrupted user state. Read the client’s reset instructions and confirm what will be deleted before using the reset option; make a backup first. Don’t delete the entire user directory or broadly elevate file permissions. Fixing a clearly identified denied path is safer and easier to verify.

Check platform, architecture, and launch method

Choose an installer that matches your operating system and processor architecture. On macOS, distinguish Apple Silicon from Intel; on Android, choose the device ABI; on Linux, check the package format and runtime dependencies. Using the wrong installer may cause startup, service installation, or update failures rather than a typical network issue. Choose a compatible package from the downloads page. Clash Plus is a good starting point for most users; for a Linux desktop, choose Clash Verge Rev or FlClash as described on the page.

On Linux, a graphical client and a manually launched mihomo process may compete for ports or change routes. If you use systemd, check the service user, working directory, configuration path, and file permissions. Don’t run the desktop core while repeatedly starting another service. Read logs from the process actually handling network traffic; results from a separate test configuration in a terminal don’t reflect the background service. See the Linux mihomo deployment guide for directory and permission details.

Include your OS and architecture, client name, steps to reproduce, time of failure, whether TUN was enabled, and the relevant redacted error in your report. A reliable minimal reproduction is more useful than an unfiltered log dump. Clash for Windows and ClashX Meta are no longer maintained. If the issue involves compatibility with a newer OS, consider a maintained client and keep your old configuration for migration. Don’t guess a version number and claim the issue is fixed.

Mobile troubleshooting: VPN permissions, background activity, and battery use

On mobile, check the system VPN status, whether the client is running, and whether the network actually works. A VPN icon in the status bar only shows that the system has established some kind of VPN connection; it doesn’t prove the selected node, DNS, or destination is working. Connect in the foreground and test a real destination, then lock the screen, switch apps, and change networks, noting where the connection fails. Desktop system proxy steps often miss mobile-specific permissions, background limits, and network changes.

Android: check VPN permission and background limits separately

Grant the system VPN permission on first connection and make sure another VPN app isn’t using the same connection. If Always-on VPN or Block connections without VPN is enabled, stopping the client may block all traffic. Note these settings before troubleshooting, compare with your intended setup, then restore the original policy. Uninstalling the client alone may leave the system settings in place. A work profile or managed device may have VPN settings controlled by an administrator; check the policy before making changes.

If the connection works in the foreground but drops when the screen locks, check battery optimization, background activity, auto-start, and the manufacturer’s power management settings. Menu names vary by device, so look up the settings for your model and client. Adjust only this app first rather than disabling power saving system-wide. Cleanup tools and one-tap boosters may stop background services; locking an app in the recent-apps screen may not add it to the system battery allowlist. After making a change, leave the screen locked for a while, then test a real request to confirm it recovered without reopening the app.

Per-app proxy settings change which traffic is covered. Check whether the target app is included or excluded; a working browser doesn’t prove that a game or chat app is routed through the proxy. App updates, work profiles, and cloned apps may use a different identity or package name, so check the selection again. Android Private DNS can also affect the resolution path. Check how it interacts with the client’s DNS, then temporarily use one source for comparison. Don’t permanently disable all system DNS features based on a single failed test.

iOS: check the system VPN configuration and tunnel status

iOS users can install Clash Plus from the iOS download page. The official product site is clashplus.io. On first use, allow the VPN configuration when prompted by iOS, then check both the tunnel status in the app and VPN settings in iOS. Other VPN profiles, managed network policies, or existing tunnels may interfere. Temporarily disable unneeded VPN connections for comparison; reinstalling the app won’t replace checking system permissions.

iOS network tunnels work differently from regular app interfaces. An app going into the background doesn’t necessarily mean the proxy stopped, and allowing Background App Refresh doesn’t guarantee that the tunnel stays active. If the connection only recovers when you return to the app, note whether the system VPN disconnected, whether the network changed, and whether the logs show a new tunnel being established. Don’t repeatedly force-quit the app to keep it alive. Test a normal disconnect and reconnect first; if needed, restart the device to clear an abnormal tunnel state.

Network switching and hotspot limitations

When switching from Wi-Fi to mobile data, old TCP sessions may drop, and DNS and the default route may change. Wait for the client to reconnect before closing a failed page or restarting the app’s connection. On public Wi-Fi, complete the captive portal sign-in first; when roaming, check that mobile data itself is available. A VPN on your phone doesn’t mean a computer connected to its hotspot uses the same tunnel—systems handle forwarded traffic differently. Test the hotspot device’s proxy entry point independently rather than relying on the VPN icon on your phone.

Start battery troubleshooting by reducing repeated work

Frequent node checks, rule set updates, verbose logs, and repeated failed reconnects can all increase battery use. Reduce unnecessary scheduled tasks first, keep a stable node, then compare battery use and temperature over similar periods. Background traffic may come from system sync or other apps, not just the proxy. A short idle test can be skewed by signal strength and charging status, so use the system battery page along with client logs. See mobile battery use and background settings for configuration trade-offs.

After troubleshooting, restore any temporary battery, DNS, and VPN changes, and keep a minimal record that can reproduce the issue. Before moving to another client, save your subscription source and personal rules, then import them using the Getting Started guide. Don’t copy all internal data from the old app directly into a different client. If the issue persists, return to the relevant node, DNS, or proxy entry point section. Mobile-specific limits are only one part of the connection path; they don’t replace checking the remote service.