mihomo
Logs · Rules · Network Stack

Clash Meta
Complete Troubleshooting Guide

Trace connection issues by symptom. Check the local port first, then rules, DNS, and the remote connection. Change one thing at a time.

For first-time installation and subscription import, follow the Getting Started guide. This page is for issues that arise after setup and is organized for quick reference. Once things are working again, return to the tutorial to verify the connection. Menu names vary by client; “configuration,” “connections,” “logs,” and “settings” refer to the corresponding areas. Always trust the active configuration and core logs over menu labels.

No Internet Access: Check the Local Entry Point

Separate Your Internet Connection from the Proxy Path

Disconnect the client, turn off the system proxy, and make sure TUN is off. Then try a site that normally works without a proxy. If it still won’t load, check Wi-Fi sign-in, cables, the router, and your system’s network status before changing any rules. Hotel and campus networks may require browser-based sign-in; until you complete it, even a working proxy server won’t connect. Once your regular connection works, restart the client with a single known-good configuration.

If your internet stops working after closing the client, check whether the system still points to a proxy address on your own computer. Apps will keep trying that address even after its listener has stopped, causing repeated connection failures. On Windows, check the manual proxy under Settings → Network & Internet → Proxy. On macOS, check the current network service under Details → Proxies. Note the existing values before changing them. On managed devices, an automatic configuration URL may be set by policy, so don’t clear it without checking first.

Check That the Core Is Running and Listening

Open the client logs and review entries from the most recent startup. A configuration parse error, port conflict, or insufficient permissions can leave the interface open while the core fails to provide a proxy. If you see address already in use, check for a second client or a leftover core process. Don’t just pick another port: if the system proxy and terminal environment variables still point to the old one, you’ll replace a port conflict with a mismatch between entry points.

mixed-port is the local port shared by HTTP and SOCKS; it is not the node server’s port. This snippet is only for checking your existing configuration and is not a replacement for a complete subscription. Once you’ve confirmed that the running port is 7890, test with an explicit proxy command. If your port differs, update the address in the command too. Use a site that works on your regular connection to test the local entry point first, without confusing the result with restrictions on the destination site.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

Use Connection History to Find Where the Request Fails

If the command immediately reports that it can’t connect to localhost, nothing is listening on the local entry point or a local security policy is blocking it. If it fails only after appearing in connection history, investigate rules and the outbound route. In Windows PowerShell, use curl.exe explicitly to avoid command aliases changing how arguments are interpreted. Any valid HTTP response means the request reached an HTTP service. A non-success status code does not, by itself, mean the proxy failed to start.

Filter for the destination domain on the Connections page and check the matched rule, policy group, and final outbound. Rules are matched in order, so an earlier broad rule can override a more specific one later. If the selected policy group points to an unavailable proxy, switching only the outer group won’t help. As a temporary comparison, try Global mode and manually select the same known-good outbound. Switch back to rule mode afterward; don’t use Global mode permanently to hide incorrect routing.

If an explicit proxy works but your browser doesn’t, see the system proxy section. If the logs show a DNS resolution error, see the DNS section. If only one outbound fails, see the node timeout section. For each test, note the destination, mode, outbound, and result. Avoid switching between different sites and nodes without a consistent basis for comparison.

Node Timeouts: Separate DNS, Connection, and Handshake Failures

A Failed Latency Test Doesn’t Mean Every Request Will Fail

Client latency checks usually send a request to a test URL through the selected proxy. They show the result of that probe, not simply whether a server port is reachable. The test URL may be unavailable, its response may not meet expectations, or the server may rate-limit frequent checks—all of which can produce a timeout. First, visit a site you actually need through the same outbound and check the connection logs. If that works, review the test URL and interval instead of deleting the subscription.

Determine whether the problem affects one outbound, every outbound from the same provider, or all providers. If only one fails, check that server and its parameters. If a whole group fails at once, check your account status, subscription updates, and server maintenance. If all outbounds fail, revisit your local network, DNS, system time, and firewall. A phone hotspot provides a useful comparison on a different network, but reconnect after switching; failures from an old connection don’t reflect the new network.

