Clash Troubleshooting Guide

No internet access: establish a network baseline

A loss of internet access can originate anywhere from the Wi-Fi connection and system routing to the local proxy, rule selection, or remote connection. Before troubleshooting, note the client name, operating system, current mode, and whether the issue affects every app or just one site. Save a copy of the active configuration, and hide subscription URLs, passwords, and credentials in screenshots. Don't update the client, reset the network, and change subscriptions all at once. Even if service returns, you won't know which step fixed it.

Disconnect the proxy and test your basic connection

Turn off System Proxy and TUN mode in the client, then exit it normally. Open your system network settings and check that no manual proxy still points to localhost; on mobile, make sure the VPN is disconnected. Visit an HTTPS site that normally works without a proxy, then check whether you can reach your router's admin page. If you're still offline, troubleshoot Wi-Fi authentication, the gateway, your broadband connection, or a public Wi-Fi sign-in page first. Changing nodes usually won't help until your basic connection is back.

Public Wi-Fi often requires you to sign in through a web page. Disconnect the VPN, complete the sign-in as prompted by your system, then reconnect the client. If only one device is affected, compare it with another device on the same network. If all devices are affected, check the router and upstream connection first. You can also briefly test with a phone hotspot. If that works, it only tells you the issue is related to the original network—not that your subscription has failed. Note the differences between the two networks, then check DNS, UDP, or firewall restrictions.

Test the local proxy and remote connection

Restart the client and select a configuration that has loaded successfully. Leave TUN off and enable System Proxy only. Open Settings to check the active HTTP or mixed proxy port, then test with an explicit proxy request. The command below applies only if the client is listening on port 7890; change it to match the port shown in the UI. In Windows PowerShell, use curl.exe to avoid differences caused by command aliases. You can also replace the test URL with the site you're troubleshooting.

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

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

An immediate “connection refused” usually means the local port isn't listening, the port is wrong, or the core hasn't started—not that the remote node is at fault. If the local proxy connects but then times out, check the client's Connections and Logs views. If the log shows the request matching DIRECT, check whether the rules and target domain are as expected. If it matches a proxy group, verify which outbound is actually selected. The configuration shown in the UI may not be the one in use. After importing, make sure it is enabled.

Narrow down the cause, then restore your usual settings

Briefly switch to Global mode only if needed, and test the same destination again. If Global works but Rule mode doesn't, check rule order, policy group names, and the final fallback rule. If both modes fail, continue to Connection timeouts. Global mode doesn't guarantee every app is using the proxy; apps that ignore system proxy settings may still connect directly. Don't change modes and toggle TUN at the same time, or you won't know whether the problem is with rules or traffic routing.

If the internet is still down after you exit the client, clear any leftover system proxy settings and check whether another VPN, virtual network adapter, or security app has taken over routing. Don't delete all network adapters or reset the entire firewall. Stop the relevant programs and restart the system first. See which change restores connectivity before deciding whether to repair that component. If you can't identify the cause, note when the error occurred and save the first relevant log entry for further troubleshooting.

Connection timeouts: distinguish probes from real connections

A timeout in the client means a particular test didn't finish within the allotted time. It doesn't mean the outbound is unusable for every destination. A probe may involve DNS resolution, establishing a connection, completing a protocol handshake, and getting a response from the test URL. Failure at any stage can produce a timeout. Select an outbound and try to visit the target site, then compare the result with the logs. Don't repeatedly test every group at once; concurrent probes can trigger server-side limits and compete for local network resources, obscuring the original problem.

Classify the error by where it occurs

Open Logs, temporarily set the log level to info, clear old entries, and make one request. Use debug briefly only if you need more detail. Look for the first error related to the request, not just the final “request failed” message. A connection timeout points to an unreachable network or blocked port; a refused connection usually means the destination actively rejected it. TLS handshake errors may involve the server name, system time, or certificate. Error text is a clue, not proof on its own.

If the error occurs while resolving the node server's hostname, check DNS issues and bootstrap resolution first. If the hostname resolves but the server port won't connect, use this command in Windows to test TCP reachability. Use the server name and port from your active configuration; the domain in the command is an example. This tests only the TCP connection. It doesn't verify proxy protocol authentication or UDP-based protocols.

# Replace the domain and port with the values for the active outbound
Test-NetConnection -ComputerName proxy.example.com -Port 443

Check protocol settings and system time

