Clash Troubleshooting
Connection & Configuration Diagnostics

No internet access: Find where traffic stops

Restore a baseline before narrowing down the cause

First, turn off the client’s system proxy and TUN, then quit any other VPN or proxy apps. Open a site that normally works without a proxy to confirm your Wi-Fi, Ethernet, or mobile connection is healthy. If you still can’t connect, check your router, network sign-in, and any leftover system proxy settings instead of switching nodes. Public Wi-Fi may require sign-in through a captive portal; starting the proxy too early can route sign-in requests incorrectly and make every site appear offline.

Once your basic connection works, restart the client and confirm that the right configuration is selected, the core is running, and the proxy group has an available member. “Connected” may only mean the local service has started—it doesn’t prove the remote proxy is reachable. In rule mode, try the same site and check whether the request appears in the connection list. If it doesn’t, investigate how traffic enters the client. If it appears but fails, check the policy, node, and DNS result.

Use an explicit proxy request to separate ingress from egress

Check which mixed port is actually configured, then run the test below. The example uses local port 7890; change it in the command if your setup uses another port. On Windows, use curl.exe to avoid differences with the older PowerShell command of the same name. You can also test a site that currently won’t load, but make only one or two requests—there’s no need for a concurrent stress test.

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

Connection refused usually means nothing is listening on that port, or the port is wrong. If the local proxy connection succeeds but then times out, the issue may be the exit node, routing rules, or remote network. An HTTP status code means part of the network path worked, but check whether it came from the destination site or an intermediary. Handle certificate errors separately; don’t hide the cause by disabling certificate verification.

Check the mode, proxy group, and rule order

In rule mode, rules are matched in order and the selected policy is used for the first match. If a site is matched by an earlier REJECT rule, switching nodes won’t change the result. If the selected proxy group is DIRECT, turning on the proxy won’t automatically route that connection through a remote node. Check the matched rule and final route in connection details rather than relying on the global toggle. Policy names in custom rules must exactly match existing proxy groups.

You can briefly switch to Global mode and explicitly select a verified node as a comparison. If Global works but Rule mode doesn’t, check the matched rules, nested proxy groups, and direct DNS resolution. If both modes fail, investigate the local listener and the node itself. Switch back to Rule mode afterward so Global mode doesn’t change how LAN traffic, work systems, or metered data are routed.

Verify the fix with repeatable checks

Don’t treat a page loading once by chance as proof that the issue is fixed. Close existing connections or restart the test app, then check one direct site, one site that needs a proxy, and one LAN address. Confirm the connection list matches what you expect. Browsers may reuse old connections, so requests made before and after a policy change can take different routes. Once results are consistent, save the configuration and note the working port, mode, and selected proxy group.

Node timeouts: Separate probe failures from connection failures

First identify which test is timing out

A timeout in the node list usually comes from a probe initiated by the client; it doesn’t mean every connection through that node will fail. A probe can fail because its target is unreachable, blocks the request, or returns an unexpected response—even when the node works. Try the node with a real destination and check the logs. If websites load but the probe fails, review the test URL and timeout setting instead of deleting the node or assuming the subscription is broken.

If real connections fail too, compare other nodes in the same proxy group. If all fail, suspect the underlying network, account status, shared configuration, or local blocking. If only one fails, the endpoint, protocol parameters, or route may be at fault. Don’t test the entire list at once; a burst of concurrent connections may trigger limits. Testing two different endpoints one at a time is enough for an initial comparison.

Use the logs to distinguish connection, handshake, and DNS failures

A timeout after dial tcp usually means the TCP connection wasn’t established in time. connection refused means the connection was actively rejected, perhaps because the port is closed or the service isn’t running. A handshake error means the connection reached the protocol or TLS stage. Check whether the destination in the error is the node server or the website server; each points to a different cause. Don’t focus only on the final “timeout” message.

If the node endpoint uses a domain name, first confirm that it resolves. A DNS failure can stop every connection that depends on it; an incorrect address can cause a handshake failure. For TLS-based protocols, also check the system clock, server name, and subscription-provided parameters. Don’t casually remove servername or change the fingerprint or transport path. These fields usually need to match the server, and guesswork only adds more variables.

