The Complete Clash Troubleshooting Guide

No Internet Access: Separate Network Issues from Proxy Issues

Turn off System Proxy and TUN in the client, then try a site that normally works without a proxy. Closing the window may not undo system settings, and some clients keep running in the background. If you still cannot connect with traffic interception off, troubleshoot Wi-Fi sign-in, your router, Ethernet, or your ISP first. Switching nodes repeatedly will not fix a broken network connection. Public Wi-Fi may also require browser-based sign-in; open the sign-in page with the proxy disabled.

Confirm what's affected before choosing where to look

Test a site that should connect directly, one that requires a proxy, and a separate app. Note which ones work. If everything fails, check whether the system proxy points to a local port that is no longer listening. If only proxy destinations fail, inspect the policy group and outbound. If just one site fails, check its matching rule, service status, and access restrictions. One website is not a reliable test of the entire internet, and a cached browser page does not prove that you are online.

Next, confirm that the core is running. An open client window does not mean its background core is listening on a port. Check the status and startup logs for port conflicts, configuration parse errors, or permission issues. If the logs stop before loading the configuration, investigate the startup failure first. If connection records appear, check whether each request goes to DIRECT, a policy group, or REJECT. With no connection records, revisit the traffic-routing method instead of changing remote protocol settings.

Narrow it down with an explicit proxy test

Find the local mixed port in the client settings, then specify it explicitly in a command. The example below uses port 7890; replace it if your client uses a different port. Do not change your entire configuration just because the example uses this one. On Windows, use curl.exe to avoid PowerShell interpreting the command as a different tool. The test destination is for troubleshooting only and may not be reachable on every network.

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

The first command does not explicitly use a proxy, but terminal proxy environment variables may still affect it; check those variables before testing. If the second command reports that the local connection was refused, the listen address, port, or core status is wrong. If the local connection succeeds but the remote request times out, investigate the node and network path. If the explicit proxy works but the browser does not, the outbound is probably available; check browser extensions, system proxy settings, and Secure DNS. An HTTP status code means you received a response, not that every part of the destination service is working.

Restore connectivity in steps you can undo

Switch back to Rule mode, select an outbound that worked before, and close other proxy clients or duplicate traffic-interception tools before reconnecting. Temporarily turn off TUN while keeping System Proxy enabled to distinguish routing issues from app proxy issues. This is not an equivalent test for apps that ignore system proxy settings. After each change, close existing browser connections or restart the test app; established connections generally do not switch routes immediately when a policy changes.

If sites only stop working after you exit the client, open your system network settings and remove any leftover manual proxy address, then restore automatic network settings. Avoid a full network reset unless necessary: it can remove virtual adapters and static addresses required for work. After restoring the connection, test direct access first, then start the client and enable features one at a time. Note the last setting that triggers the problem so you can target the fix instead of reinstalling every time.

Node Timeouts: Tell a Failed Test from an Unreachable Outbound

Try accessing the destination before relying on the client's latency test. A timeout only means that one probe did not finish within the allotted time. The test address, DNS, probe method, or current network path could be responsible; it does not prove that the node is permanently down. If the site loads but the probe keeps failing, try a reachable test address or restore the client's default test settings instead of deleting the subscription. For more on test results, see Latency Tests vs. Real-World Speed.

Pinpoint where the timeout occurs

Open the logs, repeat one failing request, and check the entries for that destination and time. A DNS error before connecting to the server points to name resolution for the server address. A timeout connecting to the server port may involve your local network, route, remote listener, or an intermediate firewall. A handshake failure after connecting calls for checking the protocol, transport, security settings, and server status. Error wording varies by client, so read the surrounding context instead of searching only for the last English word.

Check which outbound the policy group actually selected. An automatic group can change during health checks, and a fallback group may have switched to another member; the group name shown in the interface is not the server address. Inspect the outbound used by the connection and make sure it is not DIRECT or an unavailable member. If the node connects through another proxy, check that upstream outbound too. Any failed link in a proxy chain can result in a timeout to the destination.

Cross-test the network and server

On the same device, switch between your home network and a mobile hotspot. Keep the client configuration unchanged and test the same outbound on both. If it fails on only one network, suspect the network path, port restrictions, or DNS differences. If it fails on multiple networks, test on another device. If both devices fail but other outbounds from the same subscription work, the issue is more likely with that server. Disable automatic switching during tests so the same group does not silently use a different outbound each time.