Start by updating the outbound imported from your subscription rather than guessing at individual settings. For manual configurations, check the server address, port, password or user ID, and transport parameters such as path and server name. Similar-looking protocols aren't interchangeable, and older cores may not recognize newer fields. Check the configuration load log for messages such as “unsupported type” or field parsing errors before updating the client. Get updates from the client download page; don't overwrite one client's data directory with another's.

System time affects both HTTPS destinations and proxy connections that use TLS. Open your system's Date & Time settings, enable automatic time sync, and verify the time zone. Don't leave certificate verification disabled to work around certificate errors. First check the server name and certificate settings required by your subscription provider. HTTPS inspection on corporate networks, expired certificates, or an incorrect domain can also cause handshake failures. If the issue occurs only at work and not on a hotspot, ask your network administrator about restrictions instead of weakening security settings.

Check how automatic policy groups make decisions

url-test evaluates candidate outbounds using the configured test URL; fallback switches according to availability and order. Both depend on successful probes. If the test URL is unreachable, behaves differently, or doesn't suit the current network, the group may mark a usable outbound as unhealthy. The snippet below illustrates the fields only. Merge it into an existing policy group and keep your real candidate list; an empty list can't provide a working proxy group.

proxy-groups:
  - name: Automatic selection
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

In this example, DIRECT is only there to illustrate the structure and a direct-connection probe. For actual proxy selection, use an outbound name from your configuration. interval is the probe interval in seconds, not a connection timeout. tolerance is the threshold for switching; it can't fix an unreachable server. If manual selection works but the automatic group keeps showing errors, check the probe target and group references first, then read Policy Group Types Compared.

Finish with one-variable comparisons: try the same outbound on a different network, a different outbound on the same network, and the same outbound with a different destination. If only one destination fails, check its rules or service restrictions. If all outbounds fail on the same network, check the local firewall, system time, and network restrictions. A reliable comparison is more useful than repeatedly increasing timeout values. Retest a real request after each change; don't rely on the probe indicator alone to confirm recovery.

Subscription errors: check retrieval and parsing

Subscription updates have two stages: fetching a response over the network, then parsing it into a configuration or list of outbounds. “Download failed” and “invalid configuration” require different troubleshooting. Start by checking the full error in the subscription card or logs, including the HTTP status, parsing message, and timestamp. Subscription links often contain access credentials. Don't post them on forums, include them in screenshots, or submit them to online conversion tools. When asking for help, share only the domain type, error code, and a redacted example of the structure—not the original URL.

Check the URL and account status

Copy the full URL again from your subscription provider's website. Check that it starts with the correct HTTPS address and that chat apps haven't truncated the ending parameters. Don't include punctuation, line breaks, or spaces when copying. A sign-in page, a sharing page, and a subscription endpoint are different kinds of URLs. Being able to open your account page doesn't mean the URL returns a client configuration. If the link has been reset, the old one may keep returning access denied even if it's still saved in the client.

For 401 or 403 errors, check your account authorization, subscription status, and endpoint access requirements. For 404, check whether the path has changed. For 429, stop retrying and wait as instructed by the provider. A server error may be temporary; repeatedly deleting the configuration won't help. Some endpoints return different formats depending on the requesting client. Choose a Clash- or mihomo-compatible subscription explicitly supported by your provider rather than relying on the file extension.

Separate the download path from the content format

If your current outbound is down and subscription updates are configured to use it, you can end up in a loop: you need an update to connect, but you need a connection to update. In the subscription update settings, check whether requests use a direct connection, the system network, or a proxy. If possible, update over another working network. Some clients fetch subscriptions in the UI process; others use the core, so browser access doesn't guarantee the client will make the same request. Check the logs before changing the update path.

If the response is a sign-in page, CAPTCHA page, or gateway notice, the client may try to parse the HTML as a configuration and report a syntax error on the first line. Don't delete the first line just to clear the warning. If you need to inspect the response, save it locally and check its opening lines in a text editor instead of uploading it to a public site. Valid YAML may still not be a complete configuration: content containing only an outbound list may need to be referenced by proxy-providers, and can't always be enabled directly as the main configuration.

Fix the syntax without losing your existing configuration