Check whether the protocol works on this network

Some networks restrict UDP. If TCP-based nodes work but protocols that rely on UDP keep failing, try another network to tell a local restriction from a server-side problem. You can’t diagnose protocols such as Hysteria2 or TUIC with a standard TCP port test. Conversely, a successful TCP connection doesn’t prove that proxy authentication and forwarding work.

Office networks, campus networks, and public Wi-Fi may enforce access policies. Follow the network administrator’s rules; don’t try to bypass restrictions. If permitted, compare the same node on a home or mobile network. If it fails only on one network, record the time, protocol, and failure stage to help the service provider investigate. Don’t expose the local proxy listener to your entire LAN just for testing.

Check which node the proxy group actually selected

Manual, automatic latency-test, and failover groups work differently. When the interface shows an upper-level group, the actual exit may come from a nested automatic group. The displayed group name may not be the final node. Expand the connection route to see which member handled the request. Automatic selections may also rely on cached probe results, so verify with a real request after refreshing the test. Don’t draw conclusions from a single color or label.

Check the service status and usage limits. An expired account, migrated node, or connection limit can make a correctly formatted node unusable. Update the subscription and check the provider’s status page. Never post a full node URI in a public discussion. Node passwords, UUIDs, and subscription URLs can grant access; treat them like account credentials.

Choose safe fixes and know when to roll back

Start by refreshing a valid subscription, selecting a verified node, restoring the provider’s original parameters, and testing on another network. Don’t rely on skip-cert-verify as a permanent fix for certificate errors. Check the clock and server name first, then ask the provider to resolve certificate issues. Increasing the timeout temporarily can help identify a slow response, but it won’t fix failed authentication, an incorrect domain, or a closed port.

If only the automatic probe fails, try another stable test URL that you’re allowed to access. Record probe success and real-world connection success separately. For guidance on balancing latency, traffic multipliers, and location, see how to choose Clash nodes. Low latency doesn’t guarantee enough bandwidth, and a working node doesn’t guarantee that every site will accept its exit IP.

Subscription errors: Separate request failures from configuration parsing

Identify what you imported and where the error occurs

Subscription updates have two stages: first, the client fetches a response from the URL; then the client or core parses its contents. Connection timeouts, certificate errors, and unusual HTTP statuses are request-stage failures. YAML errors, unknown fields, and invalid proxy-group references after a successful fetch are parsing failures. Read the full error and identify which stage failed. Repeatedly clicking Update won’t fix an expired URL or incompatible format.

Check for leading or trailing spaces, line breaks, and smart punctuation in the pasted URL. Import the subscription URL provided by the service, not the account dashboard, payment page, or node management page. Query parameters may contain access credentials, and a missing suffix can turn the URL into a different request. Don’t run commands containing a full subscription URL on a public terminal or include it in screenshots or public logs.

Use the HTTP response to choose what to check next

HTTP status codes are a guide; their exact meaning depends on the provider. Authentication or access errors may relate to credentials, account status, or request policies. A missing resource may mean the URL has changed. If you’ve made too many requests, stop and wait. Even a successful response may contain a login page, maintenance notice, or error message instead of a configuration. Opening the URL in a browser doesn’t guarantee the client receives the same content.

Avoid making updates depend on the connection they restore

Some subscription URLs can only be reached through a proxy. If your current proxy node has stopped working and updates also depend on it, you can end up unable to fetch a replacement node. Check whether the client supports updating through a proxy. Where permitted, compare with a direct update or use a saved working configuration to connect first. Don’t keep converting an unreachable URL into different links; that can hide the real routing issue.

Some services return different formats based on the User-Agent. Use the service dashboard’s Clash or mihomo import option and follow its client requirements. Randomly spoofing request headers may return content intended for another client. Sending a private subscription to an unfamiliar online converter also exposes credentials. Before converting, verify the tool’s source and how it handles your data.

Diagnose YAML and core compatibility errors

