Clash troubleshooting guide

No internet access: separate network issues from proxy issues

Test your connection with the proxy off

If no websites load, first exit the current connection state instead of switching nodes repeatedly. Turn off the client's system proxy and TUN mode, then check whether your operating system's proxy settings have been restored. If the client exited unexpectedly, the missing toggle does not mean the system proxy was cleared. Make sure your browser does not have a separate proxy extension enabled, then try a site you can normally access directly and check whether the Wi-Fi network requires a sign-in page.

If the connection still fails with the proxy off, check your router, network authentication, IP address assignment, and settings left behind by other VPNs. Keep the client configuration unchanged and switch the same device to a phone hotspot. If the hotspot works but your usual network does not, the issue is likely related to that network. A connected network icon is not proof of internet access; it usually only means the device has joined the local network.

Use an explicit proxy request to isolate the problem

Once your basic connection works, start the core, temporarily turn off TUN, and keep just one local proxy endpoint enabled. The example below assumes the actual mixed port is 7890. On Windows, use curl.exe to avoid PowerShell environments where curl may resolve to a different command. On macOS and Linux, use curl. Make sure the port matches the client's runtime settings.

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

A connection refused error usually means no process is listening on that local port, or the client failed to start the core. If the local proxy connects but the upstream request fails, see the node troubleshooting section. An HTTP response from the destination server—even an access-denied response—means the request reached the remote server; it is not simply a case of the local proxy being down. This test applies only to that address and request; it does not prove that every site is reachable.

Check the incoming connection and its outgoing route

Open the client's connections page, clear any filters, and reload a page in your browser. If no new connection appears, check whether the app is actually using the proxy, whether it matches a bypass list, and whether the local port is correct. If a connection does appear, check the destination domain, matched rule, policy group, and final outbound node in order. A policy group is only an intermediate selector; expand it to the actual node to see where the request is going.

If only some sites fail in Rule mode, the cause is often a rule match, DNS, or the site itself. When testing Global mode temporarily, make sure its policy group has a working outbound node selected rather than Direct. If Global works but Rule does not, compare the match results for both requests, fix the specific rule, then switch back to Rule mode. For a comparison of the three modes, see Rule, Global, and Direct modes compared.

Avoid stacking multiple traffic interception methods during recovery

Enabling the system proxy, an in-app proxy, and TUN at the same time is not necessarily wrong, but it makes troubleshooting harder. Establish a working baseline with a single entry point, then restore settings one at a time. In particular, do not let another VPN intercept connections to your proxy node's domain, or point the upstream proxy back to the same local port. A forwarding loop can produce a flood of repeated connection attempts in the logs without ever getting a response from the destination site.

Finish by testing two different websites in a browser and making one command-line request. If only one site fails, stop changing global network settings and check that site's rules, certificates, account restrictions, or service status. If your connection breaks again after closing the client, check whether the system still points to the local proxy. If the issue returns only when TUN is enabled, focus on routing, DNS interception, and permissions—not on reimporting your subscription.

Node timeouts: check DNS, connectivity, and handshakes

Pinpoint where the timeout occurs

A node timeout can have several causes. The client may be unable to resolve the server's domain, may resolve it but fail to establish a transport connection, or may connect successfully but fail during the encryption handshake. Select a node manually to rule out automatic switching, make a real request, then check the logs for the same time period. A failed speed test alone does not prove that a node is down if websites still load.

If the logs show a domain resolution failure, check DNS for the node server itself. A connection refused error often means the port has no service or is actively rejecting connections; a connection timeout may indicate dropped traffic, a firewall, or an unreachable service. Certificate validation, authentication, and unsupported protocols are separate issues. Keep the full error type; copying only the final word, such as timeout, removes useful diagnostic details.

Test the server port, but don't treat the result as a verdict

Get the node address and port from your own valid configuration. Don't submit them to public lookup sites. In Windows PowerShell, use the interactive commands below to enter an address and port; your input won't appear in the example. This tests only a TCP connection—not the proxy protocol, account, TLS, or UDP service—and is useful for ruling out obvious TCP connectivity problems.

$server = Read-Host "Enter the node server hostname or address"
$port = [int](Read-Host "Enter the node port")
Test-NetConnection -ComputerName $server -Port $port