Check that the subscription updated successfully, your account still has access, and the provider has not changed the server entry. Do not guess server ports, encryption methods, or transport settings; they must match the server, and guesswork often turns a timeout into a handshake error. Check that your device date and time zone are correct, as a significant clock offset can break certificate validation. For certificate errors, verify the server hostname and certificate configuration rather than leaving validation disabled.

Don't mistake a protocol-specific issue for a total outage

A page may load while voice calls or games time out, which can point to UDP support, app traffic routing, or destination restrictions. Check whether the node protocol and server support the traffic in question, then review the client's connection records. Browser QUIC, standard HTTPS, and app-specific protocols do not all take the same path, so a single web test cannot verify every service. An app's compatibility transport option can be useful for comparison, but disabling a protocol is not a universal fix for every device.

Increasing a timeout can help identify a slow response, but it will not open a blocked port. Keep the default value at first. Once the issue is consistently reproducible, extend a single probe modestly and compare the actual request results. When reporting the issue, include the time, network type, redacted error, and cross-test results; never send full server credentials. If only a few outbounds are affected, switch to a working one and ask the provider to check the relevant server entry.

Subscription Errors: Check Download, Format, and Configuration Loading Separately

First identify the failing step: the URL cannot be fetched, the content downloads but cannot be parsed, or the core fails to start after import. Each has a different fix. Keep your last working configuration so a failed update does not overwrite a usable setup. A subscription entry in the client only proves that a record was saved locally; check its last-updated time and result to confirm that the latest content was fetched successfully.

Check the URL and how it's being fetched

Copy the subscription URL again from your provider, making sure it is intended for Clash or mihomo. Watch for line breaks or extra spaces from chat apps and punctuation added when copying from a webpage. Treat the URL like a password: it often contains account credentials. Do not paste it into a public conversion service or include it in a screenshot title. If it has been exposed, generate a new one on the provider's site; deleting a post cannot revoke access that has already been leaked.

Check the error shown during the update. No response usually calls for checking the network and DNS. An explicit unauthorized or forbidden response points to URL permissions or account status. If a page downloads but parsing fails, the response may be a login page, error message, or access verification page rather than a subscription. A provider's website opening in your browser does not prove the client can reach its subscription API; the request path, login state, and network outbound may differ. Avoid repeated retries that could trigger rate limits.

Some clients let you choose whether to fetch a subscription directly or through a proxy. If you already have a working configuration, compare both paths. For a first import without a working outbound, use a legitimate fetch method that your current network can reach. If an update depends on a node that is already down, you can end up in a loop with no way to fix it. In that case, restore the last working configuration, temporarily use another available outbound, or ask the provider to check the subscription endpoint; changing DNS at random is less likely to help.

Make sure the format matches the client's capabilities

A complete YAML configuration, an encoded list of nodes, and a single URI link are different types of content. A client may import content that is not a complete configuration for another client. Check the requirements for the import option and distinguish between adding a single node, importing a configuration, and updating a subscription. If you have the wrong format, ask the provider for the appropriate version. If conversion is necessary, see Subscription Formats and Conversion to understand what might be lost, including policy groups, rules, and extra fields.

Parse errors often include a line number and field name. Check that line and the one above it in the original file for indentation, colons, quotes, and list markers. YAML indentation uses spaces; do not mix in tabs. A configuration can pass syntax parsing and still contain invalid policy references: rules may point to missing groups, or groups may include nonexistent nodes. These can prevent loading or cause unexpected behavior. Keep names with spaces or special characters intact, and update all references when renaming them.

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

This direct-only configuration is for checking whether the basics load; it contains no remote proxy. If the client supports importing a local configuration, back up the current one and create a separate test entry rather than overwriting your subscription. If the minimal configuration starts but the original does not, inspect the original file's fields, references, and external resources. If neither starts, check ports, directory permissions, and the core's runtime environment.

Handle update overwrites and external resource failures

Even if the subscription content loads, rule sets or proxy collections may still fail to download. Check each external resource's URL, file path, and error instead of blaming every download failure on the subscription URL. If the client supports overrides or configuration merging, keep local changes in a dedicated entry to prevent updates from overwriting them. Check the final effective configuration if merge order is unclear. After repeated failures, restore a backup before adding custom content one item at a time. If the client and core are incompatible, choose a suitable option from the client downloads page. Clash Plus is a good starting point for most users; compare other options by platform.