YAML uses spaces for indentation; don’t use tabs. The reported line may be where the parser finally gives up, while the actual cause is a quote, colon, or list indentation on the previous line. Check the lines around the error, then review the top-level structure. The example below is a valid rule snippet, not a complete, connectable configuration. Its proxy policy name must match a group in your existing configuration.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

If the YAML syntax is valid but the error says a protocol or field isn’t supported, check which core is actually running. The client name, interface version, and core capabilities aren’t the same thing; an older core may not support mihomo extensions. Don’t simply remove the offending field to force the configuration to load—it may be required by the protocol. See how mihomo differs from the original core for compatibility details.

Protect local changes and verify the update

A remote subscription update may overwrite your direct edits. If the client supports overrides, merges, or local rules, put custom settings in the appropriate layer instead of editing the downloaded cache. After updating, check that the node list, proxy group members, and rules are still as expected, then test a real connection through a node. A successful subscription import only means parsing worked; it doesn’t mean every remote node is online.

If the new configuration fails but the old one still works, restore the old copy first and keep the new error details for review. Don’t clear all configurations and caches at once; you’ll lose the baseline for comparison. For more troubleshooting steps, see the subscription update failure checklist. After fixing the issue, reduce unnecessary automatic updates and confirm the client can still load the same working configuration after a restart.

Slow speeds: Check the node, route, and device separately

Compare like with like; don’t confuse different metrics

Slow page loads, video buffering, and slow downloads may have different causes. First record the destination, time, and exact symptom: does the page take a long time to start loading, or is throughput low after the download begins? Pause other downloads, cloud sync, and system updates during testing. Keep the device location and network the same. Results from different times or sites aren’t directly comparable, so they won’t tell you whether the node or destination service changed.

Latency tests measure the round trip and processing time for a probe, not bandwidth. A low-latency node can still be congested, while a high-bandwidth node may load pages slowly due to long-distance round trips. Compare two nodes on different routes against the same permitted test destination, noting the first response and sustained transfer. Avoid repeated high-volume tests; traffic usage may be charged under your provider’s rules.

Check node load and network routes first

If one node is slow while other nodes and direct connections work normally, start with that node’s route or load. If it slows down in the evening and recovers at other times, shared exit capacity or ISP routing congestion may be involved. Comparing another route in the same region is more useful than switching to a nearby region. A region label doesn’t guarantee the same physical route, exit IP, or content service; use actual connection results.

If all nodes are slow, use a direct connection with the proxy off as your baseline. If direct downloads are slow too, check Wi-Fi signal, band, router load, and your internet connection; compare with Ethernet if possible. If only one site is slow, the cause may be its content delivery route, rate limits, or exit-IP policies. Testing another destination can help rule out a general device issue, but doesn’t prove the original site will work.

Tell DNS delays from throughput bottlenecks

If the first visit is slow but the second is much faster, DNS, TLS handshakes, or caching may be involved. Check whether the logs show prolonged waits or repeated DNS attempts. If a download starts but stays slow, focus on route throughput, packet loss, and server limits. Don’t replace every DNS setting just because speeds are low; changing resolvers may return different content delivery addresses and invalidate the comparison.

You can use a single explicit proxy request to record timings—no extra tools required. The command below reports total time and time to first byte from a real request. Through an HTTP proxy, DNS resolution may happen in the core or remotely, so this isn’t an isolated DNS test. Use it only to compare the same request across different nodes.

curl --proxy http://127.0.0.1:7890 --max-time 30 -o /dev/null -sS \
  -w 'Time to first byte: %{time_starttransfer}s\nTotal time: %{time_total}s\n' \
  https://example.com

On Windows, use curl.exe, replace the output target /dev/null with NUL, and write the command on one line. Test with a small page; this measures response time, not large-file bandwidth. If time to first byte is normal but a particular download remains slow, check destination throttling, download manager concurrency, and whether the proxy rule sends the request through the same exit.

Check local traffic interception and resource usage

Compare system proxy and TUN without changing the protocol, DNS, and proxy group at the same time. If TUN alone is slow, check for other VPNs, virtual network tools, or security software, and see whether the logs show the same connection being processed repeatedly. High CPU or sustained disk writes in Task Manager may also affect network performance. After short-term debugging, restore the normal log level to avoid excessive writes.