Read the Logs by Failure Stage

lookup or no such host usually points to DNS resolution for the server hostname. connection refused means the destination actively rejected the connection, commonly because nothing is listening on that port or the service is misconfigured. A timeout only means that a particular stage didn’t finish in time; it doesn’t prove the account is invalid. If the logs reach the TLS or protocol handshake, check authentication, SNI, transport settings, and system time instead of repeatedly changing DNS.

Log clue	Check first	Don’t assume
Server hostname lookup failed	Node DNS resolver and direct network access	Incorrect node credentials
Connection refused	Server port and listening status	Incorrect local rule order
TLS certificate error	System time, certificate chain, and server name	Disabling verification fixes the issue
Connection closed after handshake	Protocol parameters, authentication, and server restrictions	A longer timeout will always help

When maintaining a proxy manually, check type, server address, port, credentials, and transport settings one by one. The TLS server name doesn’t have to match the connection address; don’t assume you can freely swap a WebSocket path and Host value either. Use the mihomo configuration provided by your provider, preserving capitalization and field nesting. If a converted subscription contains unknown fields or an unsupported protocol, check the actual core in use rather than judging by the client’s name alone.

Separate Protocol Compatibility from Network Restrictions

Some outbounds use UDP, so successfully opening a regular TCP website doesn’t prove that outbound’s transport is working. Conversely, a working TCP proxy with a failing game may simply mean the app uses UDP, the proxy doesn’t support that traffic, or the policy group isn’t using the expected outbound. First establish a baseline with a regular HTTPS request, then test UDP-dependent apps separately. Don’t use a single latency figure to draw conclusions about both.

Check the system date, time zone, and automatic time settings. An incorrect clock can make a certificate appear not yet valid or expired. If the certificate error occurs only on a particular Wi-Fi network, consider a captive portal or network inspection device. Don’t treat skip-cert-verify as a general fix: it changes the connection’s trust boundary but won’t correct the server name, certificate chain, or authentication parameters.

When contacting your provider, include when the error occurred and the time zone, network type, protocol, and a redacted error line. Don’t send a full subscription, QR code, or configuration containing passwords. If switching networks fixes the problem, the issue is likely related to the network path. If the same outbound fails on multiple devices and networks, you have stronger grounds to ask the provider to check the server. A longer timeout can confirm a slow response, but it won’t fix a port that isn’t listening or invalid credentials.

Subscription Failures: Check the Request and Configuration

Separate Download Failures from Import Failures

A subscription update involves several stages: sending the request, receiving a response, parsing its contents, and generating the active configuration. First check whether the error is a network failure, an unexpected HTTP status, or a YAML parsing error. A URL you can’t reach and content the client can’t parse are different problems: check network access, DNS, and authorization for the former; format and client compatibility for the latter. Don’t repeatedly add the same subscription before you know the cause—you may end up with several similarly named configurations with different update states, making the wrong one easier to select.

Copy the complete URL, including all query parameters, and check that a messaging app hasn’t inserted spaces, line breaks, or ellipses. Subscription URLs often contain credentials; don’t include them in public screenshots, support tickets, or online conversion tools. A URL opening in a browser doesn’t guarantee the response is valid: it may return a login page, CAPTCHA, or quota-exhausted notice as HTML. Inspect the response type and opening content locally to confirm you received a supported configuration, not a web page.

Use the Response to Pinpoint Server or Local Issues

HTTP 401 or 403 usually calls for checking authorization, account status, and server access policies. A 404 may mean the URL has expired or its path was copied incompletely. A 429 means too many requests; stop refreshing manually and wait. For server errors, keep your current working configuration and retry later or contact the provider. These statuses can’t be fixed by changing a local port, and a failed update alone isn’t a reason to delete a cached configuration.