Slow Speeds: Separate DNS, Handshake, and Throughput Issues

First describe what is slow: a long wait after clicking a link, a page that loads quickly once it starts, a consistently slow download, or slowdowns only at peak times. Time to first byte, throughput, and interactive latency are different measures. A low latency reading in the client only means that one short request responded quickly; it does not guarantee enough bandwidth. Avoid running multiple speed tests and downloads at once, as the tests themselves compete for your outbound and local Wi-Fi capacity.

Set up a repeatable comparison

Keep the device, network, outbound, and destination the same. Pause large file syncs, system updates, and other bandwidth-heavy tasks, then run a few tests. Test the destination directly first to see whether the local network is already congested, then test the service that requires a proxy. When comparing outbounds, use the same destination at roughly the same time; otherwise, server caching, file size, or regional content delivery can look like node performance differences. For hotspot tests, account for data plan limits and signal fluctuations.

Download speeds are often measured in bytes per second, while advertised broadband speeds are usually in bits per second; the figures are not directly comparable. A Wi-Fi link's negotiated rate is also not the usable speed an app can sustain. Router performance, wireless interference, device power-saving settings, shared outbound capacity, and destination server limits can all be bottlenecks. Compare wired and wireless connections, or test close to the router. If direct traffic is also slow, improve the local connection first; changing proxy rules cannot increase Wi-Fi capacity.

Check which outbound the slow request actually uses

Find the domain that's loading in the connections view and check its matching rule and policy. A webpage often loads resources from multiple domains: the main page may connect directly while static files go through a proxy, or the login API may use a different region. Do not assume every request is routed correctly just because the main domain is. Use connection records to add necessary rules, placing specific rules before broader ones. Reconnect after changes so existing connections do not keep using the old outbound.

Rules are evaluated in order. A broad condition placed too early can send traffic that should connect directly to a remote server, adding latency. Conversely, routing a domain that needs a proxy directly can leave it waiting before it fails. Check the final configuration, not just the snippet in the editor; subscription merging and overrides can change rule order. To understand matching behavior, read Custom Rules and Match Order before making changes. Avoid adding repeated rules and hoping one works.

If only the first visit is slow and later visits are fine, check DNS, connection handshakes, and whether the remote server needs time to wake. If a transfer starts quickly and then slows, congestion, throttling, or device load is more likely. Check CPU, memory, and network usage in Task Manager for a process that is continuously consuming resources. Excessive logging in a graphical client can also add overhead. Once you have diagnosed the issue, restore the normal log level instead of leaving verbose debug logs enabled.

Adjust MTU, protocol, and concurrency with care

If small pages work with TUN enabled but large files or some sites stall, check for path MTU or fragmentation issues. First compare with TUN disabled and explicit proxying enabled to see if the virtual adapter is involved. Adjust MTU based on link testing and the client documentation; a value found online is not universal. Retest the same service after each change and keep the original value. Lowering it blindly increases the number of packets and may not improve speed.

Likewise, do not treat more concurrency, every advanced setting, or an arbitrary public DNS server as a speed-boosting package. More connections can add load, and some protocols depend on server support. Choose an available outbound with a suitable route and distance to the destination, and avoid unnecessary proxy chains. Automatic selection can help maintain availability, but health checks may not measure large-file throughput. For sustained downloads, compare outbounds and pin one manually to avoid changes that make results hard to interpret.

DNS Issues: Find Out Who Resolves the Name and Where the Result Is Used

First distinguish a DNS failure from a failed connection to the destination. Look for errors such as host not found, DNS timeout, or no address available before prioritizing DNS troubleshooting. If an address was returned but the connection timed out, routing or the outbound may still be the problem. Replacing a domain in a URL with its IP is not a reliable test: HTTPS certificates, server names, and virtual hosting may all depend on the original hostname. Use DNS tools alongside client logs instead of relying on a browser error page alone.

Map the DNS path that's actually in use

The operating system, browser, client, and remote proxy may all take part in DNS resolution. Secure DNS in the browser can bypass the system resolver, while an app's built-in resolver can return a different result from a terminal tool. Whether TUN intercepts DNS also depends on the route and query type. Note the current mode, the client's DNS settings, system DNS, and browser settings; then check which path the affected app uses. Changing system DNS alone may not change the app's results.