Many connections, concurrent small files, and background sync can strain the core and device. Close unrelated apps and repeat the same single task. On routers and low-power devices, encryption and connection volume may exceed available processing capacity. Don’t copy high-concurrency settings from a desktop, and don’t permanently disable security features to improve speed. Use process, rule, and timing comparisons to identify conflicts.

Check MTU and routing boundaries

If small requests work but large pages or long connections stall—especially only in TUN mode or on one network—consider MTU, packet loss along the route, or UDP handling. First compare another network and protocol. Once you have a consistent difference, make a small adjustment to the supported MTU setting and keep the original value. There’s no one MTU value that works best on every device; lowering it blindly may add overhead without fixing anything.

Finally, check which rule matched the slow request. Some downloads may bypass the proxy, while media requests may use different proxy groups, so you can’t attribute every slowdown to the manually selected node. Restore temporary settings and retest the same destination, then verify again at a similar time. See a layered guide to diagnosing slow Clash speeds to avoid mistaking a brief fluctuation for a lasting fault.

DNS issues: Check resolution paths and Fake-IP mappings

Understand the difference between system DNS and core DNS

The browser, security software, operating system, and proxy core may all handle DNS. A domain resolving in the terminal doesn’t mean an app uses the same result; apps with encrypted DNS may bypass the system resolver. First note the failing domain, error, and current traffic-interception mode. If the logs show no matching DNS request, investigate the app’s resolution path before replacing every DNS setting in the core.

A system lookup gives you a baseline, but be clear about what it tests. nslookup typically queries the DNS server configured for the system. It doesn’t fully replicate encrypted DNS in a browser and may not use the current HTTP proxy. Note the responding server and address, then compare them with the client logs. If the domain resolves but the connection fails, check routing, rules, TLS, or the destination service instead of conflating the layers.

nslookup example.com

Know what to expect from Fake-IP

Fake-IP uses mapped addresses to associate domains with connections, allowing the core to match rules by domain. Seeing an address in the mapped range when this mode is enabled isn’t necessarily an error, and you can’t verify it as a real server address using a standard direct connection. After an app receives the mapped address, the same core must handle the connection. If only DNS is intercepted and the subsequent connection isn’t, the mapped address may take the wrong route.

After switching enhanced mode, restarting the core, or changing configurations, apps may still cache old mappings. Close the affected apps and clear their caches using the method supported on your platform, then start a fresh request. Windows can clear the system DNS cache, but browsers and apps may keep their own caches and need a restart or a change in their network settings. Repeatedly switching modes while old connections remain open can mix old and new mappings.

ipconfig /flushdns

Add filters for compatibility issues

LAN device discovery, some games, and apps that require real addresses may need exceptions. Add fake-ip-filter entries for the specific domains affected instead of excluding every domain. The snippet below shows a mapping range and LAN suffix filters; it doesn’t include upstream resolvers and can’t replace a complete DNS configuration. Before editing, check that your current core supports the filter syntax.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

Private DNS and internal company domains often require a resolver provided by your organization. Public DNS can’t replace internal DNS, and switching to a public service may break work systems. Note whether the issue occurs only on the company network, and check the required domain suffixes and VPN DNS settings. LAN discovery may also rely on mDNS or broadcasts; adding a domain filter alone won’t necessarily restore every discovery feature.

Check startup dependencies for upstream and node DNS

An encrypted DNS upstream may itself use a domain name that must be resolved first. Node server domains also need a valid result before the proxy can connect. If resolving the node domain depends on a proxy that hasn’t started yet, you can create a loop. Settings such as mihomo’s default-nameserver and proxy-server-nameserver serve different purposes. Confirm the current core’s behavior before changing them.

When DNS requests are routed by rules, also check how connections to the resolvers are routed. Don’t add several policies that refer to each other and expect the core to resolve the dependency. If the logs repeatedly query the same upstream domain without completing the connection, check the bootstrap resolution path first. For upstream timeouts, verify that the current network allows access instead of relying on how familiar the server name looks.

Check for DNS leaks and unexpected results