When editing YAML by hand, indent with spaces, not tabs. Quote passwords and addresses that contain special characters appropriately. The reported line number may be where the parser finally gave up; the actual issue could be a colon, quote, or list nesting error on the previous line. Save a copy before editing only the relevant section. Don't replace your subscription file with a full configuration copied from the internet. Subscription updates may overwrite that file, making temporary changes hard to track and easy to lose.

If the subscription downloads successfully but there are no selectable outbounds, check whether the account returned any usable content and whether a filter expression excluded every item. If the log says a policy group references a missing name, check local overrides, subscription renaming, and group references. Disable recently added overrides or merge scripts, then reload the original subscription. Once the original configuration works, restore changes one at a time. For the standard import flow, follow the subscription import guide.

Slow speeds: separate response time from throughput

A slow page load, slow download, stuttering video, and choppy voice call are different problems. Web pages are more affected by DNS, handshakes, and requests for multiple resources. Large downloads depend more on sustained throughput. Real-time apps are also sensitive to packet loss and jitter. Note which app and destination are slow, when it happens, and whether a direct connection is just as slow. Don't infer download speed from policy group probes: an outbound that responds quickly to a short test may not sustain a fast transfer.

Compare under consistent conditions

Use the same device, network, and destination to test a direct connection and one manually selected outbound. Pause cloud sync, system updates, and other high-bandwidth tasks to reduce background traffic. On Wi-Fi, move closer to the router or compare with a wired connection. If local network transfers are also slow, check signal strength, wireless interference, and the network adapter. If only one remote site is slow, the cause may be the service, network peering, or restrictions on your exit IP.

Keep conditions similar across tests rather than comparing different sites, files, and times. Browser caching can make a second visit much faster, and download sites may assign servers dynamically. In your browser's Network panel, compare time to first byte, connection setup, and content download. A long wait for the first byte doesn't necessarily mean low bandwidth; it may be caused by server processing, a longer route, or connection retries.

Check routing rules and app connection behavior

Open Connections in the client, filter by destination domain or process, and check which rule and outbound matched the slow request. A page may fetch images, scripts, and APIs from different domains, so checking only the main domain can miss a problem with one resource. Ad blockers, browser extensions, and security software can also block resources and leave a page waiting. Try a fresh browser profile or temporarily disable relevant extensions to compare. Don't change the entire ruleset before you know where the problem is.

Frequent automatic policy group switching can force apps to reconnect, especially during long downloads or sessions. For troubleshooting, pin a working outbound first and see whether the issue goes away, then adjust the probe interval or switching tolerance. Don't set an extremely short interval in pursuit of “real-time optimization”; probes use connections and bandwidth too. See url-test, fallback, and load-balance explained for details on how different policy groups work.

Check UDP, MTU, and concurrency with care

If video or real-time calls fail while regular web browsing works, check whether the app uses UDP and whether the protocol, outbound, and server support that traffic. Browser HTTP/3 also uses UDP, and may retry before falling back on restricted networks. You can temporarily disable the relevant app feature to compare, but that doesn't mean all UDP should be disabled. Voice calls, games, and some tunneling protocols need it; disabling it long term may cause other problems.

If large downloads stall only in TUN mode while small requests work, check whether path MTU is involved. First make sure another VPN isn't running. Then lower the TUN MTU gradually within the options supported by the client, changing one value at a time and reconnecting after each change. There's no single best value for every network. If the change doesn't consistently help, restore the original value rather than leaving a temporary workaround in place. MTU testing also depends on the operating system and link type, so don't rely on a single command as definitive proof.

Finally, check device resources. If the client uses unusually high resources over time, look for verbose debug logging, duplicate rules, or multiple running cores. Low disk space can also slow log writes. Turn off debug logging and reduce duplicate tasks, then test again. If changing networks or outbounds consistently helps, keep those comparison results. If all routes are slow for just one destination, contact the service or subscription provider rather than assuming the local software is broken based on a single speed test.

DNS issues: trace the resolution path

DNS problems can make domains unreachable, slow down the first connection, break local device names, or produce resolution timeouts in the logs. Separate three questions: how the system resolves ordinary domains, how the core resolves destination domains, and how the proxy server's own domain is resolved. Different components may handle each path. Reaching an IP address directly doesn't prove that the HTTPS service works; certificates and virtual hosts still depend on the domain. Don't treat direct IP access as a permanent fix.

Find out which resolver handles the request