TCP tests cannot tell you whether a UDP-based protocol is working. Even a successful TCP test might connect to the wrong service. Conversely, a server may block ICMP, so a failed ping does not mean the proxy port is unreachable. If the node's domain resolves to multiple addresses, check which one the client actually connects to. IPv4 and IPv6 may have different reachability, and another device may succeed by using a different route.

Check authentication and time settings for the protocol

If some nodes fail just after a subscription update, first confirm that the new subscription was applied to the active configuration, not just downloaded. Passwords, user IDs, encryption methods, transport types, and TLS settings must match the server. Don't change fields based on advice from unrelated posts or copy fields from one protocol into another. A client importing a configuration only proves it accepted the file structure; it does not prove the server will accept the credentials.

An incorrect system date, time zone, or time sync can trigger certificate errors, such as a certificate not yet being valid or already expired. Restore automatic time sync and reconnect. Don't leave certificate verification disabled as a workaround; that can conceal problems with the domain, certificate, or network path. The server hostname in the configuration may differ from the TLS server name. Follow your provider's instructions before changing it; replacing it with an IP address can also break the handshake.

Use cross-tests to narrow down the cause

Test the same node on another network, another node on the same network, and the same configuration in another supported client—in that order. Change one variable at a time. If all nodes fail on your usual network but work on a hotspot, check network restrictions, UDP availability, and the IPv6 route. If just one node fails everywhere, contact your service provider. If all nodes fail on one device but work on another, check the device's security software, system time, and core compatibility.

An automatic selection policy group may temporarily exclude nodes based on health checks. Check whether the health-check URL reflects your actual use case, then inspect the test route. If the test URL itself is restricted, a batch of healthy nodes may appear to be down. Don't set the check interval extremely low in an attempt to fix the issue; frequent checks increase request volume and cannot repair a server-side problem. Once you've confirmed a node works, restore automatic selection.

Subscription failures: separate download, parsing, and application

First determine whether fetching or parsing failed

Importing a subscription involves several stages: fetching remote content, parsing its format, generating the runtime configuration, and applying it. A download error points to an HTTP status or connection issue. A configuration format error means at least some content was retrieved, so inspect the response body. If the update reports success but no nodes appear, check which configuration is active. Repeatedly refreshing won't fix all of these different issues.

Make sure you copied the full subscription URL, not the service homepage, payment page, or a browser share link. Line breaks, extra spaces, or query parameters truncated by a chat app can change the request. Subscription URLs usually grant access and should be treated as sensitive. Don't show them on a screen share or paste them into online converters, public support tickets, or search engines. If a URL is exposed, reset it through your provider.

Use the response to diagnose fetch errors

A status code points to a possible cause but doesn't tell the whole story. For example, an access-control page may return a success status while its body contains a login prompt. Opening a link in your browser doesn't guarantee the client can fetch it: the browser may already be logged in, use a separate proxy, or have the required cookies saved. Use a subscription method explicitly supported by your provider rather than copying browser session data into a configuration file.

Check YAML and subscription format compatibility

A Clash configuration, a node list, and a subscription for another client are not interchangeable. A list of encoded node links may not work as a complete YAML configuration. A full configuration may also include policy groups, rules, and DNS settings; some clients add these through a template. First check whether the import option expects a full configuration or a proxy provider. Renaming the file extension does not convert its format.

Common YAML issues include tab indentation, misplaced list items, unclosed quotes, and duplicate top-level keys. Check the lines around the reported line number, including the one above it; a parser may flag where it detected the problem rather than where it began. For a local mihomo configuration, you can use its validation command. Here, config.yaml is the file in the current directory that you plan to check. Make sure it isn't your only backup before running the command.

mihomo -t -f config.yaml

A successful validation means the core accepts the configuration structure and its references. It does not prove that node credentials work or that all rule resources can be updated. If you see an unknown field or unsupported proxy type, check which core comes with your client rather than relying on the client shell's name. If you need a replacement, choose a maintained client for your operating system on the downloads page, and keep the original configuration for comparison.

Check what actually changed after a successful update

After updating the subscription, return to the configuration list and make sure the correct configuration is active. Then check whether policy groups still refer to old node names. A server-side rename can break manual selections, while local overrides may retain old rules or replace new DNS settings. Back up the configuration, temporarily disable overrides for comparison, and determine whether the issue comes from the subscription or the local merge before changing anything.

When a subscription is shared across devices, update schedules, caches, and templates may differ between clients. Updating it on your computer doesn't mean your phone has applied the same content. Compare node names and configuration update times, but never share the subscription URL. For details, see Sharing a configuration between your computer and phone. Once automatic updates resume, avoid frequent manual retries to prevent rate limits from causing another apparent failure.

