Clash Troubleshooting Guide

No internet: separate local network access from the proxy route

Check your connection with the proxy off

If no pages load in your browser, turn off the client’s system proxy and TUN mode, then test a site that normally works without a proxy. Quitting the client may not clear a manual proxy left in your system settings, so check the OS network settings too. If you still can’t get online with the proxy off, check Wi-Fi, Ethernet, the router, and any required network sign-in before changing nodes.

Hotels, campuses, and public Wi-Fi often require you to sign in through a captive portal. A proxy or custom DNS can interfere with the redirect, leaving you connected to Wi-Fi but unable to browse. Pause the proxy, complete the sign-in, then turn the client back on. If other devices on the same network also can’t connect directly, fix the network first. Proxy testing is only useful once your direct connection works.

Use an explicit proxy request to pinpoint the failure

Restart the client, confirm the core is running, and check the mixed port actually in use in Settings. The commands below use a common local port; change it if your port differs. The first command bypasses proxy environment variables; the second explicitly uses the local HTTP proxy. On Windows, use curl.exe; on macOS and Linux, use curl to avoid invoking a different command alias.

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

Replace the test URL with a site you know is reachable on your current network, and use the same URL for both requests. If the second command immediately returns a connection refused error, check the local listening port or core. If the proxy request returns an HTTP response but your browser still fails, check browser extensions, system proxy settings, and the app’s own network settings. A website returning an access-denied status code does not mean the proxy connection failed.

Check the mode, policy, and rules that actually match

If the local port accepts connections but the destination site won’t load, check whether you’re in Rule, Global, or Direct mode. In Rule mode, check the connection log for the matched rule and policy group; the node selected on the main screen may not be the one in use. A nested policy group may still point to a dead node, or an earlier Direct rule may be taking the traffic. Check the destination domain, matched rule, and final outbound in the connection log.

You can briefly switch to Global mode and manually select a known-working node as a comparison. If Global mode works but Rule mode doesn’t, focus on rule order, rule-set loading, and DNS. If both fail, check the node route first. Global mode is a diagnostic tool, not a permanent fix for every issue. Switch back to your usual mode after testing, then fix the specific rule so traffic that should connect directly doesn’t go through the proxy.

Recovery steps and when to stop

If only a few sites fail, check whether the service is down, restricts access by egress region, or requires a specific account. For browser certificate errors, check your device’s date and time zone; don’t disable certificate validation. If you use another VPN, accelerator, or security tool, quit one of them before testing. Multiple apps changing the default route can send traffic along conflicting paths.

After each step, retest the same URL and note the results for direct access, an explicit proxy request, and browser access. Once all three work, turn other network tools back on one at a time. If you need help, share the exact error and where it occurred—not just “connection failed.” Once your connection is back, check the system proxy setup guide for everyday use.

Node timeouts: distinguish failed probes from unusable nodes

Find out which test is timing out

A client’s node latency test usually sends a request to a specified URL and measures the response time. It isn’t a full download speed test, and it doesn’t guarantee that every app can reach every destination through that node. The test URL may be restricted, return unexpected content, or exceed a short timeout. Try the node with the service you actually need before deciding whether the probe is misconfigured or the proxy route is unavailable.

If webpages load but only the speed test times out, check whether the test URL is reachable and uses the expected protocol. Prefer the test method recommended by the client or subscription provider. Don’t run repeated batch tests to check a single node; concurrent probes can trigger connection limits and use up network resources. Test one node at a time, wait for the result, then compare it with a known-working node.

Use the log stage to check the server connection

Different errors in the connection log point to different stages: DNS resolution failure, connection refused, handshake failure, and read/write timeout. A resolution failure means the server address hasn’t been found. Connection refused usually means nothing is accepting connections on the target port. A handshake failure may involve protocol settings, credentials, device time, or network interference. Save the full error chain, especially the underlying cause—not just the red status in the interface.

On Windows, use the command below to check whether the TCP port for a subscription node is reachable. Replace the address and port with the actual node details. This only tests whether a TCP connection can be established; it doesn’t confirm proxy authentication. For nodes that primarily use UDP, a failed TCP test alone doesn’t prove the node is down. Don’t post node details in public forums.

Test-NetConnection -ComputerName example.com -Port 443