Check the DNS settings for your current network interface, then use the command below to get a basic resolution result. It shows the system's query path, which may differ from browser secure DNS or the core's internal resolver. A browser with encrypted DNS may bypass the system resolver. With DNS hijacking in TUN mode, ordinary queries may instead be handled by the core. Note whether these features are enabled before testing; results from different tools can't be compared directly otherwise.

# Windows
nslookup example.com
ipconfig /flushdns

# macOS / Linux: use if dig is installed
dig example.com A
dig example.com AAAA

Clearing the cache removes old results; it can't fix an unreachable upstream or a configuration error. Change the resolution path first, then clear system and app caches and reconnect. A NXDOMAIN response means the name wasn't found, but you still need to determine whether the domain doesn't exist or the upstream returned an unexpected response. A query timeout points more toward a path or service issue. Don't assume every failure is “DNS cache pollution,” or that one resolver is wrong just because it returns a different IP.

Understand fake-ip and bootstrap resolution

fake-ip returns an address that the core maps internally to the real domain. Seeing an address in the 198.18.0.0/16 range may be expected with the relevant configuration; it doesn't mean the website is actually hosted there. If an app still has an old mapping after the core restarts, its connection may fail. Close and reopen the affected app, then clear the DNS mapping using the method provided by your client. Don't bypass the mapping by adding the entire address range to direct-connection rules.

A proxy server's hostname must resolve before the proxy connection is established, or startup can get stuck in a dependency loop. In mihomo, proxy-server-nameserver can specify a resolver for these hostnames; default-nameserver resolves the hostnames of DNS upstreams. This snippet only illustrates the dependency. Before using it, make sure the resolver is reachable on your network. Don't open another DNS listening port that conflicts with the client, or replace the entire subscription.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

Handle local domains and dual-stack differences

Corporate networks, home storage devices, and router names often rely on internal DNS. Sending all queries to public resolvers may break them. Check which resolver local devices originally use, then use nameserver-policy to route known internal domain suffixes appropriately. For fake-ip compatibility issues, you can filter specific domains when needed. Filtering doesn't let a public resolver answer queries for internal records; you still need an upstream that can resolve those names.

If IPv4 works but IPv6 is only partially configured, an app may try IPv6 first, wait, and then fall back. Check A and AAAA records separately and see which address family the logs show for actual connections. You can temporarily disable the client's IPv6 resolution option to compare, but don't assume IPv6 should be disabled permanently. Some networks need it for full connectivity. Once you identify the cause, fix the route or outbound support, then restore dual-stack settings if needed.

After fixing the issue, test a public website, the node hostname, and a commonly used internal service. Restoring public web access while losing access to a printer or internal system isn't a complete fix. For how DNS and routing rules work together, see Rule-Based Routing in Practice. For unfamiliar terms, consult the quick reference. Identify which part of the path a field controls before changing it.

System proxy not working: check each app's proxy path

System Proxy registers a proxy address with the operating system; only apps that read that setting will use it. TUN takes over traffic that matches its routing rules through a virtual network interface. They work at different layers. If a browser works but the terminal connects directly, that doesn't necessarily mean the client is broken. Games and standalone downloaders may also use their own connection settings. First check whether an explicit proxy request works, then decide whether to fix the app's proxy settings or enable TUN. Don't assume every case is a node problem.

Test the browser, terminal, and services separately

In your browser, check whether a proxy extension overrides the system settings. Turn off duplicate proxy management features and restart the browser. Apps such as Firefox may have their own proxy configuration; confirm they use the system proxy or the correct local port. Then open Connections in the client, visit the target site, and see whether the request appears. Missing activity in the UI isn't conclusive on its own, but together with a successful explicit proxy request, it usually points to the app's settings.

Whether a terminal tool reads environment variables depends on the program. The settings below apply only to the current terminal and its child processes; already running programs won't inherit them. Change the port to match the client, then test the same destination. Use NO_PROXY to list destinations that should bypass the proxy, and avoid overly broad domain patterns. Remove temporary variables after testing so the terminal doesn't keep trying to use a nonexistent local port after the client exits.

# PowerShell: current session
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com/

# Clear temporary settings for the current session
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux: apply to this command only
https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

The proxy URL for an HTTPS destination may still use http://. This describes how the connection to the local proxy is made; it doesn't downgrade the destination website to plain text. HTTP and SOCKS ports aren't interchangeable. Tools using socks5h generally pass the destination hostname to the proxy for resolution, which can help isolate local DNS issues. Background services, containers, and remote sessions also have separate environments, so a working host browser doesn't mean they inherit the same settings.