Finally, check whether fetching the subscription depends on a proxy that is currently unavailable. If your client lets you choose the network path for updates, compare a direct connection with a working outbound node once your basic connection is available. If no node works, don't force subscription requests through a failed proxy. Follow your provider's instructions for any required access method, and don't add unknown conversion services to the mix.

Slow speeds: measure latency, throughput, and stability separately

Identify which part feels slow

A page that takes a long time to start loading, a slow download, and video that repeatedly buffers can point to different issues: DNS or handshake delays, low sustained throughput, or an unstable connection. Note when the slowdown occurs before choosing a test. A node's displayed latency usually comes from a short request; it does not measure large-file download speeds or predict how a particular video site or code repository will perform.

Choose a destination you normally use and compare a direct connection, a fixed proxy node, and another network at roughly the same time. Don't run multiple speed tests at once; they compete for bandwidth. Pause cloud sync and system downloads, and check your Wi-Fi signal. Your router may be online while wireless interference is severe, even if the proxy node is fine. Compare with a wired connection or move closer to the access point.

Look at the timing breakdown, not just the total

The commands below send a request through a local HTTP proxy and report connection, handshake, first-byte, and total times. These are cumulative timestamps reported by curl, so don't add them together. When an HTTPS tunnel is established through an HTTP proxy, some timings include proxy negotiation, and remote DNS lookups may not appear as local resolution time. Use these results to compare tests under the same conditions, not to judge a DNS service in isolation.

curl.exe -o NUL -sS --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

On macOS and Linux, replace curl.exe with curl and change the output file NUL to /dev/null. A small-page test is useful for checking connection setup, not maximum bandwidth. To compare sustained downloads, use a trusted source that permits testing, with the same file and similar timing, and account for server-side throttling. Don't treat a single site's rate limit as the limit of your entire proxy network.

Check policy group changes and connection reuse

An automatic selection group may switch outbound nodes frequently, while established connections continue using their original node. After switching nodes, the browser may reuse an existing connection, so the result might not match the selection shown in the client. Close the target page and end its connection before testing again. Don't routinely terminate all connections; that can interrupt downloads, meetings, and other active tasks.

The same region label doesn't guarantee the same route, and a shorter distance doesn't guarantee better performance across networks. When comparing nodes, pin the final node, not just the policy group. If only one service is slow through a particular node, check its regional restrictions, congestion, and server response. If several nodes are slow on the same network but work on a phone hotspot, check the local network, ISP route, or other tunneling software instead of adding more routing rules.

Use care with UDP, MTU, and resource usage

Some apps use UDP-based transports such as QUIC, and proxy support for UDP can affect performance. Temporarily disabling the browser's related experimental feature can help with comparison, but permanently disabling the protocol is not a general optimization. If TCP works but UDP-based apps are unstable, first confirm that the node protocol, client settings, and current network all support UDP. Then consider a targeted rule or app-level change.

With TUN, small web requests may work while large transfers stall, which can involve path MTU—but this symptom alone doesn't prove it. First rule out server throttling and packet loss. Back up your settings, change one supported parameter at a time, and retest. An arbitrarily low MTU increases packet count and may reduce throughput. On corporate networks or with multiple tunnels, check with your network administrator.

If speeds drop while CPU usage rises sharply, check whether verbose logging, frequent health checks, and multiple configuration updates are running at the same time. A growing number of connections may also come from an app retrying requests. Pause extra tasks and retest with one app. If the issue is on the remote service or upstream route, stop changing local DNS; DNS settings can't increase the throughput of an established connection.

DNS issues: check the resolver path and Fake-IP

Separate local DNS from proxy-side DNS

A browser's domain error can involve the operating system resolver, browser secure DNS, client DNS, or the resolver used by the node server. First identify whether the failed domain belongs to the destination site or the node server. If the node's domain won't resolve, the connection hasn't reached the upstream server. If the destination domain fails, check the proxy entry point and DNS mode. Don't send every lookup to the same public resolver by default.

With an explicit HTTP proxy or SOCKS remote DNS, the proxy may resolve the destination domain. A system lookup can fail while browser access through the proxy succeeds. The reverse is also true: a successful system lookup doesn't prove that DNS inside the client is working. Trace the request path first and test through the relevant entry point instead of using system DNS results to judge the client's internal resolver.