If the server uses a domain name, check that it resolves to the expected address type. Some networks only support IPv4 but try an unreachable IPv6 route first, causing a delay before failure. If you record the original settings, you can temporarily adjust the client’s IPv6 options to compare. Don’t remove the server domain from the subscription: some protocols also use it for the TLS handshake.

Check protocol settings and subscription status

If the node connects at the network level but fails during the handshake, refresh the subscription and check your account status, expiry date, and device limits. When copying a node manually, it’s easy to miss fields such as cipher, transport type, server name, path, or public key. Reimport a complete configuration supported by your current client rather than piecing together settings from another node. Similar-sounding fields aren’t necessarily interchangeable across protocols.

Some newer protocols require a more recent core. Seeing a node name in the interface doesn’t mean the underlying core can load all its settings. Check startup logs for unsupported proxy types or fields. If you’re using the discontinued Clash for Windows or ClashX Meta, keep your original configuration and test with a maintained client from the client downloads page. Clash Plus is the recommended general-purpose option.

Narrow down the issue by comparing networks and nodes

If the same device works on a phone hotspot, check the original network’s egress, sign-in requirements, routing, and firewall first. However, a hotspot may use a different IP stack, so this alone doesn’t prove that a carrier is blocking the node. Keep the client and configuration unchanged, then compare DNS results and the stage where each connection fails to separate network differences from configuration issues.

If only one node fails and others work, stop changing global DNS and system proxy settings; focus on that node’s availability and settings. If all nodes fail across multiple networks, check your subscription account and client compatibility. An automatic policy group may keep switching back to a bad node, so pin a single outbound while troubleshooting. Once it’s working again, see Policy Group Types and When to Use Them to tune the health checks.

Subscription failures: check download, parsing, and activation separately

First, identify which step failed

Importing a subscription involves several steps: fetching the URL, parsing the configuration, downloading referenced resources, and enabling the configuration. An error when you click Update doesn’t necessarily mean your current configuration is broken; some clients keep the last successfully updated version. Check the profile’s last-updated time and whether it’s enabled, then read the error details. Don’t delete your only working profile and lose the network route you need to update it.

When copying a subscription URL, check for spaces, line breaks, non-ASCII punctuation, or extra text added by a chat app. Query parameters may act as credentials, so don’t remove them or share the URL publicly. If your provider requires you to sign in to generate a dedicated subscription, use that page rather than your account homepage. A regular webpage URL may open in a browser but still not return a configuration the client can parse.

Troubleshoot download failures and update loops

For a request timeout, connection reset, or resolution failure, first check that the subscription domain is reachable. Then check whether the client fetches updates directly, through the current proxy, or via a custom download route. If the subscription service isn’t reachable directly but an old node still works, you can temporarily route the update through that profile. If the old proxy is down, forcing updates through it creates a loop; switch to a reachable download route instead.

Authentication failures and access denied errors usually mean you should check the URL, account limits, or whether you need to generate a new link with your provider. Too many requests may result in a temporary block; repeatedly clicking Update won’t speed things up. If the log reports a certificate error, check the system time and network sign-in first. Don’t permanently skip certificate validation to keep subscription updates working; it hides the cause and weakens connection security.

Tell configuration format errors apart from core compatibility issues

If a YAML parse error appears after a successful download, check indentation, colons, and quotes near the reported line. YAML uses spaces for indentation; a tab pasted into the file or a non-ASCII colon in a key can make it invalid. The reported location may only be where the parser stopped—the real problem could be on the previous line. Restore the last working file and fix a copy rather than rewriting the entire subscription.

A login page, maintenance page, or structured error response may have been saved as a configuration file, causing a parse error. Check the start of the response to see whether it looks like a configuration before changing indentation repeatedly. For protocol compatibility, choose a format labeled for Clash or mihomo by your provider, and make sure your current client’s core supports the relevant fields.

If the node list is present but the profile won’t activate, check whether rule sets and proxy providers loaded successfully. The main configuration, node provider, and rule provider may each come from a different URL; a failure in any one can affect the result. If the log names a specific resource, check its URL, access method, and format instead of assuming the main subscription URL is broken.

Keep custom rules and protect your credentials

Subscription updates typically overwrite remotely managed fields. Save ports, LAN access settings, and custom rules using the client’s supported override, merge, or extension mechanism. Check the client documentation for the exact processing order. Direct edits to a downloaded file may only last for the current session. After an update, confirm your custom rules are still present and check the connection log to verify they actually match—not just that the text is there.

