Clash Troubleshooting Guide

No internet access: separate direct, proxy, and rule-based traffic

“No internet after opening Clash” can have several causes. Your browser may still be pointing to a local proxy that has stopped, or the core may be listening normally but have no working outbound route. First note which apps are affected, whether all sites fail, and whether access returns after you close the client. A single site failing calls for a different approach than a system-wide outage. Don’t start by reinstalling the app, wiping the configuration, or changing system DNS: changing several conditions at once makes it harder to identify the cause.

Restore direct access, then check the local proxy

Turn off the system proxy and TUN mode in the client, then exit it normally. Check your operating system’s network settings for a leftover manual proxy, then try a site that normally works without a proxy. If it still fails, check whether you completed the Wi-Fi sign-in page, whether the gateway is reachable, and whether other devices are also offline. The issue is not yet isolated to Clash, so restore the basic connection first. On a managed device or workplace network, keep the original automatic configuration script and proxy settings; don’t remove organization-managed policies.

Once direct access works, launch just one client and leave TUN off for now. Check the runtime log for a successful configuration load and note the mixed port shown in settings. The example below tests a local HTTP proxy listening on port 7890; replace the port number if yours differs. This request only checks whether the proxy path gets a response; it doesn’t prove that every app is using the proxy. Even a redirect means the request received an HTTP-level response.

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

In Windows PowerShell, use curl.exe with the same arguments to avoid invoking another command with the same name. If it can’t connect to the local port, check that the core is running, the port hasn’t changed, and security software isn’t blocking the local listener. If the local connection succeeds but the subsequent handshake times out, the issue is beyond app proxy settings; check the outbound node under Connection timeouts. Don’t keep switching browser proxy extensions.

Switch modes to see whether rules are causing the issue

With the system proxy enabled, test the same URL in rule mode, then temporarily switch to global mode and make sure the global policy group has a working node selected. If global mode works but rule mode doesn’t, check the matched rule, policy group target, and whether the rule database loaded. If both fail, start with the node, DNS, and local connection. Global mode still requires the app to use the client; it won’t automatically capture programs that ignore the system proxy. The mode name alone doesn’t tell you how traffic is routed.

Open the connections list, find the domain you just visited, and check the matched rule, outbound policy, and error log. If the outbound is DIRECT but that destination isn’t reachable directly, fix the rule rather than leaving every domain in global mode. Rules are usually matched in order, so an earlier, broader rule can take precedence over a later, more specific one. Before editing, make sure the policy name exists in the active configuration and matches a node or policy group name exactly.

Narrow down changes to the affected scope

If only one browser fails, compare it with a browser that has no proxy extensions, and check extensions, independent DNS settings, and cache. If only one site fails, check for maintenance, certificate errors, or account restrictions. For a certificate warning, verify the system clock first; don’t disable certificate validation to “restore access.” See HTTPS certificate errors: causes and fixes. Don’t mistake a site’s access-denied page for a complete local network outage.

Connection timeouts: separate DNS, connection, and handshake failures

A timed-out node test only means that one test request didn’t finish within the time limit; it doesn’t prove the node is down. The test URL, DNS, server port, protocol handshake, or target site could all produce the same result. Test a single node with a real connection, then compare it with the logs from when the issue occurred. Don’t repeatedly test an entire subscription: many concurrent tests can trigger rate limits and clutter logs with errors unrelated to your current request, making individual connections harder to diagnose.

Find which stage produced the error

Temporarily set the log level to info and note the time and target of one failed request. If the node hostname can’t be resolved, check DNS first. If the connection to the server address times out, check whether the current network can reach the server. If the connection succeeds but TLS or authentication fails, verify the protocol settings, system time, and subscription status. Use debug briefly if needed, but don’t leave verbose logging enabled or post logs containing full addresses and authentication details publicly.

Read error messages in context. The same timeout may come from connecting to the node or waiting for the destination site. Check the remote address in the log to tell whether it belongs to the node server or the destination. Fields vary by core and client, so don’t draw conclusions from a single English keyword. See How to read Clash runtime logs and organize one request by time, target, policy, and error.

Narrow the cause with a one-variable comparison

Keep the client and configuration unchanged, switch the device from its current Wi-Fi network to a phone hotspot, then test the same node and URL. If the hotspot works but the original network doesn’t, focus on that network’s egress, firewall, or DNS. If both fail, compare with another node. If only certain nodes fail, ask the provider about maintenance, account expiration, or connection limits. Don’t replace your entire system network configuration because one node has a problem.