Use a system tool to query a stable domain while checking the client logs. The command below shows the system resolver's result; it may not match the address returned to the browser or proxy outbound. Query both the failing and a working domain. If only one fails, check authoritative records, cache, or split DNS settings. If all fail, check whether the resolver is reachable. Different results in a terminal and client log are not automatically a problem; content delivery networks may return different addresses.

nslookup example.com

# Use this on Linux or macOS if dig is installed
dig example.com A
dig example.com AAAA

Check how the proxy server's own hostname is resolved. If resolving the proxy endpoint requires using a proxy that has not been established yet, startup can get stuck in a loop. In mihomo, proxy-server-nameserver is used to resolve proxy node hostnames, and default-nameserver can resolve the hostnames of encrypted DNS servers; behavior also depends on other settings. Make sure DNS needed at startup has a working path before configuring resolution for destination domains. Do not force every query through an unreachable outbound.

Know the limits of fake-IP mode and caching

In fake-IP mode, apps receive virtual addresses that the core maps back to domain names when handling connections. Seeing one of these addresses does not mean DNS has been poisoned. The issue is whether the same core still intercepts the connection after the app receives the virtual address. If an app retains an old cache after the client closes or loses the mapping, it may fail to connect. After changing modes, close existing connections and restart affected apps; clear the relevant cache if needed instead of immediately adding a long list of exclusions.

Some device discovery features, local network services, and apps require real addresses. If you confirm a compatibility issue, add the relevant domains to the fake-IP exclusions. An exclusion only changes DNS handling for those domains; it does not automatically route their traffic directly. Check the rules and routes as well. Local hostnames may rely on your router, search domains, or multicast discovery, which public DNS providers typically do not know about. Preserve corporate DNS for remote work rather than replacing it with a single public resolver for every use.

Compare with a minimal DNS configuration

This snippet illustrates how the fields relate to one another. Merge it into a separate test configuration; do not replace the entire DNS section of an existing subscription. It uses ordinary DNS for a basic comparison and does not include encrypted transport. If the resolver cannot be reached on your current network, use an address confirmed by your network administrator or service provider. A successful test only proves that this DNS path works; it does not meet every privacy or routing requirement.

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

If IPv4 works but dual-stack connections fail intermittently, check IPv6 resolution, the default route, and proxy support separately. Disabling IPv6 for one app does not prove that the root cause is gone; other apps may still use a different path. When restoring the configuration, test node hostnames, ordinary destinations, and local network destinations separately, then re-enable encrypted DNS and routing rules one at a time. For the full TUN setup, see TUN Mode and Virtual Adapter Setup.

System Proxy Not Working: Check Whether the App Uses Proxy Settings

Start with what System Proxy actually does: it provides proxy settings for apps to read. It does not force all network traffic through the proxy. Some terminal tools, games, background services, and apps that create their own connections will ignore it. If the browser works but a particular app still connects directly, the client may be working as intended. Verify the local listener with a tool that explicitly uses the proxy, then check whether the target app supports proxy settings. If more apps need traffic interception, consider TUN rather than repeatedly toggling System Proxy.

Check the listen address, port, and proxy type

Check the client’s current port and make sure the system’s manual proxy points to the same address. The common local address is 127.0.0.1, but the port varies. HTTP, SOCKS, and mixed ports support different capabilities and cannot be swapped at random. If an app requires SOCKS, use a port that supports SOCKS. For HTTP CONNECT, use the corresponding listener. A mixed port can support both, but only if the client has enabled that listener.

Check whether another client, browser extension, or enterprise policy keeps rewriting system proxy settings. You may see it work at first, then find that the proxy address has changed again. Exit other traffic-interception tools and check whether the setting stays put, then re-enable them one at a time. Do not have multiple clients auto-start and compete for control. If your device is managed by your organization, follow the administrator's instructions; overriding its policy can break work networks and authentication services.

Configure terminals and isolated environments separately

Terminals usually need tool-specific options or environment variables. The commands below set HTTP and HTTPS proxies for the current Unix-like shell session and exclude local addresses. In Windows PowerShell, use the corresponding environment variable syntax. Environment variable name case sensitivity varies by tool, so check its documentation. Running processes do not inherit variables changed later; restart the test app from a new shell.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