Check the source and purpose of remote resources and scripted extensions in your configuration. A subscription URL is a credential, and conversion services may also access node information; don’t share it with an untrusted site. See Subscription Conversion FAQs for when conversion is needed and which formats to use. For the basic import process, see the subscription import guide.

Slow speeds: compare the node, route, and device in sequence

Track wait time, latency, and throughput separately

Long waits before a page opens, interrupted video, and slow downloads can have completely different causes. A long initial wait often involves DNS, the handshake, or rule-set loading; sustained download speed depends more on link bandwidth, congestion, and limits at the destination server. A node’s latency test measures request time, not available bandwidth. Even a low-latency node can slow down at peak times, so latency alone doesn’t prove a speed problem.

Keep the device, destination, test method, and time window the same, and change just one variable. Compare two nodes using the same file or service, then keep the node fixed and switch networks. Speed tests can use significant data or trigger server-side throttling, so check your data allowance first. Don’t run cloud sync, system updates, and a bandwidth test at the same time; the results may reflect competition for local resources.

Start by comparing nodes and egress routes

If only one node is slow, check whether nodes in the same region or on different routes show the same problem. Nodes in the same region don’t necessarily take the same route, and different names don’t guarantee separate egress. If speeds drop in the evening and recover later, congestion or server load may be the cause. If speeds stay near the same limit all day, check your plan, destination service, router limits, and local connection speed before blaming the client.

If only one site or download source is slow, compare it on another node. Some CDNs choose a server based on DNS or your egress IP, so changing nodes may send you to a different edge server and noticeably change speeds. Tune the policy for that service instead of routing all traffic through Global mode. Check which rule matches before creating a dedicated policy group for the service.

Check local resources and connection type

Check CPU usage for the client core, browser, and security software in Task Manager or Activity Monitor. High throughput, complex rules, and many concurrent connections can increase CPU load; verbose logging also increases disk writes. Return to the normal log level once you’ve finished troubleshooting. If CPU usage is near 100% while network use remains low, investigate a local bottleneck instead of chasing a supposedly faster node.

Weak Wi-Fi, interference, Bluetooth coexistence, and an underpowered router can all cause inconsistent speeds. If possible, compare with a wired connection and pause bandwidth-heavy tasks on other devices. When switching between system proxy and TUN mode, confirm the app uses the same node in both. If the modes use different rules or DNS routes, their speed difference doesn’t prove that one connection method is inherently faster.

Adjust concurrency, MTU, and automatic policies with care

More concurrent connections can’t increase the link’s underlying bandwidth and may hit server connection limits sooner. Adjust concurrency based on the current core documentation and how your apps behave; don’t copy settings from a different protocol. If small pages load but large downloads stall, or only one tunnel has problems, check the path MTU. First compare results with other VPNs off, then record the original value and test small changes.

Avoid blindly applying a fixed MTU value found online. Different network connections and tunnel encapsulation result in different effective payload sizes. Lowering the MTU may only work around the problem temporarily or add overhead. If you’ve confirmed the issue is TUN-related, follow the client’s diagnostics for fragmentation and routing, and keep a way to restore the original settings. An occasional slow webpage isn’t enough reason to change the system network stack.

An automatic speed-test policy group may switch nodes when probe conditions change, but existing connections might not move to the new outbound. Pin a node for testing, then restore the automatic policy when you’re done. For a more detailed diagnostic workflow, see How to Troubleshoot Slow Clash Speeds. For the speed test and basic comparison method, see the node latency test guide.

DNS issues: check the resolution path and connection address

Use the error message to decide whether DNS is involved

If the log says DNS resolution failed, host not found, or DNS query timed out, check the resolution step. If authentication fails only after connecting to the destination IP, changing DNS probably isn’t the first thing to try. Some sites loading while others keep waiting may point to DNS, but a service outage, a misapplied rule, or an unreachable IPv6 route can look similar. Check the connection log to tell them apart.

System DNS, browser Secure DNS, the client’s built-in DNS, and resolution on the proxy server may all be in play. A command-line tool may not get the same address as your browser. Map the request path first: which resolver the app queries, whether the query enters TUN, whether the client returns a mapped address, and which outbound makes the final connection. Changing system DNS alone may not affect queries handled by the browser or client.