If the subscription URL is only accessible through a proxy, but the current configuration has no working outbound, updates can get stuck in a dependency loop. Try the client’s direct or proxied update option and note which route you used. If needed, switch to a network that can reach the URL. Keep the old configuration and use a working outbound to update first. Don’t make a subscription that hasn’t been downloaded your only route to the internet.

Check the YAML and the Final Merged Configuration

For an indentation error, start with the line number in the logs and inspect the surrounding context. YAML uses spaces to represent nesting; tabs, full-width colons, and unmatched quotes can all cause parse failures. Parsing successfully doesn’t guarantee that values have the right types: for example, a list written as a string or a boolean at the wrong level may fail only when the core loads it. Undo your most recent manual change and restore it piece by piece. Don’t rewrite the entire file at once.

mode: rule
proxy-groups:
  - name: Outbound selection
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Select outbound

This example is only for checking list and indentation structure; it includes a direct outbound only. In a real subscription, proxy group names must match the rule references exactly, including spaces and capitalization. If the logs report a missing proxy or policy group, check the generated runtime configuration, not just the original subscription. The client may apply overrides, merges, or scripts after downloading, and one of those post-processing steps may be the source of the issue.

proxy-providers supplies proxies; rule-providers supplies rule sets. They use different content formats. For rule providers, check behavior against the file contents: domain lists, IP lists, and classical rules aren’t interchangeable just by changing one field. Give each remote resource its own path too, so providers don’t overwrite the same cache file and replace one another’s contents during updates.

Troubleshoot in this order: “disable overrides → update the original subscription → confirm it loads → restore overrides one at a time.” After a successful update, check the active configuration, policy group members, and rule count, then test with a new connection. When syncing across devices, distinguish subscription content from local settings. Ports and TUN permissions shouldn’t be copied blindly; see Cross-Device Configuration Sync Compared for details.

Slow Speeds: Separate Bandwidth, Latency, and Load

Start with a Repeatable Comparison

“Slow” can mean a delayed page load, video buffering, low download throughput, or laggy interactions—and each calls for a different measure. Keep the device, network, destination, and outbound constant for before-and-after comparisons. If the first visit to a page is slow but later transfers are fine, look at DNS, connection setup, and the handshake. If downloads remain slow, focus on available bandwidth, server load, and destination-side limits. Recording the symptom is more useful than repeatedly speed-testing every node.

Check your local network baseline with a resource that’s reachable directly, then access that same resource through the proxy. For a destination that requires a proxy, compare two working outbounds. Pause system updates, cloud sync, and other bandwidth-heavy tasks while testing; multiple devices sharing bandwidth can skew results. Wi-Fi signal, router load, and mobile network congestion are all bottlenecks before the proxy. Switching clients can’t bypass them.

Latency Tests Don’t Rank Throughput

A lower-latency outbound doesn’t necessarily have more throughput or work better with every site. Automatic selection strategies generally make decisions based on test requests, not continuous download speed measurements. If only one site is slow, check its CDN, account limits, and the route from the outbound to that destination. If everything is slow, investigate the access network and overall server status. Don’t generalize from one large download to every app’s performance.

Use connection history to confirm which policy group handled the traffic. A rule may select an automatic group that itself references another selection group; the outer group’s name isn’t the final outbound. Existing long-lived connections may keep using the old route after you change a policy. Close the target app’s connection or disconnect only the relevant connection, then retry. Don’t clear every connection during an important download or remote session—you don’t want troubleshooting to cause another interruption.

Check DNS, Transport, and TUN Overhead

If there’s a pause every time you open a new domain, check whether DNS requests are timing out repeatedly before falling back. More upstream servers don’t automatically mean faster resolution: an unreachable resolver, a broken bootstrap lookup, or queries sent over an unstable outbound can all delay new connections. Establish a baseline with one resolver that works on your current network, then add routing as needed. Caching only helps repeat lookups; it can’t replace a reliable initial resolution path.