After starting TUN, check permissions and routes

If you need to proxy apps that ignore system settings, install or enable the service component as described by your client, then turn on TUN. If the toggle immediately switches back off, check the logs for permission, device creation, or routing errors. Windows service mode, macOS system authorization, and Linux network permissions work differently; don't apply instructions for one platform to another. Clash Plus is a recommended option. For other clients' interfaces and system requirements, see the download page.

If TUN appears enabled but traffic still bypasses it, check for another VPN, virtual machine networking, static routes, or app exclusion rules. The following are common mihomo fields; merge them through the override method supported by your client to avoid duplicating TUN settings generated by the UI. auto-route sets routes automatically, while auto-detect-interface helps select an outbound interface. Neither replaces the required system permissions nor guarantees correct detection on every complex network.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Preserve local network access and clear leftover settings

If your local network stops working after enabling TUN, check whether its subnet is being routed through the tunnel and whether internal domains still use the correct DNS. Excluding a route and setting a rule to DIRECT aren't the same: the former decides whether traffic enters the tunnel; the latter decides how traffic exits after reaching the core. Confirm what's required before configuring specific subnets. Avoid overly broad exclusions that bypass all traffic. For work VPNs with dedicated routes, follow your organization's network policy.

When you're done troubleshooting, turn off TUN, then System Proxy, and exit normally. Confirm that direct access works again. If an abnormal exit left proxy settings behind, remove the leftover address in the system network panel; you don't need to uninstall the client right away. For a full browser and terminal checklist, see System Proxy Not Working: A Dedicated Guide. For router deployment, read OpenWrt Bypass Router Deployment Tips instead of applying desktop proxy instructions.

Client crashes: separate the UI from the core

A closed window, missing tray icon, stopped core, and failed configuration load are four different states. First check whether the client is still running in the background, whether the system proxy still points to it, and whether logs are still being generated. If the UI won't open but the proxy still works, the issue may be limited to the UI process. If the window works but all requests fail, the core may not have started. Repeatedly double-clicking can create duplicate processes and port conflicts. Check Task Manager or Activity Monitor for existing instances before restarting.

Save evidence and recoverable data first

Note the last action before the issue began: updating a subscription, adding an override, enabling TUN, importing rules, or upgrading the client. Save relevant files using the log or configuration directory option in Settings. Directory locations vary by client and installation method, so don't assume another app's paths apply. If the UI won't open, use system application logs or crash reports to investigate. Before sharing anything, remove subscription URLs, passwords, control interface credentials, and any content that could reveal browsing history.

Back up your subscription source, user overrides, rule files, and policy selections. Don't copy only the runtime configuration currently being generated: it may include cache and temporary fields and may not be the source file read on the next launch. Exit the program before moving its data directory to avoid truncating a database or file that's being written. Keep recoverable backups in a private local directory; don't upload the entire configuration directory when asking for help.

Find the specific cause of startup failure

If the logs say an address is already in use, check which process is listening on the proxy or controller port. The command below checks port 7890; change the port to match your settings. Identify the program before stopping anything—don't terminate a system process blindly. Common causes include an old client still running in the background, another core running at the same time, or a brief overlap during restart. Keeping one clearly identified instance is usually easier to maintain than changing multiple ports at random.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS: view local TCP listeners
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: view listening ports
ss -lntp

If the core exits immediately after starting, check for configuration parsing errors, rule file permissions, low disk space, and failed external resource loads. Disable recently added overrides or rule providers, then reload the last working configuration. If only one configuration triggers the issue, fix that configuration instead of reinstalling the UI. If files can't be written, check permissions on the installation and data directories. Don't make every file writable by everyone to work around the problem.

If the window is blank or a UI component reports an error, check the client's documentation for required system components and supported operating systems. Review security software quarantine logs to see which file was blocked and why. Don't disable all protection as a permanent fix. If needed, reinstall from a trusted source and follow the system's authorization prompts. Choose an installer that matches your device architecture. Older systems may not support newer UI components; check the download page and project documentation for compatibility details.

Use an isolated test instead of wiping data