A DNS leak means requests take an unexpected route; seeing a local ISP’s name in results doesn’t automatically mean there’s a leak. Website-based tests are only clues and may be affected by caches, encrypted DNS in the browser, IPv6, or how the test service observes requests. Compare system DNS settings, client query logs, and app settings to establish who made the request, which route it took, and whether that differed from your intended setup.

If IPv6 is enabled, check AAAA records and IPv6 routes too. Handling the IPv4 proxy path doesn’t mean IPv6 requests are intercepted. Conversely, disabling IPv6 may break network features that were working. Compare address types and connection results for the same domain, then configure full interception or explicit direct routing as appropriate for your platform. See the Fake-IP glossary entry for an explanation.

System proxy not working: Check the entry point, port, and TUN routes

System proxy settings don’t cover every app

A system proxy is a set of proxy settings provided by the operating system, and whether an app uses them depends on how it’s built. Some browsers read these settings; some command-line tools, games, and apps with their own network stack don’t. If a browser works but one app doesn’t, check for an app-specific proxy setting instead of assuming the core is broken. Consider TUN only if you need to cover more traffic.

Start with an explicit proxy request. If it works but requests that rely on system settings fail, the local proxy service and at least part of the exit route are working; the issue is more likely in the system settings or app entry point. If the explicit request fails too, check the listening port, core startup, and configuration loading. The interface toggle and the operating system’s actual setting may briefly disagree, especially after an abnormal exit or when multiple apps compete for control.

Check the port and listening address

mixed-port provides both HTTP and SOCKS access; port and socks-port configure them separately. Don’t enter the external controller port as the proxy port: it manages the core and doesn’t forward regular requests. After changing settings, confirm that the core has reloaded. An old process may still be using the previous port, making the interface and actual listener disagree.

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info

This is a basic snippet for local use and must be merged into your existing configuration. Keep the loopback listener if only this device needs access; there’s no need to expose it to the LAN. allow-lan controls whether other devices can connect; it isn’t required to fix the system proxy on this device. If a port is already in use, identify the process with system tools before changing the port or stopping a conflicting app. Don’t terminate unfamiliar system services.

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

Check platform settings and command-line environments

On Windows, user proxy settings and the WinHTTP proxy are separate; an app that reads one may be unaffected by the other. On macOS, proxy settings are tied to a network service, so check the active service after switching Wi-Fi, Ethernet, or a newly added service. On Linux, desktop proxy settings may differ from terminal environment variables. Identify which layer the target app reads rather than treating them as a single toggle.

Command-line tools often need explicit options or environment variables. The variables below affect only the current terminal and child processes launched from it; they don’t change settings for every app. Existing terminals and background services may still have old values, and exceptions in NO_PROXY can bypass the proxy. For remote DNS resolution through SOCKS, you can use a socks5h address if the tool supports it.

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

TUN permissions, routes, and exclusions

TUN intercepts traffic through a virtual network interface and requires the right permissions and routing configuration. A client may use a service or system authorization to set these up; turning on the interface toggle doesn’t prove the routes were installed. Check the logs for permission, adapter, or route errors, then inspect the actual interface. Organization-managed devices may restrict virtual adapters; follow device management rules instead of trying to bypass them.

Before enabling TUN, close other VPNs and note the current system proxy settings. After starting it, check ordinary apps, command-line tools, and LAN access. If work network ranges stop working, review automatic routing and exclusions. Excluding every private address range won’t suit every network and may break resources that need to travel through a VPN. Configure routes for your actual network instead of copying unrelated subnet lists.

Recover and verify after an abnormal exit

If the internet stops working after the client exits, the system may still be pointing to a local port that is no longer listening. Restore the original proxy settings in your system network preferences, then confirm that apps can connect directly. For leftover TUN routes, close the client normally, restore the network service, or restart the device; don’t manually delete unfamiliar routes. Also check startup order—launching before the network is ready can cause the first connection to fail.

For Linux environments that need a persistent service, see the mihomo and systemd deployment guide. After fixing the issue, exit and restart the client once to verify that the listener, proxy settings, and routes are restored correctly. Finally, make sure the network also works with the proxy stopped, completing a full start-and-stop check.