A browser may try HTTP/3 first, but if UDP is unstable on the outbound or current network, it may eventually fall back to TCP, causing a pause before loading resumes. Temporarily disable QUIC in that app to compare, but don’t permanently drop all UDP as an optimization; voice, games, and some protocols rely on it. During testing, check the connection type and destination port to confirm whether the slow request actually uses UDP.

TUN captures a wider range of traffic. When enabled, it may expose background traffic not covered by the system proxy, or compete with security software, another VPN, or a virtual network adapter over routing. Compare the same destination using an explicit HTTP proxy and TUN. If the former works but the latter is slow, check routing and the network stack before changing subscriptions. Before changing stack, confirm support in your core and platform, and record the original value so you can restore it.

If small requests work but large responses stall, the path MTU or an intermediate device may be involved, but first rule out destination-side rate limits and packet loss. Change the MTU only on the actual tunnel interface and compare results before and after; don’t apply an arbitrary value to every network adapter. Disabling the firewall repeatedly isn’t a speed fix either. Check for a specific blocked event, then adjust only the rule for the relevant client or interface.

At the end of troubleshooting, save a reproducible comparison: the same destination and time period, results from two outbounds and two access networks, and whether TUN was enabled. If the bottleneck consistently occurs on a particular server route, that information will help your provider investigate. Don’t clear caches, reinstall the app, or increase parallel connections by default without evidence that they’ll help.

DNS Issues: Check the Resolver and Outbound Path

First Identify What’s Making the DNS Request

DNS issues don’t always originate in the core. The system resolver, browser Secure DNS, app-specific resolvers, and mihomo DNS may all be active at once. First check whether the failed request reached the client, then look for resolution errors in the logs. If a browser works but a terminal doesn’t, they may be using different DNS paths; if the terminal resolves names but the browser doesn’t, the app’s encrypted DNS may be unreachable. One lookup tool’s result doesn’t represent every app.

With an explicit HTTP proxy, the destination hostname is usually handled by the proxy entry point. With SOCKS, distinguish local DNS resolution from remote resolution. The command below uses socks5h to resolve the hostname through the proxy, so you can compare it with the app’s local resolution. If the command works but the app doesn’t, investigate the app’s DNS behavior instead of immediately changing system-wide DNS. Make sure the command uses the actual mixed port.

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

Know What to Expect from fake-ip

enhanced-mode: fake-ip returns a virtual address for eligible domains and lets the core track the mapping between the domain and connection. An address in the 198.18.0.0/16 range isn’t, by itself, evidence of DNS poisoning. What matters is whether traffic to that address is still handled by the same core. Problems can occur if an app bypasses the proxy after receiving a virtual address, or keeps using a stale mapping after the core restarts.

Close the affected app, restart the core, and clear the relevant system or app DNS cache before trying again. On Windows, run ipconfig /flushdns; on other systems, use the command for the resolver in use. Don’t delete the entire client data directory without confirming where the cached data is stored. For compatibility issues with local devices, printers, or specific captive portal domains, consider targeted fake-ip filtering instead of excluding every domain.

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

This is only a DNS snippet; the upstream addresses must be reachable on your current network. Listening on port 1053 doesn’t make the system use that service or automatically capture all DNS requests. You’ll need the client’s interception mechanism or an explicitly configured resolver. nslookup example.com 127.0.0.1 checks the local port 53, so it can’t verify the example’s port 1053. If dig is installed, use the command below to specify the port.

dig @127.0.0.1 -p 1053 example.com A

Avoid Circular Dependencies Between Bootstrap DNS and Proxy Outbounds

When an upstream is configured as a DoH URL with a hostname, that hostname must be resolved before the upstream can be reached. If the proxy server also uses a hostname, the node hostname needs resolution too. Distinguish the bootstrap resolution provided by default-nameserver from proxy node hostname resolution via proxy-server-nameserver. Don’t require a node hostname to be resolved through a node that hasn’t connected yet, and don’t force every query through the same unverified outbound.