# Remove temporary settings from the current session
unset http_proxy https_proxy no_proxy

Using an HTTP URL as the value of https_proxy is not necessarily wrong: it can tell a client to tunnel HTTPS traffic through an HTTP proxy. Do not change the URL scheme just because of the variable name. In a container, virtual machine, or some subsystems, 127.0.0.1 points to that environment, not the host. For cross-environment access, confirm the host address, listener scope, and firewall rules. Restrict who can connect so you do not expose a local proxy to an untrusted network.

Enable TUN only when you need it

If a target app does not support proxies, you can use the client's TUN feature. First check the required permissions, virtual adapter, routes, and DNS interception. Some clients can use System Proxy and TUN together, but enabling both does not automatically make traffic handling more reliable. For diagnosis, keep only one traffic-routing method active at a time to avoid duplicate forwarding or a competing VPN route. The presence of a virtual adapter does not prove that routes are correct; check the target app's actual connection records.

If the browser works but the command line does not, test with an explicitly specified proxy. If no apps appear in the connection records, check the listener and traffic-routing method. If records appear but use the wrong outbound, check the rules. After fixing the issue, test a proxied destination, a direct destination, and a local device to make sure you have not broken printing, file sharing, or work access. After exiting the client, check that System Proxy was reset correctly too; verify the rollback to avoid a leftover address breaking your connection after the next reboot.

Client Crashes: Check the Interface, Core, and Background Service Separately

First identify which process exited. An interface that will not open, a frozen window, a stopped core, and a failed background service are different issues. If the proxy still works after the window closes, the interface process may have crashed. If the window is fine but the port no longer listens, check the core and service logs. Record the operating system message, time, and last action—for example, updating the configuration, switching TUN, waking the device, or changing networks—instead of reporting an unrepeatable “sudden crash.”

Preserve evidence, then try a minimal startup

Export the necessary logs from the client, or look in its data directory for records around the time of the issue. Before sharing, remove subscription URLs, node credentials, browsing history, and local usernames. Do not upload the entire configuration directory; it may contain account data and control interface settings. If the logs are long, include the startup and error lines with their surrounding context. The last line alone is rarely enough to tell a configuration problem from a runtime issue.

Back up your files, then switch to a minimal local configuration. Temporarily turn off automatic updates, external rule downloads, TUN, and launch at startup before opening the client. If the minimal configuration works, restore the original settings one at a time to find the trigger. If it still fails, check the installation files, system components, directory permissions, and process conflicts. Do not delete the configuration, reinstall, and update the system all at once; even if that fixes it, you will not know which step helped.

Check permissions, architecture, and port conflicts

Choose an installer for your operating system and processor architecture from the client downloads page. Clash Plus is a good starting point for most users; choose Clash Verge Rev, FlClash, or another suitable option if you need a different interface or deployment method. Check the client's current system requirements instead of assuming a new installer will work on an older system. Clash for Windows and ClashX Meta are no longer maintained. When migrating, keep a working copy of your configuration and recheck traffic routing and service settings; do not copy the entire old application folder over the new client.

If the startup log reports that an address is already in use, identify the process using it rather than ending random system processes. On Windows, use the command below to find the process ID for the example port, then verify the app in Task Manager. On Linux, use ss to check listening sockets. If another proxy instance is responsible, close the duplicate or change the port in settings, then update the system proxy and app to match. A port in the log might belong to the control interface rather than the proxy listener; check each field separately.

# Windows: check the example port
netstat -ano | findstr :7890

# Linux: check TCP listeners
ss -lntp

Service installation, virtual adapter creation, and normal desktop use may require different permissions. Grant only the permissions required for documented steps; do not run everything with elevated privileges to mask a directory permission problem. A protected installation folder, read-only data directory, or full disk can prevent configuration writes. If security software quarantines a component, first check its source and the security event log, then follow your device management requirements. Do not disable all protection as a troubleshooting shortcut.

Troubleshoot after sleep and monitor ongoing resource use

If the issue only occurs after waking from sleep or switching networks, reconnect to the network, restart the core, and check whether that fixes it. Network interface IDs, the default route, and DNS servers may change after resume, so the previous TUN state may no longer apply. Once you confirm the client has a relevant recovery option, decide whether to enable auto-reconnect. A repeated restart loop can erase useful evidence and interrupt working connections; it is not a substitute for diagnosing the cause.