Client crashes: Tell the UI, core, and system service apart

First identify which component exited

A window disappearing doesn’t always mean the core stopped, and a tray icon doesn’t prove that the core is healthy. Check client logs and system processes to distinguish a UI crash, core exit, or background service startup failure. A UI issue usually affects controls and display; a core issue stops the proxy listener; a service issue may only affect TUN or privileged features. Note whether it happened during startup, configuration import, or after enabling a feature.

First close leftover processes normally, then try launching the client again. Multiple instances may compete for the configuration file, controller, or proxy port, making the second instance look like it crashed. If an instance is still running in the background, don’t install another client and enable the same traffic-interception features. Confirm the old instance has exited before retesting; otherwise, process conflicts may look like a compatibility problem.

Compare configurations to see whether a recent change triggered the crash

If the crash began after a subscription update or configuration edit, restore the last copy that started successfully. If the old configuration works but the new one doesn’t, check syntax, rule-set loading, protocol compatibility, and file paths. Some clients show a configuration error in the UI after the core has already refused to start; reinstalling isn’t the only solution. Keep the error and nearby lines, and redact node credentials before sharing them for review.

You can use mihomo’s test mode to check a configuration in a command-line deployment, but this doesn’t replace a full runtime test. Adjust the program name and path to match your installation; on Windows, you may need to run mihomo.exe. GUI clients may have a built-in checker; prefer that to avoid another core interfering with the same configuration directory.

mihomo -t -f ./config.yaml

If a minimal rules-only configuration loads but adding a rule set causes a failure, check the rule-set path, format, and download. Relative paths may depend on the configuration directory; don’t assume the working directory is always the same. Restore new content in small batches to pinpoint the trigger. That’s more useful than clearing everything, only to discover you had no backup of your subscription URL or local overrides.

Check architecture, OS support, and permissions

When downloading, match both the operating system and processor architecture. Apple Silicon, Intel, and ARM devices may need different packages. Startup errors can result from an incompatible architecture, missing system components, or an unsupported OS version. Check the package and requirements in the Download Center rather than choosing by a similar filename. For a fresh install, consider Clash Plus first, then choose another client based on your platform needs.

An unwritable configuration directory, low disk space, or incorrect log directory permissions can also prevent startup. Check that the current user can read and write the client’s own data directory; don’t make the entire system directory writable by everyone. A Linux service may run as a different user than your interactive session. A file readable in the terminal may not be accessible to systemd, so check permissions as the service account.

Use evidence to investigate security software and resource issues

Security software may block a virtual adapter, background service, or application startup. Check quarantine records and system notifications to identify the blocked file and action; don’t disable all protection long-term. On a managed work device, ask an administrator to review the logs. If the client exits only when TUN starts, focus on the adapter and privileged service. If it fails as soon as the window opens, check graphics components and user data first.

If memory or CPU usage stays high, check for excessively verbose logs, oversized rule sets, or connection loops. High resource use is a symptom; correlate it with connection counts, log entries, and the action that triggered it. Restore the normal log level, stop duplicate traffic-interception apps, and check whether performance improves. On low-memory devices, reducing unnecessary configuration size is usually better than increasing the cache further.

Reset and migrate carefully

Back up before resetting, then move only the suspected corrupted user state or cache files so the client can rebuild them. Prefer the client’s built-in reset option and check what it will remove. Remote subscriptions, local rules, proxy group selections, and system service settings are separate data. When moving to another client, don’t assume every UI preference will transfer automatically with the YAML.

Clash for Windows and ClashX Meta are no longer maintained. If you run into new OS compatibility issues, consider moving to a maintained alternative. Export your configuration and custom settings first, then choose a client in the platform order listed on the download page. Verify basic proxying before restoring TUN and startup options. Don’t configure both the old and new clients to intercept network traffic at startup.

Mobile troubleshooting: VPN permissions, background activity, and network changes

Start with VPN authorization and configuration loading