Understand fake-ip and real address resolution

With fake-ip enabled, the client returns a mapped address from a reserved range, then maps it back to the corresponding domain during the connection. This doesn’t mean the domain resolved incorrectly, and you shouldn’t use that address to test public internet access. What matters is whether the app’s connection still reaches the same client after receiving the mapped address. If DNS goes through the proxy but the connection bypasses the client, the app may get a mapped address it can’t reach.

Apps that need LAN discovery, use special domains, or validate DNS results themselves may not work well with fake-ip for every domain. Configure exceptions for specific domains instead of disabling the entire DNS setup. The snippet below shows how the fields relate; it isn’t a complete configuration. Use the local loopback address for the listener, and make sure its port isn’t already in use. Before applying it, check whether the client’s override mechanism will replace these fields.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

The DNS resolver in this example illustrates the syntax and may not be reachable on every network. Choose a service that works reliably on your network and meets your privacy requirements. Configuring a listener on a local port doesn’t automatically send system queries to it; you also need TUN DNS interception or another explicit forwarding mechanism. Don’t expose the DNS listener on every network interface just to intercept queries.

Avoid startup loops with encrypted DNS

When using a hostname-based upstream such as DoH, the client may need to resolve the upstream’s own hostname first. If that resolution depends on a proxy that hasn’t started yet, or on the same upstream, startup can get stuck in a loop. Follow the core documentation to configure a reachable bootstrap resolver, and check which resolver handles proxy node hostnames. Whether a field is supported and follows routing rules depends on the current core behavior.

A custom Secure DNS setting in your browser may bypass system resolution rules, making the client’s routing rules differ from the actual connection address. Record the original setting, then temporarily switch the browser to use system DNS for comparison. If that fixes the issue, decide whether to configure a separate resolver for the browser. Corporate intranet domains may only resolve through a designated DNS server; a public resolver isn’t a universal substitute.

Confirm the configuration is fixed before clearing caches

After changing DNS settings, existing connections and browser or system caches may retain old results. Close the relevant tabs or app connections, then refresh the cache using a method supported by your OS. On Windows, run the command below. Cache services and commands on other platforms vary by system, so don’t copy it blindly. Clearing a cache only triggers a new lookup; it won’t fix an unreachable upstream or a misapplied rule.

ipconfig /flushdns

Recovery means the same domain resolves as expected along the intended path and the service connects reliably. In Rule mode, check that the domain rule matches before a broad IP rule. For more on how GEOIP, GEOSITE, and rule sets work together, see Practical Rule-Based Routing. Avoid using repeated DNS changes to cover up a rule design problem.

System proxy not working: check ports, apps, and TUN

First, tell the two traffic interception methods apart

A system proxy tells apps that follow system settings where to send proxy requests; it doesn’t capture every network connection. Some command-line tools, games, and apps manage their own networking and ignore it. TUN routes eligible traffic through a virtual network interface, usually covering more apps, but it also depends on permissions, routes, exclusions, and system extension status. Turning on both doesn’t simply combine their coverage.

If your browser works but your terminal doesn’t, check whether the terminal app supports the system proxy or proxy environment variables before assuming the client is broken. If a command with an explicit local proxy works but all browsers fail, check whether the system proxy is set on the right interface, whether a browser extension configures a separate proxy, and whether the app has cached old settings. Test the simplest route first, then re-enable other tools one at a time.

Port settings and listening addresses

The mixed port accepts both HTTP and SOCKS proxy requests. The external controller port is for the management API; they serve different purposes. Entering the controller port in a browser’s proxy settings won’t usually forward web traffic. A port shown in Settings is only the configured value; check the startup log to see whether the client is actually listening. If the port is already in use, the core may fail to start or prompt you to choose another port.

For local use, the proxy address is usually 127.0.0.1; there’s no need to allow LAN access. This snippet only shows the local proxy listener and doesn’t include a working node. After editing the configuration, reload it and check that the system proxy uses the same port. If the client has a separate port setting, change it in the interface to avoid a remote subscription update restoring the old value.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

Find port conflicts and TUN route conflicts