If performance degrades the longer the client runs, monitor memory, CPU, and disk writes. Record when resource use starts to rise and what the client was doing. Excessive logs, very large rule sets, and frequent health checks are worth comparing, but high resource use alone does not prove a specific defect. Reduce custom settings one at a time, restore the normal log level, and compare over the same period. After an update or migration, confirm stable operation before enabling launch at startup. For Linux background service and log checks, see mihomo and systemd Deployment Guide.

Mobile Troubleshooting: Check VPN Permission, Background Activity, and Network Changes

Confirm that the operating system has established a VPN connection for the current client before testing the destination app. Mobile clients usually route traffic through the system VPN interface. A VPN icon only indicates connection status; it does not confirm that the subscription, DNS, and remote outbound are working. A work VPN, firewall, or other network filter may compete for the same routing slot. Identify which app is handling traffic before troubleshooting rules and nodes, so two tools do not keep overwriting each other's settings.

Android: Check VPN permission and background restrictions first

When starting Clash Plus, Clash Meta for Android, or FlClash, grant VPN permission when prompted. Without permission, the app may still show your configuration, but app traffic will not enter the tunnel as expected. If connecting does not trigger a permission prompt, check Android's VPN settings for an old profile, always-on VPN, or an option to block connections without a VPN. Note the original settings before changing them. On a managed work device, follow your organization's policy and do not remove a required connection.

If the client works in the foreground but stops after the screen has been locked, check battery optimization, background activity, and auto-start restrictions. Settings vary by manufacturer, so use your device's menus as the source of truth. Allow the client to run in the background as needed, then test by locking and waking the device once. Do not remove restrictions for every app; adjust only the client handling network traffic and check whether the system reports high battery use or has stopped its background service.

If only some apps bypass the proxy, check whether an app include or exclude list is enabled. An app list works differently from routing all traffic. App updates, work profiles, and cloned apps can also change which processes the list covers. Use a regular browser as a baseline, then test the affected app. In-app Secure DNS, a separate network stack, or account region restrictions may produce different results from the browser; one failing app does not prove that the whole VPN is broken.

iOS: Check the VPN profile and affected service

For iOS, see the recommended Clash Plus option in the iOS client section and verify the official site at clashplus.io. When connecting for the first time, approve the VPN configuration requested by iOS, then confirm the active subscription and policy in the client. If multiple VPN profiles are saved, check which one is active. Before deleting an old profile, make sure it is not for work or another network you still need.

If the browser works but a particular app fails, check the connection records to see whether its destination appears. Then distinguish between traffic that was not intercepted, a rule issue, and a server rejection. Some services base access on account region, device location, or an existing session; changing outbounds does not automatically change those conditions. Restarting the app can rule out a stale connection, but clearing all app data should not be the first step. For payments, account verification, or work authentication, restore a stable network and follow the service provider's instructions.

Recheck after switching between Wi-Fi and cellular

Switching from Wi-Fi to cellular can change the local address, DNS resolver, IPv6 availability, and network path at the same time. If traffic stops right after switching, wait for the system network to become ready, then reconnect the client. Record the result on each network. If only Wi-Fi fails, check the sign-in page and router. If only cellular fails, check signal strength, plan status, and carrier routing. Do not repeatedly test while driving or in any other situation where using the device is unsafe.

A phone connecting through the client does not mean that a computer connected to its hotspot will use the proxy too. Whether hotspot traffic is intercepted depends on the operating system, routing, and client implementation; the phone's VPN icon cannot confirm it. Sharing a proxy with other devices also involves listener scope, authentication, and firewall settings, so use a clearly defined local network setup. Most users should install a suitable client on each device and test it separately. Do not enter the phone's loopback address in the computer's proxy settings.

After troubleshooting, test foreground access, recovery after locking the screen, Wi-Fi and cellular switching, and a local service that should connect directly. Keep only the background permissions you need and restore temporary debug settings. If the issue still reproduces, collect the device OS, client name, network type, time of failure, and redacted logs, then contact the relevant maintainer or service provider. Look up basic terms in the glossary. To rebuild your configuration, return to the getting started guide and verify each step instead of layering on unknown settings.