On Windows, use Test-NetConnection to check a known server’s TCP port; on macOS or Linux, use nc. Use the server address and port from your own configuration, and never paste node credentials into a public terminal. A reachable TCP port only proves that a connection can be established; it doesn’t confirm that the application protocol, authentication, or forwarding works. A TCP test can’t establish whether UDP-based transport works, either. A node may still proxy traffic even if ICMP ping is blocked.

Check protocol support and automatic selection

A successful configuration import doesn’t mean the current core supports every protocol field. For configurations from another client, converted subscriptions, or newer protocols, check the logs for an unknown type, missing field, or incompatible handshake. Update to a release that is still maintained by the project you use, or ask the provider for a configuration that explicitly supports your core. If you need a different client, see Clash Plus on the Download page, then check protocol support for your needs instead of mixing in core files from unknown sources.

An automatic selection policy may still be using its previous test results or a probe URL that doesn’t reflect your actual traffic. Temporarily select a verified node manually, disable automatic switching for this test, and check a real connection. If connections start successfully but drop only under heavy traffic, also check packet loss, path MTU, and server limits; shortening the test interval won’t help. When troubleshooting is complete, restore the original test policy and confirm that new connections use the selected node.

Subscription errors: check download, parsing, and activation separately

A subscription update involves three separate steps: downloading the content, parsing it into a configuration, and loading the selected configuration into the core. A successful download that isn’t activated is different from a subscription that can’t be fetched at all. Check the last update result on the configuration page and the runtime log to find which step failed. Don’t repeatedly delete and re-add the subscription; that could also remove local overrides, rule selections, and saved settings, and make a working cached configuration impossible to restore.

If the content can’t be fetched, check the URL and connection path

Copy the full subscription URL again from the provider’s account page. Check the beginning and end, and make sure no line breaks were included when copying. If you scanned a QR code, confirm that it contains a subscription URL rather than a webpage address. Subscriptions often contain access credentials, so don’t upload them to online testing sites or public conversion services. To report an issue to support, share the error code, time, and a redacted domain; the URL path and query parameters may also contain sensitive information.

Handle HTTP status codes according to what they mean. For authentication errors, first check that the account and URL are still valid. For rate limits, wait before updating again. For server errors, keep the current configuration. Being able to open the provider’s website in a browser doesn’t mean the subscription endpoint is reachable; they may use different domains and authentication. A page displaying content also doesn’t prove the configuration is valid: a login or verification page can return a success status too.

If the subscription domain is only reachable through a proxy, connect with an existing working configuration before updating. If the client forces subscription downloads to use a direct connection, check its download settings. Conversely, forcing a download through a proxy that’s already broken can create a loop. Use the client’s direct or proxied option for a controlled comparison. Don’t run multiple clients to “chain” connections; they can override each other’s local ports and system proxy settings.

Content downloaded, but the format is invalid

When parsing fails, first distinguish a complete YAML configuration, a node list, and a client-specific sharing format. They aren’t always interchangeable at import. A complete configuration belongs in configuration management; a proxy provider needs to be referenced by a main configuration. Importing a node list as a main configuration with policy groups and rules can cause missing-field or unknown-policy errors. Check the provider’s import instructions and choose a link explicitly compatible with your client; don’t rely on the file extension alone.

YAML is sensitive to indentation and data types. When editing by hand, use spaces, not tabs; keep list items at the right level under their parent field; and avoid full-width colons or curly quotes copied from chat apps. The reported line is usually where the parser noticed the problem, not necessarily where the missing character belongs; it may be on the previous line. Don’t replace every quote just to fix one indentation issue: passwords, regular expressions, and names with special characters may need their quotes.

After an update, confirm which configuration the core actually uses

Return to the configuration list, select the updated entry explicitly, and check the logs for a completed reload. Some clients don’t switch to an updated file automatically, and the node list shown in the interface may come from a different configuration. Verify the policy group name and the outbound used by a new connection. Don’t use a tab that’s been open for a long time as your only test; existing long-lived connections may keep their old policy. Close the test tab and make a fresh request.

If nodes are present after an update but rules are missing, check whether a local override replaces the entire rules or proxy-groups list. Array replacement and merge behavior depend on the client; don’t assume they all work the same way. Temporarily disable one override to see whether the issue comes from the subscription or the merge result. Once fixed, put settings that must persist in a supported override location to prevent the next update from replacing them.