On Windows, use the command below to see which process is listening on a port, then confirm its identity in Task Manager. Don’t kill an unknown process just because it’s using the port. First exit an old client, a leftover core process, or another proxy tool, then restart the client you’re troubleshooting. After changing the port, update the address in your browser, terminal environment variables, and other devices on your LAN; otherwise, they’ll still connect to the old listener.

netstat -ano | findstr :7890

If all connectivity drops after enabling TUN, turn TUN off first and check whether the system proxy works. Then confirm that the client has permission to create a virtual network interface. Other VPNs, container networks, and corporate security software can use overlapping routes or change interface priority. Compare with only one tool controlling the default route at a time. Don’t delete network interfaces or clear all routes, which can make the problem worse.

Restore connectivity after quitting and enable LAN access safely

After a client exits unexpectedly, your system may still point to a local proxy that’s no longer running. Turn off the manual system proxy and confirm that your browser connects directly. If a proxy auto-configuration script is in use, check that too. Normal exit and force-quitting may clean up settings differently. Once connectivity is restored, test a full start-and-stop cycle to make sure the settings follow the client’s state.

For another device to use your computer’s proxy, enter the computer’s LAN address—not the phone’s loopback address. Enable LAN access only when you need to share the proxy, and restrict it to trusted networks and necessary devices. Don’t expose the management API. For setup details and firewall considerations, see Mixed Port and LAN Access Settings. For local use, see the system proxy guide.

Client crashes: distinguish interface, core, and configuration issues

Find out which part has stopped

A closed window, missing tray icon, and stopped core aren’t the same thing. Some clients keep running in the background after the window closes; in other cases, the interface remains open after the core exits. Check the system tray, running processes, and local listening port before deciding that the app crashed. An interface that can’t connect to the service may mean the management API address changed or the background service hasn’t started—not that the whole app is damaged.

Note what you did just before the crash: imported a configuration, updated a subscription, enabled TUN, switched networks, or resumed from sleep. A reliable way to reproduce the issue is more useful than a screenshot on its own. Save the client logs and system application error records, and check that their timestamps match. If the core reports a configuration error before the interface disconnects, fix the configuration before reinstalling the interface app.

Narrow down the configuration without losing your data

If the app exits as soon as it starts, back up the configuration directory and custom overrides first. Then try the client’s option to disable or reset the configuration. Data locations vary by app and OS; find them in the client documentation or logs rather than deleting an entire user directory with a similar name. If you need to move files manually, stop the client and background service completely, and keep the original directory so you can restore it.

If the interface opens, disable recently added rule providers, scripted extensions, or complex overrides, then re-enable them one at a time. A minimal configuration helps identify the part causing the problem; it isn’t a reason to manually piece subscription credentials back together. If removing a field fixes the issue, check whether the current core supports it, whether it’s being merged twice, and whether its referenced file path is valid before calling it a client bug.

Check OS compatibility, permissions, and system resources

The installer architecture must match your device. Don’t use Windows, macOS, and Linux builds interchangeably just because their filenames look similar. On Linux, also check the distribution’s package format and desktop runtime dependencies. If the app won’t start, read the specific OS error. Use the client download for your platform on the downloads page. Clash Plus is the recommended general-purpose option; don’t replace the executable with one from an unknown source.

macOS may require you to approve network-related components in System Settings; the Windows TUN service may require administrator permission. Follow the OS prompts if authorization fails rather than leaving system protections disabled. If security software quarantines a file, check the alert and its reason, then verify the download source and app identity before taking action. Don’t add an entire drive or user directory to the exclusions list to work around one app’s startup issue.

If the client crashes after running for a long time, check memory use, connection count, and available disk space. Too many connections, repeated retries, overly verbose logs, or uncontrolled resource updates can all consume more resources. Lower unnecessary logging and stop duplicate tasks, then see whether stability improves. Clear caches using a client-supported option. Before deleting a database or configuration cache manually, stop the core to avoid corruption from an interrupted write.

Update, roll back, and submit useful details

If the problem started after an update, check whether the configuration format changed, a new feature was enabled, or the default DNS settings changed at the same time. Back up your current data, then test a maintained client with a separate configuration. Don’t let two apps enable the system proxy and TUN at once. If you need to roll back, use a trusted installer compatible with your existing configuration, and make sure an older client won’t overwrite data in the newer format.