Understand what a Fake-IP response means

Fake-IP mode assigns a mapped address to a domain; the core uses that mapping to recover the original domain when handling the connection. Seeing an address from a reserved range does not automatically mean DNS has been tampered with. First check whether it belongs to the Fake-IP range in your client configuration. If an app caches that address and bypasses the core for a direct connection, it may fail. After switching modes, reconnect and restart any affected apps if needed.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

This snippet explains how the fields relate. Merge it into the single existing dns block rather than replacing your entire subscription. The upstream addresses are examples; check whether they are reachable on your current network. An encrypted DNS upstream specified by hostname also needs a way to resolve its own hostname; follow the documentation for your core to configure bootstrap resolution. Internal company domains usually require an internal resolver and should not all be sent to public services.

Add exceptions for specific domains

Device discovery on a local network, some games, and apps that need to verify real DNS responses may not work well with Fake-IP. Identify the exact failing domain first, then add it to fake-ip-filter for comparison. Filtering returns the real address, but routing rules still determine whether traffic goes direct; the filter list is not a direct-connection list. Filtering every domain defeats the main purpose of this mode and may change existing routing behavior.

If your browser uses its own encrypted DNS, its queries may bypass the expected local DNS entry point. During diagnosis, temporarily switch to the system resolver path and see whether the issue changes, then decide which setup to keep. TUN DNS interception does not guarantee that every encrypted query can be identified, especially queries made over HTTPS inside an app. For more on how the mapping works, see Fake-IP and filter lists explained.

Clear caches along the resolution path and check IPv6

First make sure the configuration has been applied, then clear the cache at the affected layer. Otherwise, old settings may still be active and clearing the cache may only help temporarily. On Windows, run the system DNS cache flush command below. Browsers, apps, and clients may have their own caches; clear them through their respective settings. Cache behavior varies across macOS and Linux system services, so don't keep repeating a copied command.

ipconfig /flushdns

When a domain returns both IPv4 and IPv6 addresses, an app may try an address family that isn't reachable on your current network. Check the system's IPv6 route, node outbound path, and client DNS settings instead of immediately disabling IPv6 on the whole device. Compare address families in a controlled test, then change a client-supported option if the results point to a specific issue. Reconnect after changing resolution order to see the effect.

If only internal domains fail, check the search suffix, internal DNS server, and network connection. Connecting to a corporate VPN may add split-DNS settings that a proxy client's general DNS override can disrupt. Preserve your organization's policies and set appropriate DNS and routing boundaries for internal domains. When troubleshooting is complete, test public websites, local devices, and work services to make sure fixing external access hasn't broken your intranet.

System proxy not working: check app support and TUN routing

Check whether the app uses the system proxy

The system proxy toggle changes the proxy settings provided by the operating system; it doesn't force every program to use a proxy. Browsers usually read these settings, but command-line tools, games, containers, and some desktop apps may use their own network stack. Use the client's connection log to confirm whether traffic is going through the proxy. If the app creates no connection at all, check how it supports proxies before changing outbound rules.

On Windows, the user proxy and WinHTTP settings are separate; some services won't follow the proxy shown in the user interface. macOS stores proxy settings per network service, so check the active service after switching between wired and wireless connections. Linux desktop proxy settings, environment variables, and app-level settings also differ. Don't set every entry to the same value just to get one app working. First find out which setting that app actually uses.

Ports, environment variables, and bypass lists

After the client changes its mixed port, in-app proxy settings and terminal variables may still point to the old port. Read the actual value from the current runtime configuration, then check which local port is listening. The commands below check the port on Windows and Linux. If it is occupied, identify the owning process; don't kill every process that is listening.

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

# Linux
ss -lntp 'sport = :7890'

Terminal variables such as HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY can affect different tools, but support varies. Be careful when viewing them: they may contain credentials. Changing a variable in your current terminal won't affect other programs that are already running, and desktop apps may not inherit terminal variables. If the destination domain is on a bypass list, the app may connect directly and leave no record in the client.

TUN needs permissions, routes, and the right exclusions

TUN intercepts traffic through a virtual network interface and can help with apps that ignore the system proxy, but it requires the right system permissions and routing setup. First confirm that the client's helper service or permissions are in place, then check that the virtual interface exists and its routes were actually added. If the UI shows TUN as enabled but the logs report insufficient permissions, traffic interception has not succeeded. Take extra care with containers, remote desktops, and servers: a bad route can cut off your management connection.

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