Corporate domains and home network hostnames may only be known to internal DNS. If they fail after you configure a public resolver, that doesn’t mean the public DNS service is broken; your queries may simply be going to a resolver without those internal records. Preserve the internal resolution path and route relevant domains appropriately. Also check that internal network ranges aren’t mistakenly sent through the proxy. Before making changes, note the DNS servers provided by your network, especially on managed devices.

A “DNS leak” needs to be judged against the intended DNS path. If a test page shows a particular recursive resolver, that only tells you which resolver handled that test domain; it doesn’t prove that other connections bypassed the proxy. First decide which DNS route each domain should use, then check browser Secure DNS, TUN DNS interception, and connection history. Encrypted DNS protects queries in transit, but doesn’t guarantee they use the proxy outbound you intended.

System Proxy Not Working: Check How the App Connects

The System Proxy Doesn’t Capture All Network Traffic

A system proxy is a setting made available to apps; whether an app uses it depends on the app and its networking library. If a browser works but a command-line tool, game, or Store app doesn’t, that doesn’t necessarily mean the rules are wrong. First verify the core entry point with an explicit proxy command, then check whether the target app reads system settings. Some apps need an HTTP or SOCKS address entered separately, some use environment variables, and others are better handled by TUN. Don’t assume one switch covers every process.

On Windows, the user proxy, automatic proxy script, and WinHTTP settings are separate entry points. netsh winhttp show proxy shows the WinHTTP state, but not necessarily the settings used by your current browser. Don’t set a proxy for every system service just to fix one app; service accounts, update components, and user sessions may have different network needs. Identify the networking library used by the failing program, then choose the appropriate configuration method.

Check the Local Address, Port, and Environment Variables

Local apps typically use 127.0.0.1 and the port the client is actually listening on. A system proxy set to an old port will fail, as will entering an HTTP address in a field that supports only SOCKS. allow-lan: false doesn’t block loopback access from the same computer. But another device can’t use its own 127.0.0.1 to reach your computer. For LAN sharing, check the listening address, firewall, and trust boundary separately.

Child processes inherit environment variables when launched from a terminal. After the client changes ports, an already-open terminal may still have the old value; turning off the system proxy won’t remove manually set variables either. The example below is for testing the current session in a Unix-like shell and doesn’t change permanent settings. Check existing variables and note where they came from before setting a test value. When reverting, also check shell startup files, developer tool settings, and project scripts for anything that might set the proxy again.

env | grep -i proxy
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I --max-time 20 https://example.com
unset http_proxy https_proxy

Here, https_proxy still uses http:// to connect to a local HTTP proxy, which then establishes an HTTPS tunnel. It doesn’t downgrade the destination connection to plaintext. Tools differ in how they handle variable capitalization and precedence, and ALL_PROXY or NO_PROXY can also affect behavior. Check all of these variables, especially for bypass domains or network ranges that are too broad.

UWP, Containers, and TUN

Some Windows Store apps are subject to loopback restrictions and may not connect to a local proxy even when the system proxy is configured correctly. First confirm that a regular desktop app works through the same port, then consider granting the target app a loopback exemption or using TUN. Don’t exempt every app by default. For the exact commands and scope, see Troubleshooting UWP Loopback Restrictions. This issue doesn’t require changing remote proxy credentials.

Containers, virtual machines, and WSL have their own network views, where loopback may not point to the host. Find an address the host can reach in the current network mode, then check firewall rules and the listening interface. Don’t expose the local proxy on every interface as a first step; other devices on the same network could use it. If sharing is necessary, restrict access to trusted sources and configure access controls supported by the client.

TUN uses a virtual interface and routing to capture traffic, and usually requires extra permissions or a service component. After enabling it, check the logs for interface creation, route installation, and DNS interception. Two VPNs changing the default route, or overlapping virtual machine and tunnel subnets, can make some destinations unreachable. Temporarily stop other traffic interception software to compare. If things work again, determine whether the tools can coexist with explicit routes instead of repeatedly reinstalling network adapters.