For help choosing an import method or selecting a configuration, see the installation and configuration guide. For format differences and routine update questions, see the Help Center’s installation and configuration FAQ. Once subscription downloads work again, set a sensible update interval; frequent refreshes aren’t a general fix for node timeouts or account issues.

Slow speeds: separate response latency from sustained throughput

Slow webpages, video buffering, and slow large downloads can have entirely different bottlenecks. The node latency shown in a speed test mainly reflects how quickly the test request gets a response; it doesn’t measure available bandwidth or guarantee a good CDN route to a particular site. First identify whether the delay is at initial load, throughout the transfer, or limited to one type of app. Compare under the same network, to the same destination, and within the same time window. Don’t compare node performance using results from different sites or files.

Rule out local network issues and background traffic first

Pause system updates, cloud sync, and other downloads. Check that the Wi-Fi signal is stable, then test the same destination again. On a laptop, compare with a wired connection; on a phone, compare Wi-Fi with cellular. If direct connections are also slow, check the local network and ISP egress. If only the proxy route is slow, compare nodes. Run tests one at a time: several speed tests at once compete for bandwidth, and connection counts can skew the results.

Check CPU and memory usage on the device running the client. Low-power routers, older phones, and virtual machines may be limited by protocol encryption or virtual network overhead; one core may stay busy as throughput rises. Low overall CPU usage doesn’t rule out a compute bottleneck. If the same node performs normally on a standard computer but is much slower on a router, check device resources and configuration complexity rather than repeatedly changing DNS servers.

Use connection logs to confirm the actual outbound route

Open the connections list and check which policy handled the slow request. Automatic selection, load balancing, and fallback groups can send different requests through different exits; browsers may also reuse connections made before a switch. For a test, select one fixed node, stop the old download, start a new request, and record the result. Global mode is useful for comparing rules, not for permanently hiding a rule mismatch. Don’t route large local services through a proxy if they should connect directly.

If the homepage loads quickly but images or video are slow, check the domains used by those page resources and the rules they match. A page often loads content from multiple sources; a working proxy route for the main domain doesn’t mean media domains use the same policy. Mixing direct and proxied requests can cause duplicate connections, inconsistent regions, or the server to select different content. Adjust the rule for the resource that’s actually failing instead of routing every subdomain through the same exit.

Adjust transport and TUN settings with care

Some videos and browsers use QUIC, which usually runs over UDP. If the node or network doesn’t fully support UDP, requests may stall repeatedly or fall back. If you have a specific reason to suspect QUIC, temporarily disable it in the app for comparison, note the original setting, and restore it afterward. A successful TCP download doesn’t prove UDP works; a failed UDP-based app doesn’t mean the whole node is unusable. Choose a protocol based on the app you’re troubleshooting, not just the speed-test ranking.

If the issue only happens with TUN, first compare against TUN disabled and an explicit local proxy. A mismatched path MTU can cause large packets to be retransmitted, but changing MTU isn’t a general fix for slow speeds. Adjust it one setting at a time only if packet captures, network documentation, or repeated tests support that diagnosis, and keep the original value. Don’t change the protocol, DNS, MTU, and outbound node all at once; even if that fixes the issue, you won’t know why, and it may return after an update.

Consider server capacity, account traffic limits, and the destination site’s download policy last. If multiple devices are slow on the same node at the same time, but work again after switching nodes, give the provider the test time, destination type, and symptoms. Distinguishing a slow connection setup from low sustained throughput is more useful than simply reporting “high latency.” There’s no need to run speed tests continuously; stable performance in real use matters more than a single test result.

DNS issues: check where names are resolved and how traffic is routed

DNS problems can appear as certain domains failing to load, node hostnames failing to resolve, long waits before the first connection, or stale addresses after switching networks. First distinguish system DNS, browser-specific DNS, and core DNS: all may be active at once and may use different servers. A successful system lookup only means that the path used by that command works; it doesn’t prove the Clash core got the right result. The browser may also have succeeded by using its own cache.

Compare system results with the client’s connection logs

With proxy interception disabled, look up the target domain and note the resolver and returned address. Then enable the client and check the corresponding connection log. The commands below show the system’s results; they don’t query the core’s DNS service automatically. To query a DNS port listened to by the core, first check the configured listen address and port, then use a query tool that lets you specify a port. Don’t mistake the controller port for the DNS port.

nslookup example.com