Mobile clients usually intercept traffic through the system VPN interface. The first connection requires system authorization; importing a subscription successfully doesn’t mean permission has been granted. Confirm that the right configuration is selected and the proxy group has an available member, then connect. Check whether the system shows a VPN status and the client records the request. If authorization was denied or is restricted by device management, fix that at the system level instead of importing the same subscription again.

Other VPNs, work profiles, security filters, and some ad-blocking tools on the same device may compete for traffic interception. For testing, leave one traffic-interception tool active and disable other services of the same kind. Browser extension filters don’t necessarily conflict with VPNs; check how they work. On a managed device, follow the management policy instead of removing its profile to force a proxy connection.

Android background and battery restrictions

If Android disconnects when the screen locks and reconnects when you return to the app, background restrictions may be the cause. Check whether the client’s notification stays visible and whether the system restricts background activity. Allow the necessary background use in the battery settings available on your device; menu paths vary by manufacturer. After changing them, lock the screen, wait, unlock, and check the logs rather than relying on the foreground toggle.

“Always-on VPN” and “Block connections without VPN” change what happens after a disconnection. With blocking enabled, the whole device losing internet when the client stops may be expected system behavior. Check this setting before temporarily disabling it for comparison, then restore the protection you need when troubleshooting is complete. Don’t mistake traffic blocked by the system for a DNS problem or a failure of every node.

Android clients may also offer per-app proxying or bypass lists. If one app has no log entries, check whether it’s excluded, especially if it’s in a work profile. An app on the bypass list can’t be explained by its proxy group. Clash Plus, Clash Meta for Android, FlClash, and Surfboard differ in interface and configuration support. When switching clients, check each feature instead of copying all preferences blindly.

iOS connections and choosing a client

When using Clash Plus on iOS, follow the system prompt to add a VPN configuration, then import a valid subscription and select a policy. The VPN status confirms that an interception tunnel exists, but you still need to test a real request to verify the exit. After changing configurations, close and reopen the test app if existing requests continue to fail; reused connections can interfere with the result. On a managed work device, first confirm that personal VPN configurations are allowed.

For client options and installation steps, see the iOS download guide. The official Clash Plus site is clashplus.io. If setup fails in the app, record import errors and connection errors separately rather than treating them as the same problem. Your account, subscription service, and client are separate parts of the setup; installing the app doesn’t automatically provide working nodes.

Test Wi-Fi, mobile data, and hotspots separately

If Wi-Fi works but mobile data doesn’t, check the client’s mobile data permission, system data restrictions, and whether the provider limits access from certain networks. If only Wi-Fi fails, check captive portal sign-in, router DNS, network protocol restrictions, and the network’s access policies. Use the same node and destination on both networks and record the results to narrow down the cause. Don’t change networks and configurations at the same time.

Switching between Wi-Fi and mobile data can change the local address, IPv6 status, and NAT mapping, so existing connections may stop working. Wait for the network to stabilize, then start a new request. If it still doesn’t recover, disconnect and reconnect the client and check whether the exit is re-established. A failure only during the switch is different from one that continues afterward; record them separately.

Turning on a phone hotspot doesn’t mean connected devices will automatically use the phone’s VPN. Traffic forwarding depends on the operating system and implementation, so a working webpage on the phone doesn’t prove a computer is using the proxy. Verify the exit on the connected device itself. If you need to share a proxy, first confirm that the client supports LAN access and review network isolation settings. Restrict access to avoid exposing a proxy port on a public hotspot.

LAN access and final verification

Screen casting, printing, LAN management, and game discovery may rely on direct connections, broadcasts, or local DNS. If these stop working when the proxy is enabled, check LAN bypass settings, routes, and Fake-IP exceptions. Don’t route all traffic directly just to restore screen casting. Identify the affected app and destination address, then add only the necessary exception. Test LAN discovery separately from access to public websites.

Finish with four checks: foreground browsing, recovery after locking the screen, switching between Wi-Fi and mobile data, and network behavior after stopping the client. Confirm that subscription updates won’t overwrite custom rules, and keep a working configuration. For common questions, see the Help Center. For a first install or migration, return to the Getting Started guide to establish a working connection, then restore background, per-app, and LAN settings.