Make a new request from the target app and confirm the process or destination, matched rule, and outbound on the Connections page. A changed exit address on a website only proves that website’s route is working. After a fix, test the browser, command line, and the app that originally failed. Then quit the client and check whether the system proxy is restored, so it doesn’t point to a stopped port.

Client Crashes: Separate the UI, Core, and Configuration

First Identify Which Component Exited

The graphical interface, background service, and mihomo core are separate components. If the window disappears but traffic still works, the UI may have failed; if the window stays open but all connections stop, check whether the core exited. Note whether the issue happens at startup, while importing a configuration, when enabling TUN, or after the client has been running for a while. Then check the logs for that time. “It crashed” alone doesn’t distinguish a parse error, permission problem, process crash, or system-initiated termination.

Don’t wipe your data after the first failure. Quit the client, back up the configuration directory, override files, and relevant logs, then check whether any background processes remain. Repeatedly reopening the UI may start a second core and introduce a port conflict that obscures the original issue. If the client has an “Open logs folder” or “Diagnostics” option, use it first. Paths vary by platform and client, so don’t copy a path from a different app.

Test the Core with a Minimal Configuration

Test core startup separately from subscription content. The configuration below listens only on localhost and uses a direct rule to check whether the program can start; it isn’t a replacement for a working proxy configuration. Save it as a separate test file and don’t overwrite your current configuration. If the minimal configuration works but the full subscription doesn’t, restore proxy providers, rule providers, DNS, and TUN one at a time to find the trigger.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

If you run mihomo on its own, start by testing the configuration. The example assumes the core and test configuration are in the current directory; users of a graphical client don’t need to download a separate core. Passing the test only confirms that the configuration parses and passes validation. It doesn’t prove remote resources can be downloaded or a proxy can connect. Check external rule file paths, relative directories, and runtime permissions in the actual launch environment too.

# Linux or macOS
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

Check Architecture, Permissions, and Upgrade Leftovers

Make sure the package matches your operating system and processor architecture. Downloading a file doesn’t mean it will run on your system, and a command-line core isn’t a graphical client installer. Most users can start with the downloads page to choose Clash Plus, then compare other clients if their platform requires it. Don’t copy core files or configuration directories between clients without checking them; the UI may expect a different control interface or launch arguments.

If the client exits only after TUN is enabled or a service is installed, check administrator authorization, background service status, and security software block logs first. On macOS, use the system prompt to allow required network components. On Windows, verify that service installation succeeded. On Linux, check the user that launched the process and device permissions. Don’t recursively open up permissions across the entire configuration directory or run every UI action as an administrator to mask a permission issue with one service.

A blank window after startup may be a rendering issue or app cache problem. If the core logs remain normal, don’t change proxy protocols. Quit fully and restart; if the client supports a rendering compatibility option, test that on its own. Back up your data before resetting the UI cache and confirm that the reset won’t also delete your configuration. System crash logs can help identify a problem with the graphics component or underlying runtime.

If the client exits after running for a while, check system memory pressure, disk space, and log growth instead of relying on a made-up “normal memory” figure. Enable debug logging only while reproducing the issue, then restore info. Keeping detailed connection logs indefinitely takes up space and records sensitive browsing activity. If the problem occurs only after enabling a particular remote rule set, save a minimal reproduction with sensitive details removed and note the steps that trigger it.

If the original client is no longer maintained, migrating is a better long-term option than repeatedly reinstalling the same archived package. The fact that Clash for Windows and ClashX Meta are archived doesn’t mean their configurations can be imported into other clients without review. Migrate subscriptions, custom rules, and overrides separately, test a connection, then remove the old software. See Switching to a mihomo-Based Client for the process.

Mobile Troubleshooting: VPN, Background Activity, and Network Switching