This example is for mihomo environments that support these fields; it should not be copied unchanged to every platform. The client may generate and override TUN settings through its interface, so make changes in the designated settings. Automatic outbound interface detection can choose the wrong adapter when multiple network cards, virtual machines, or other VPNs are present. Check the actual default route. Intercepting DNS on a port does not mean all encrypted DNS traffic is intercepted.

Check for other proxies and leftover network changes

Browser extensions, another VPN, corporate security software, and proxy clients can compete for the system proxy, virtual adapters, or routes. During diagnosis, pause additional tools you can safely turn off, keep mandatory corporate policies in place, and note their original settings. Let only one tool control the system proxy, then see whether another process changes it back. Don't repeatedly toggle the setting to compete with another program.

After switching from Wi-Fi to Ethernet, resuming from sleep, or joining a hotspot, the default adapter and gateway may have changed. If TUN stops working only after a network switch, disconnect, restart traffic interception, and check the new connection log. If re-enabling it restores access, investigate interface detection and client logs instead of scheduling full system restarts. For macOS permissions, see Network Extension and Keychain setup.

Test one browser that follows the system proxy and one app that didn't use it before. If the browser works but the other app doesn't, the system proxy path may be fixed while TUN or the app's own settings still need attention. Finally, close the client and check whether basic network access returns. The recovery process is complete only after the proxy address has been cleared and virtual routes have been removed. Don't leave a local proxy port exposed to untrusted networks.

Startup failures and crashes: separate the UI, core, and configuration

First identify which process exited

A closed client window, a missing tray icon, and a stopped core are not the same thing. Some apps keep running in the background after the window closes; others leave the UI open after the core crashes. Check the system tray, Task Manager, or Activity Monitor, then check the local port and logs. Don't launch multiple instances just because the main window is gone; they can compete for ports, configuration directories, and helper services, causing new startup problems.

Note when the failure occurs. An app that exits immediately after launch often has an environment, permissions, or configuration issue. If it exits after importing a configuration, check the content and referenced resources. If it exits after running for a while, consider memory, disk space, growing logs, or a specific connection. Recording your last normal action and subsequent changes is more useful than clearing all data, and makes the issue easier to reproduce.

Check the system architecture and installation

The installer must match your operating system and processor architecture. Windows, macOS, and Linux have different installation methods; similar filenames do not guarantee compatibility. On macOS, distinguish Apple Silicon from Intel. On Linux, check the distribution's package format, runtime libraries, and desktop environment. Use the platform downloads page to choose Clash Plus or another maintained client for your system instead of relying on an old tutorial's installer.

Security software, system app controls, or file execution permissions can also prevent an app from starting. Check the exact system message, confirm where the file came from, and grant permission using the normal system process. Don't disable security protections globally or download supposed missing components from unknown sites. Ask your administrator about installation restrictions on managed devices; bypassing them may prevent the helper service from working and cause network interception to fail later.

Back up first, then test a minimal setup

If you suspect a corrupt configuration, close the client and back up its data directory first. The backup may contain subscription URLs and credentials; keep it in a trusted local location rather than syncing it to a public repository. Then use the client's reset or new-configuration option to test, instead of deleting the entire directory. If a minimal configuration starts, restore the subscription, rule resources, and overrides one at a time, restarting to test after each change.

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

This minimal example checks whether the core and local listener work. It sends all traffic direct and does not provide a proxy. Before testing, make sure the port is free and temporarily turn off TUN. If this setup works, focus on proxy types, rule providers, scripted overrides, and external resources in the original configuration. Before restoring your usual setup, switch back to a valid subscription so you don't mistake a direct-only diagnostic configuration for a working proxy.

Separate port conflicts from resource exhaustion

If the logs say an address is already in use, identify the process listening on it and check whether it is an old instance, another proxy, or a system service. Temporarily changing the mixed port can confirm a conflict, but you must also update the proxy settings in any apps that use it. The controller port and proxy port serve different purposes; changing one value in the UI doesn't resolve every conflict. If the helper service still has the old settings, restart it using the client's procedure.

If the client gradually becomes unresponsive, check free disk space, log growth, rule resource size, and connection count. Leaving debug logs enabled can increase disk activity; a large number of connections may also result from an app repeatedly retrying. Stop the app triggering the problem, then see whether resource use falls. High memory usage alone doesn't prove a leak; look for continued growth, whether memory is released, and whether the issue is consistently reproducible.