With fake-IP enabled, the client may return a reserved mapping address, which the core later maps back to the domain. That result alone doesn’t mean DNS is being poisoned. Check whether subsequent connections are intercepted by the same core and whether the domain mapping is still valid. If an app receives a mapped address but bypasses TUN or the local proxy, its connection may fail. A stale mapping can also cause temporary failures after interception is turned off.

Understand bootstrap resolution and upstream access

The hostname of an encrypted DNS server also has to be resolved first. If the request used to resolve the node hostname depends on a proxy that hasn’t been established yet, the two can form a loop. Check whether the DNS upstream is reachable and which resolver handles the node hostname before checking rule-based DNS routing. Don’t paste a full DNS configuration from the web over your subscription. In particular, verify that the current core supports fields such as proxy-server-nameserver and check whether the existing configuration already does the same job.

This is a partial example of fields for clients using mihomo. It shows how regular domains and proxy server hostnames can use different resolvers; it isn’t a complete configuration. It doesn’t enable TUN or define a DNS listener, so it won’t intercept system lookups on its own. When merging it, edit the existing dns section; don’t add a second top-level key with the same name at the end of the file. Parsers may handle duplicate keys differently.

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

The upstream servers in the example must be reachable on your network; no public resolver is the right choice for every network. Workplace, campus, and home LANs may also need dedicated DNS to resolve internal names. Replacing all upstreams may restore access to public sites but break printers, internal systems, or local domains. Preserve the internal DNS route for the relevant domains instead of continually adding public servers; multiple upstreams don’t necessarily work as simple fallbacks in the order listed.

Rule out cache, IPv6, and false DNS leak alarms

After changing the DNS route, reopen the target app first. If needed, clear the system DNS cache before testing a new connection. On Windows, use ipconfig /flushdns; on Linux with systemd-resolved, use resolvectl flush-caches. For other systems, use the appropriate service. Clearing the cache removes stale results but won’t fix an unreachable upstream. If access returns immediately after a change, check the actual route again before assuming the issue is resolved; the cache may only have changed temporarily.

Assess DNS leaks against your expected routing policy. If a test page shows a resolver, that only tells you which DNS route the test request observed; it doesn’t prove that all your traffic bypasses the proxy. Check whether browser secure DNS, system private DNS, TUN DNS hijacking, and split-routing rules are consistent. Check IPv6 separately: if only IPv4 is intercepted, an app may use a different route over IPv6. Don’t disable IPv6 as a default fix; first confirm what the client and network support.

System proxy not working: check whether the app reaches the core

The system proxy is a set of settings that apps can read from the operating system; it isn’t a network tunnel that captures all traffic. Browsers, command-line tools, games, and system services differ in their support, so an enabled switch only means the client attempted to apply the settings. It doesn’t prove that every program is using them. Open the client’s connections page and make a new request from the affected app. A matching connection record is an important first clue about its route.

First check that the system settings were applied correctly

Check the system network proxy settings and confirm that the address is local and the port matches the client’s mixed port. If the client runs on another device, use that device’s LAN address and configure its listener and firewall separately. 127.0.0.1 is never the address of a remote computer; it always refers to the current device. You don’t need to allow LAN connections for a local browser to use the proxy. Doing so expands the listener’s reach without fixing an incorrect local port.

On Windows, the user proxy settings and the WinHTTP proxy used by some services are separate configurations. On macOS, proxy settings are usually tied to a network service, so check them again after switching to a new Wi-Fi or wired connection. A Linux desktop environment’s global proxy isn’t guaranteed to be used by terminal programs. If a switch keeps turning itself back on, a port reverts, or the proxy address changes repeatedly, check for another proxy client, browser extension, or organization policy managing the settings.

If the log says the local port is in use, identify the program using it before deciding whether to close it or change the port. On Windows, use netstat -ano to view listeners and PIDs. On macOS, use lsof -nP -iTCP:7890 -sTCP:LISTEN to find what is listening on a specific port. Don’t force-quit an unfamiliar system service based only on its PID. If you change the mixed port, update the system proxy, browser settings, and terminal variables too. See How to troubleshoot a port conflict for details.

Test the terminal with a one-off explicit proxy

If a terminal tool doesn’t use the system proxy, specify the proxy for a single command first instead of changing global environment variables. The two commands below use an HTTP proxy and a SOCKS proxy, respectively. In socks5h, the final letter means the proxy resolves the destination hostname; this differs from resolving it locally before connecting and can help compare DNS routes. Before running the commands, confirm that the client supports the relevant protocol. A mixed port usually accepts both types of request.

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