Android: Check VPN Service Status First

Android clients typically route traffic through the system VPN service. Another VPN, some local filtering tools, or an enterprise security app under the same user or profile may already be using it. Stop other traffic interception apps, reconnect in Clash Plus, Clash Meta for Android, or FlClash, and check the system VPN indicator and permission status. Don’t rely only on the client’s home-screen button color to tell whether the background service is still running.

If only certain apps fail, check the app routing list first. Apps on an exclusion list won’t be proxied as expected; when only selected apps are proxied, apps you haven’t selected won’t be captured either. Work and personal profiles may have different apps and VPN environments. A working connection in your personal profile doesn’t prove that the work profile uses the same route. Identify the affected profile before deciding whether an administrator needs to change an enterprise policy.

Connection Drops When Screen Locks: Check Power Saving and Stale Routes

If the connection works in the foreground but drops after the screen locks, first check whether the VPN service is still running. Then check whether the system restricts background activity, background data, or auto-start. Android settings vary by manufacturer; look under Settings → Apps → the client → Battery for background activity permissions, then check mobile data restrictions. Change one setting at a time and retest with the screen locked. Don’t turn off every power-saving feature at once or you won’t know which exception was needed.

If Always-on VPN or blocking connections outside the VPN is enabled, the whole device may lose internet access when the service is stopped. This is the combined effect of the blocking policy and service state, not necessarily a sudden node failure. To restore access temporarily, understand the purpose of the setting before changing it in the system VPN settings, then verify again after restarting the client. See Troubleshooting Android Background and Battery Restrictions for the full diagnostic flow.

High battery use shouldn’t be judged by the app’s ranking alone. The VPN process carries traffic for other apps, so the system may attribute some of their network use to it. Compare screen-on time, data transfer, and network type across similar usage periods. Then check for overly frequent health checks, subscription refreshes, or reconnect attempts. If the client produces lots of logs while idle, find the source of repeated requests instead of immediately disabling all DNS features.

iOS: Check the Tunnel and On-Demand Connection

On iOS, use the downloads page to open the Clash Plus App Store page. The official site is clashplus.io. If the connection fails, first check that the system VPN configuration matches the active configuration in the app, then see whether another network extension is also intercepting traffic. Sending the app to the background doesn’t mean the tunnel has stopped; check the system VPN status and the result of a new request together.

With On Demand enabled, iOS may automatically rebuild the tunnel when the network changes. If it reconnects right after you disconnect manually, that doesn’t necessarily mean the action failed; check the current On Demand rules and which networks they apply to. If Wi-Fi works but cellular doesn’t, first confirm the app can use cellular data, then check whether the current network can reach the subscription and outbound. Switching networks changes the source address for existing connections, so some long-lived connections will need to be re-established.

Network Switching, Captive Portals, and Local Access

After switching from Wi-Fi to cellular, wait for the network to stabilize and send the request again. If it still fails, reconnect the VPN instead of deleting the configuration. Public Wi-Fi sign-in pages may require local network access or specific domains; if needed, pause the proxy to sign in, then turn it back on. If the system blocks all traffic outside the tunnel, check the VPN policy described above so the sign-in request isn’t trapped behind a tunnel that can’t connect.

If phone casting, printing, or access to a home server fails, check whether LAN addresses are being sent through the remote proxy and whether the VPN permits the local access you need. Don’t route all traffic directly just to reach one printer. Note the destination’s LAN address and domain, then use the narrowest rule possible. Apps that rely on device discovery may need local broadcast or multicast too; a single TCP destination rule may not be enough.

For a mobile issue you can reproduce, record the platform, access network, behavior before and after screen lock, whether the VPN stays connected, and which apps are affected. Don’t share a full configuration publicly when asking for help. After recovery, test foreground access, a brief screen lock, switching between Wi-Fi and cellular, and LAN access. For fundamentals, see Troubleshooting. To import a configuration again, return to the configuration steps in Getting Started.