If problems began after an upgrade, record changes to the configuration and system messages, and keep a backup in case you need to roll back. Don't update the client, change DNS, and replace the subscription all at once; you won't know which change caused the problem. When reporting it, include the system architecture, client name, core error, and minimal steps to reproduce, with private fields removed. A reproducible case helps maintainers distinguish a UI bug from a core issue or incompatible configuration.

Mobile troubleshooting: permissions, background activity, and network switching

On Android, check VPN permission and make sure only one app is intercepting traffic

Android clients typically use VpnService to create a local VPN interface. The system permission prompt is part of traffic interception; it does not mean the device has connected to a remote VPN service. On first launch, confirm that permission was granted, then check the status bar and the client's connection status. In most normal setups, only one active VPN can run per user. Ad blockers, work-profile VPNs, and other proxy apps may conflict with the current client.

Android's always-on VPN and block connections without VPN settings affect what happens after a disconnect. If blocking is enabled, losing all network access when the client stops may be the expected system behavior, not a Wi-Fi problem. Note these settings before temporarily changing them. Don't remove a managed VPN from a work device yourself; ask your administrator whether a personal proxy can run alongside it and which apps are managed.

For lock-screen disconnections, check background restrictions

If the connection works with the screen on but fails after the phone has been locked for a while, check battery optimization, background activity, auto-start, and the manufacturer's app-sleep features. Allow the client to run without strict battery restrictions, then test again with the screen locked. Notification permission alone may not be enough, and a visible notification doesn't prove that the core is still running. After waking the device, check the service status and log timestamps to see whether the process stopped, the network was suspended, or the connection expired.

Don't turn off every battery-saving feature on your phone at once. Allow background activity for the client specifically, keep other app settings unchanged, and test for the same amount of time. Menu names vary by Android version; search Settings for battery optimization, background activity, or auto-start. For a step-by-step checklist, see Android background disconnections and battery optimization exemptions. If the issue happens only on one network, also check router sleep settings and Wi-Fi power saving.

On iOS, check the tunnel status and On Demand settings

When using Clash Plus on iOS, first confirm the configuration is enabled in the app, then check the system VPN status to see whether the tunnel is actually connected. If initial permissions weren't granted, saving a subscription won't start traffic interception. To install or reinstall the app, use the iOS download page to open the App Store; its official website is clashplus.io. Before reinstalling, make sure your configuration is backed up safely.

On Demand may reconnect the tunnel after a network switch, when internet access returns, or when a rule is met. If the tunnel reconnects after you manually turn it off, that isn't necessarily a bug. Check On Demand settings, other VPN configurations saved by iOS, and which one is active. Don't repeatedly delete all network profiles. If the tunnel shows as connected but only one app fails, check routing rules and DNS instead of resetting the entire network.

Compare Wi-Fi and cellular connections

If the same node works on Wi-Fi but fails on cellular, check UDP, IPv6, the carrier route, and mobile data permissions. Confirm that the client is allowed to use mobile data, then compare using the same node. Some networks use different address translation methods; a successful ping to the server doesn't prove the proxy protocol will work. Change one variable at a time and note when the connection drops and what it takes to reconnect.

Public Wi-Fi often requires signing in through a web page first. After traffic interception starts, the login page may not open correctly. Temporarily disconnect the proxy, sign in to the network, then reconnect. Use your judgment to verify the login page; don't enter your subscription URL or proxy credentials on an unfamiliar page. If a hotel or campus network restricts certain protocols, ask its network administrator which access methods are allowed instead of repeatedly resetting your local configuration.

On mobile, check the per-app proxy list as well. Make sure you know whether the list means only proxy selected apps or exclude selected apps; reversing the setting can leave one app connected while another never appears in the logs. Changes usually require reconnecting the tunnel and restarting the target app. Whether tethered devices use the phone's proxy depends on the operating system and client. A working connection on the phone does not prove that a tethered computer will use the same outbound node.

When comparing devices, confirm that your phone and computer use the same subscription content and final node, and that they aren't using different modes such as Rule and Global. A simpler mobile interface doesn't mean the core behaves identically; unsupported fields may be ignored or overridden by the app. Look up unfamiliar terms in the glossary. To review the setup from scratch, return to Getting Started and establish a working baseline by importing, selecting, connecting, and testing.