If an explicit proxy works but the default command connects directly, check where the tool gets its proxy settings. Look at HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY, including uppercase and lowercase variants and the tool’s configuration files. Programs vary in which variables they support and the order they read them. NO_PROXY may also exclude certain domains. A working browser with a failing Git command could mean Git has its own saved proxy setting; changing only the system switch won’t fix that.

Configure permissions and routes only if you need TUN

For apps that ignore the system proxy, use TUN as documented by your client, but first confirm that the basic proxy route works. After enabling it, verify that the service has permission and that the virtual adapter and routes are actually in place; don’t rely on the UI switch alone. Other VPNs, virtual machine networks, and container networks can conflict with routes. Disable one related feature at a time for comparison and note how to restore it; don’t delete unfamiliar adapters. If you need to keep a corporate VPN, follow its network management requirements.

If only a browser is affected, check whether an extension controls the proxy, whether the browser uses its own secure DNS, and whether it’s reusing old connections. Testing with a new browser profile that has no extensions is more reliable than private browsing alone, since some extensions can be allowed in private windows. For a full browser and terminal comparison, see Troubleshooting a system proxy that isn’t working. For the basic switch location, see the System proxy section of the guide.

When you’re done troubleshooting, exit the client normally and check that the system proxy has been restored as expected. After a forced quit or power loss, the system may still point to a local port that’s no longer listening, making access fail after the client closes. Reopen the client and turn off the system proxy normally, or restore the original value in system settings. Autostart only controls when the program launches; it doesn’t mean the configuration is loaded, the core is running, or the system proxy has been set. Check each stage separately.

Client crashes: distinguish the interface, core, and system environment

A vanished window, a client still in the system tray, lost connections, and an app that won’t launch can point to different issues in the UI process, core process, or system environment. First check Task Manager or Activity Monitor to see whether the relevant processes are still running, then inspect the latest entry in the client’s log directory. Don’t repeatedly double-click to launch multiple instances or immediately wipe the app’s data directory. The original configuration, error logs, and startup state are often the most useful clues.

Note what triggers the crash and keep a way to recover

Think back to whether the crash happened right after a subscription update, enabling TUN, changing themes, a system upgrade, or resuming from sleep. A repeatable trigger is more useful than “it crashes sometimes.” Back up your configuration and essential app settings, then try launching the client without proxy interception. If the window stays open, restore features one at a time. After a crash, also check for a leftover system proxy; otherwise, browser access problems while collecting logs may look like a separate issue.

Make sure the installer matches your operating system and processor architecture. For macOS, distinguish Apple Silicon and Intel builds. On Linux, also consider the distribution, package format, and desktop environment. If installation fails or the app closes on launch, check the system error. Don’t download runtimes or drivers from unknown sites or replace dynamic libraries manually. If you need another installer, check Clash Plus on the Download page, then compare other maintained clients for your platform and needs.

Treat configuration load failures and app crashes separately

If the UI works but the core keeps exiting, check configuration syntax, referenced files, and rule provider paths. A failed download of a file referenced by the subscription may prevent the configuration from loading fully; moving the configuration directory by hand can also break relative paths. Pause automatic updates, switch back to a known-good backup configuration, and see whether the client stays stable. Don’t remove every rule to “reduce the load.” Start with the specific file or field named in the log and restore items one at a time.

If the client has a configuration check, run it before reloading the core. Command-line core users can use the syntax test command below after making a backup; it checks only the specified configuration and doesn’t replace a normal startup. If the configuration uses relative paths, providers, or external databases, specify the correct working directory for your setup. A GUI client may generate a merged configuration, so checking the original subscription may not produce the same result as checking the configuration used at runtime.

mihomo -t -f config.yaml

Conflicts involving the controller address, mixed port, or DNS listen port can make the core exit immediately after startup. Read the full error, not just the final exit message. Multiple instances, startup tasks, and service mode can compete for the same port. Keep one startup method, confirm no old process is holding the port, then launch again. Don’t expose the external controller port to the public internet to fix a local connection problem; it has nothing to do with this startup issue.

Check permissions, resources, and UI dependencies

If the client exits only after TUN is enabled, check that its service is installed correctly, the system allows the required permissions, and security software hasn’t blocked it. Grant only the permissions needed for a specific program and operation; don’t disable all protection. On Linux, check whether a GUI was run as a regular user or administrator and who owns its configuration files. After launching a GUI as an administrator, a regular user may no longer be able to write to the same directory, causing failures when saving settings or starting the client.