When reporting an issue, include the OS, device architecture, client name, reproducible steps, and redacted logs. If the interface shows the actual version, include it; don’t guess based on the installer filename. Keep the error type and stage in the logs, but remove node credentials. Cutting the logs down to just “failed” removes the detail needed to diagnose the issue. For configuration sync and backup options, see Comparing Configuration Sync Across Devices.

Recovery means more than seeing the window open again. Confirm that the core starts, the port listens, the subscription updates, and a real connection works before turning previously disabled features back on. If re-enabling an extension reliably reproduces the problem, leave it off and check its compatibility requirements separately. There’s no need to repeatedly wipe all client data for an issue you can isolate.

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

Check which VPN is active and whether another app is using it

A VPN icon on your phone only indicates that a system VPN connection is active in some form. It doesn’t prove that the subscription node, DNS, or destination service is working. Open the client to check the active profile, selected policy, and logs, then test the same webpage. If the status icon belongs to another VPN, ad blocker, or corporate network app, identify which app actually controls the connection before assuming Clash is active.

Android clients usually route traffic through the system VPN interface and require your permission the first time they connect. Other apps using the same interface may compete for the connection. Some devices also have Always-on VPN or a setting to block connections that don’t use the VPN. If the original client stops, these restrictions can leave the whole device offline. Check the system VPN settings first, note their original state, and then decide which restriction to disable temporarily.

Troubleshoot Android background interruptions and app routing

If the connection drops after the screen locks or takes a while to recover when you switch apps, check whether battery optimization or background restrictions are stopping the client. Use the OS settings to allow the background activity and notifications it needs, then see whether the issue improves. Don’t disable background limits for every app just for one networking app. Settings vary by device; check whether the process is still running, whether the VPN reconnects, and whether the logs show a restart.

When using per-app proxying or exclusions, check whether you’re looking at an include list or an exclude list. An app may bypass the proxy because it’s excluded, not because the rules are broken. You may need to reconnect after changing the list, and some apps keep their existing network session. Fully close the target app, then reconnect and test. Work profiles, app clones, and personal profiles may be separate user environments, so don’t assume one list applies to every copy.

If Wi-Fi works but cellular data doesn’t, check whether the client has permission to use mobile data, whether Data Saver is on, and whether the current network has a working IPv4 or IPv6 route. Don’t copy your computer’s listener address or system proxy setup: a phone’s built-in VPN connection and a proxy shared from a computer are two different paths. When comparing them, turn off the other path first to avoid confusing results.

Check iOS network extensions and reconnect after network changes

When using Clash Plus on iOS, make sure the system has allowed it to add a VPN configuration and that the enabled profile belongs to the app. A managed corporate network profile or another on-demand connection setting may activate a different connection when the network changes. Don’t remove profiles from a managed device without permission. Check with the administrator about what you can change, then test one connection at a time.

After switching from Wi-Fi to cellular, an existing connection may have stopped working even though the app still holds the old session. Stop and reconnect the client, then close and reopen the target app to see whether it recovers. If the issue only appears after sleep, note the network type, client status, and error time before and after the transition. One successful reconnect doesn’t prove the node is healthy. See the iOS download guide for the client.

Distinguish LAN proxy sharing from a mobile device’s own proxy

To use a proxy shared from a computer, your phone must be on a network that allows devices to communicate, and you must enter the computer’s current LAN address and proxy port. Sleep, an IP address change, guest network isolation, or a firewall can suddenly block access. On your phone, 127.0.0.1 points back to the phone itself, not the computer. Devices on the same Wi-Fi network name may still be isolated, so check the network’s client isolation settings.

When scanning or copying a subscription to your phone, make sure you’ve got the complete subscription URL, not a link to a shared webpage. If your phone and computer use cores with different capabilities, you may need the appropriate subscription format for each. Don’t keep two configurations working by repeatedly deleting fields by hand. After updating, check custom rules, per-app routing, and DNS behavior on each device; a successful sync doesn’t mean all platform settings are identical.

To confirm mobile connectivity is restored, test browsing in the foreground, again after briefly locking the screen, and once more after switching networks and reconnecting. Keep only the necessary proxy features on during testing; restore automatic policies and app routing after the connection is stable. If problems persist, continue with the subscription, DNS, and node sections earlier on this page. For general questions, see the FAQs. For a first-time setup, follow the full setup guide.