If you suspect a damaged cache or local state, exit the client and rename the data directory to keep it as a backup. Let the program create a new directory using a method supported by its documentation. If the fresh environment starts, import subscriptions and user overrides one at a time to find the trigger. Don't delete the old directory immediately or copy every cache file back at once. If you use both portable and installed modes, check whether they share a data location so your test doesn't keep loading the same problematic state.

If you need to switch clients, use the download page to choose Clash Plus for your platform, or select Clash Verge Rev, FlClash, or another client to suit your needs. Clash for Windows and ClashX Meta are no longer maintained and aren't recommended as general fixes for issues on new systems. After recovery, test the regular proxy first, then enable TUN and automatic updates, and finally restore launch at startup. This separates startup, traffic routing, and background permissions, making future problems easier to diagnose.

Mobile troubleshooting: VPN, background access, and network switching

Mobile proxies usually rely on the system VPN. Their connection can also be affected by battery policies, background restrictions, and switching between Wi-Fi and cellular. First distinguish between “the system VPN disconnected” and “the VPN is still connected but traffic fails.” For the former, check permissions and whether the process is running. For the latter, check the outbound, DNS, and network changes. Android and iOS use different permission models, so desktop System Proxy instructions don't apply. A VPN icon in the status bar doesn't prove every request is being forwarded successfully.

Android: check VPN permissions and per-app settings first

On the first connection, approve the system VPN permission prompt. Then open the system VPN settings and check which app is handling the connection. Ad blockers, firewalls, and other VPN tools may compete for the same capability; exit other tools while troubleshooting. If Always-on VPN or Block connections without VPN is enabled, stopping the client may block all internet access. Understand what these settings do before temporarily disabling them, and don't mistake the result for a broken Wi-Fi connection.

If only some apps bypass the proxy, check the client's per-app proxy list. Interfaces may use either “proxy only selected apps” or “bypass selected apps”—opposite behaviors where selecting the same app produces different results. After changing the list, you may need to reconnect the VPN and fully quit and reopen the affected app. Work profiles, cloned apps, and system components may have separate identities, so check the specific app instance rather than just the name on your home screen.

If the connection drops when the screen turns off, open the system Battery and App management settings. Allow the client to run in the background as needed and check for background data limits. Some devices also have startup management settings; grant permissions according to your needs. After making changes, lock the screen for a while, then wake the device and test the same destination. Check the logs for signs that the process restarted. Locking an app in the recent apps list doesn't necessarily remove battery restrictions, and you shouldn't disable every power-saving feature just to fix one app.

iOS: check the configuration, permissions, and reconnection

On iOS, consider using Clash Plus. Find the installer in the iOS downloads; the official website is clashplus.io. Open the client and make sure the subscription is enabled, then add the VPN configuration and approve it when prompted. If the connection drops immediately, check the client's error log and the system VPN list for an old configuration or another app repeatedly trying to connect. Don't delete every network configuration. Disable conflicting entries first, then test them one at a time.

Some apps may keep existing long-lived connections after you switch networks or outbounds. After making a change, disconnect and reconnect the VPN, then fully quit and reopen the affected app. The system's VPN status only confirms that the tunnel is up; it doesn't mean every outbound in the subscription is reachable. If one site fails while others work, check its rules and DNS. If all requests fail, test another device on the same network to see whether the network is restricted.

Test network switching and hotspot sharing separately

If Wi-Fi works but cellular doesn't, check whether the system allows the client to use cellular data, whether your plan has data available, and whether Low Data Mode restricts the app. Then test the same outbound to rule out differences in UDP or IPv6 behavior across networks. Switching between Wi-Fi and cellular changes the local address and routes, so existing connections may drop. If reconnecting restores service, keep checking for a client background-state issue before resetting all network settings.

Your phone connecting successfully doesn't mean other devices on its hotspot will use the phone's VPN. Whether tethered traffic is intercepted depends on the system and client implementation, so test it separately. Allow LAN connections only permits other devices to access the proxy listener; it doesn't configure their proxy settings automatically. If needed, enable it only on a trusted network and don't expose the listening port to public networks. On the connected device, enter the phone's local network address and the correct port.

After troubleshooting, test three states separately: foreground use, recovery after locking the screen, and network switching. Keep any necessary background permissions, disable temporary LAN listening, and restore your usual mode. If the issue persists, note the device OS, client name, affected network type, error time, and steps you've already tested. That's enough to help diagnose the problem; don't include the original subscription. For setup, return to the Quick Start Guide; for unfamiliar concepts, see the glossary.