If the client crashes after running for a while, check whether memory use keeps growing, the disk is full, or logs are accumulating. Temporarily close frequently refreshed pages such as connection details and lower the log level to see whether the UI refresh or core connection load triggers the issue. Don’t delete a database file that’s currently being written. Exit the app first, make a backup, and then clear only rebuildable caches as documented by the client. Confirm what a directory contains before clearing it; subscriptions and user settings are not caches.

When reporting a problem, provide the smallest reproducible case: operating system and architecture, client name, steps that trigger the issue, whether TUN is enabled, a redacted error excerpt, and results from a comparison with another configuration. Clash for Windows and ClashX Meta are no longer maintained. If you encounter compatibility problems, consider migrating instead of repeatedly reinstalling archived builds. Save the original configuration and import it in the new client’s format; don’t copy the entire private data directory over.

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

Mobile troubleshooting differs from desktop system proxy checks because it depends on the system VPN, background scheduling, and network changes. First confirm that the app has established a VPN session, then check whether the target app is included in traffic capture. A VPN icon in the status bar usually means the system tunnel exists, but doesn’t prove that node authentication, DNS, or the destination connection succeeded. Keep one known-working node and test both a browser and another app so you don’t judge the entire device’s connectivity from a single app.

Android: check VPN conflicts and background restrictions

Android requires system VPN permission before the client can connect. If it stops immediately after you tap Connect, check whether another VPN, firewall, ad blocker, or packet capture app is using Android’s VPN slot. These apps may use the local VPN API even without a remote server. Stop the other app normally before testing, and don’t keep enabling both back and forth. If a work profile or device management policy is involved, follow its requirements; personal settings may not override the work network.

If the connection drops when the screen locks and returns when you reopen the app, check battery optimization, background permissions, and whether the system is stopping the app. Allow the client to run in the background as needed and check its connection notification. Menu names vary by device manufacturer; allowing notifications alone doesn’t grant all background permissions. First test briefly with the screen on, then lock it and repeat the same task. A failure only after locking points more strongly to a background restriction.

With Always-on VPN or blocking connections outside the VPN enabled, losing access when the client stops may be expected. Check those options in system VPN settings to distinguish a security policy from an app failure. If you need to turn them off for troubleshooting, be aware that traffic may go direct; restore the settings afterward. For per-app proxying, also check the allowlist and exclusion list: an excluded app won’t use the proxy just because other apps are covered.

iOS: check session status and app rules

On the download page, you can find Clash Plus, our recommended option for iOS. Its official site is clashplus.io; for installation, visit the Clash Plus page on the App Store. When connecting, first grant the VPN configuration permission requested by iOS, then return to the app and check the active configuration and policy. If the connection switch turns itself off, check for another VPN or a device profile controlling the network. Don’t start by reinstalling the app.

If only Safari or one app behaves differently, check its network settings, cache, and privacy features that may affect its traffic route. iCloud Private Relay, separate DNS settings, or other network extensions can make the observed outbound differ from what you expect, but a location label on an IP lookup page alone doesn’t prove the proxy is broken. First check the domain and policy in the client’s connection log. Then, if needed, temporarily pause one feature at a time for comparison and keep a record of the original settings.

Handle switches between Wi-Fi, cellular, and sleep

When switching from Wi-Fi to cellular, an existing connection may drop as the device’s address and routes change. Stop the current download or call and reconnect. If it still fails, disconnect and reconnect the VPN in the app. If the network requires a sign-in page, complete authentication before starting the proxy. Don’t assume that a captive portal failing to open is a node problem; on hotel, airport, and campus networks, a VPN may prevent requests from reaching the local sign-in page.

Check that the client is allowed to use cellular data and whether the system has enabled data saving or background restrictions for the current network. If Wi-Fi works but cellular doesn’t, test the same configuration and destination on both, and check whether the node hostname resolves and is reachable over each network. IPv6, UDP, or path MTU behavior may differ between networks, so don’t copy desktop settings blindly. Compare other transport options on the same node, and give the provider the network type and error time if you need help.

When reimporting a subscription on mobile, confirm that the new configuration is selected; the VPN session may still be using the old one. If the system shows a normal VPN state but one app can’t connect, check its rules and per-app settings instead of granting broader system permissions. For everyday mode selection, see the Rule and global mode guide; for common usage considerations, see the Help Center’s usage tips. Record the permissions, mode, and network conditions that worked so you can check them again after a system update or device change.