When a VPN connects but does not actually work, the cause is rarely a single failure. “Connected” only means the client completed some form of connection with the remote node; it does not mean your browser, desktop apps, and system services have handed their traffic to that route. An unchanged exit IP, locally resolved DNS, or an app bypassing the proxy can all produce the same result: the status says connected, but access looks unchanged.
Do not keep switching nodes and hope for a different result. A more reliable approach is to split the path into separate stages: whether the client established a session, whether the system accepted the proxy or virtual adapter settings, whether the target app matched a routing rule, whether DNS used the expected path, and whether the remote service accepted the current exit. Test each stage independently to locate the failure.
First distinguish “connected” from “traffic routed”
Different clients do not define “connected” in exactly the same way. With Shadowsocks, VMess, Trojan, or VLESS, a client may first start a local proxy port and then test the remote node. Only apps that read the system proxy settings or have an explicit proxy address configured will send requests to that local port. Other apps may continue accessing the network directly.
Hysteria2 and TUIC typically use transport methods different from traditional TCP forwarding, but whether they take over system traffic still depends on the client’s operating mode. A successful protocol connection does not prove that the routing table, virtual adapter, and split-tunneling rules were installed correctly. The protocol defines how data travels between the client and node; system takeover defines which local traffic enters that path. They are separate concerns.
System proxy mode mainly affects programs that follow the operating system’s proxy settings. TUN mode uses a virtual adapter and routing rules to receive a broader range of network requests, making it better suited to desktop apps that do not read system proxy settings. An in-app proxy applies only to selected software. All three modes may appear in one client, but their names, permissions, and rule behavior vary by platform.
| Observed symptom | Likely stage | First checks |
|---|---|---|
| No app has a different exit IP | System proxy, TUN routing, or client takeover | Operating mode, system permissions, proxy toggle |
| The browser works, but desktop apps do not | The app does not read the system proxy | TUN mode, in-app proxy, split-tunneling rules |
| The exit changes, but the DNS location looks wrong | DNS path | Client DNS settings, browser Secure DNS |
| Some websites work, while others behave the same | Routing rules, cache, or target-service policy | Rule-hit logs, private window, exit region |
| An old region still appears after switching nodes | Connection reuse, cache, or session state | Close old connections, reopen the page, quit the app |
Verify the public request path with your exit IP
Your exit IP is the clearest external signal. Before testing, disconnect the route and open this site’s IP lookup to record your current network location. Connect to the target node and open the lookup page again. If the address and location change as expected, that browser’s public requests are using the remote exit. If they are identical, check whether the browser is actually being routed.
Avoid testing by refreshing a page that has been open for a long time. The browser may retain connection pools, proxy authentication, or page cache, and some sites store region data in the session. A safer method is to close the test tab, start a new browsing session, and run the lookup again. If the browser has a separate proxy extension, make sure it is not overriding the system proxy or forcing the current domain to connect directly.
- Disconnect the client, then look up and record the current exit location.
- Connect to the target node and confirm the client is not merely running a local port.
- Start a new browsing session and look up the exit location again.
- Repeat the lookup in another app and compare the results.
- Check the client logs to confirm whether the test request matched a proxy or direct rule.
A changed exit IP proves only that the tested app’s public request used the route; it does not prove that every app uses the same path. A browser may follow the system proxy while a command-line tool connects directly. Desktop apps may use their own network stack, and system updates, local-network devices, and background services may follow different rules. After verifying the exit, check DNS and per-app results as well.
Check whether DNS follows the expected route
DNS converts domain names into addresses that can be reached. Web content traveling through a remote exit does not necessarily mean DNS resolution uses the same path. If the system continues using DNS supplied by the local network, requests and lookups take different routes. This is commonly called a DNS leak. It may reveal the local network’s DNS location or return results unsuitable for the target region.
Compare the DNS resolver location before and after connecting. If the exit has changed but the resolver still clearly belongs to the local network, check whether the client has enabled remote DNS, encrypted DNS, or DNS handling through TUN. Option names vary by client, so do not assume that “automatic” means it is working; confirm with connection logs and an external lookup.
The browser may also use its own Secure DNS setting, bypassing the resolver selected by the operating system or client. That is not necessarily a fault, but it can make the client’s rules differ from the browser’s DNS path. If only one browser shows an unusual DNS result, temporarily make it follow the system settings and test again. Security software on managed networks may also control DNS; follow the requirements of that network.
- ✅ The exit location matches the selected node region, and the DNS location matches the client configuration.
- ✅ The result is the same in another browser, indicating that the issue is not a browser-specific resolver setting.
- ✅ The client log shows DNS requests and the expected proxy or remote-resolution path.
- ❌ The exit has changed, but DNS still points consistently to the local access network.
- ❌ The browser and system tools show completely different DNS locations, with no routing rule explaining the difference.
- ❌ After changing DNS, only the old page was refreshed; existing connections and DNS cache were not cleared.
After changing DNS settings, let old resolution results expire. Quit and reopen the target app, reconnect the route, and, if necessary, use the DNS-cache refresh function provided by the operating system. Do not blindly copy cleanup commands from unknown sources; commands and permission models differ across systems, and a wrong command can disrupt normal network settings.
Test the browser, client, and system services by app
Per-app testing identifies which programs work and which do not. Start with a browser known to follow the system proxy, then test a desktop app that may ignore it, and finally check a command-line tool or system service. Change only one condition at a time so you can tell whether the difference comes from the app, operating mode, or node.
The browser works, but the desktop app does not
This usually means the system proxy was set, but the desktop app did not read it. Some apps have their own proxy page, some read system settings only at startup, and others can be fully managed only in TUN mode. Check the app’s network settings for options such as “follow system,” “direct,” or a custom proxy, then choose between an in-app proxy and TUN.
If the app accepts an HTTP or SOCKS proxy, use the local address and port actually exposed by the client. Do not guess the port, and do not use a subscription URL as a proxy address. A subscription URL distributes node configuration to the client; a proxy address is the local entry point an app uses to connect to the client. They serve different purposes.
The desktop app works, but the browser does not
Browser extensions, independent Secure DNS, startup arguments, and enterprise policies can override system settings. First disable extensions that alter the proxy path, check whether the browser is set to “follow system,” and test with a new browsing session. If only one profile is affected, create a temporary profile for comparison instead of reinstalling the entire client.
Only some domains are not routed
Focus on the rule mode. Common modes include global proxy, rule-based routing, and global direct. Rule-based routing chooses a path based on domains, address ranges, processes, or rule sets. If the target domain matches a direct rule, other sites may work while that site still uses the local exit. Checking rule-hit entries in the client log is more effective than repeatedly switching nodes.
How to rule out subscription, protocol, and node settings
If the client shows nodes after importing a subscription but never carries useful traffic, distinguish between “subscription fetched successfully” and “node connected successfully.” A subscription URL is only a configuration entry point and typically contains the node address, port, protocol, and authentication parameters. Successfully downloading it does not mean every node can establish a session on the current network.
When importing, choose a subscription format the client explicitly supports. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different parameter structures and cannot replace one another by changing only the protocol name. If the client version does not support a transport method in the subscription, it may show the node name without connecting correctly. Prefer the client recommended by the provider and use its update-subscription function; do not manually delete or alter authentication fields.
If a node connects but carries no data, inspect the logs for the handshake, authentication, DNS resolution, and routing details. Authentication failures usually indicate an expired configuration or mismatched parameters; timeouts may involve the local network, node address, or transport method; a request marked direct indicates a rule issue; logs showing only a local port starting, with no remote session, suggest that the client has not actually reached the node.
Relay, direct access, and IEPL describe different ways of organizing a network path. Direct access usually sends traffic from the user’s network straight to the node entry point; a relay first reaches an intermediate entry and then forwards traffic to the target exit; IEPL focuses on dedicated transport across the international segment. These affect the path and suitable use cases, but they do not replace local proxy takeover. Even when the route itself works, apps will not use it if the system proxy is off or a rule sends them direct.
Common platform differences and troubleshooting order
Desktop systems usually support both system proxy and virtual-adapter modes, but TUN often requires additional permissions. Without them, the client may still show the node as connected even though the routes were not fully installed. Check for prompts to approve a network extension, virtual adapter, or administrator access, then reconnect after granting permission.
Mobile operating systems usually take over traffic through their built-in VPN interface. If another network tool, content filter, or managed configuration is using that interface, a new connection may not work as expected. Confirm the active configuration in the system network settings rather than relying on the button inside the app. Battery-saving policies may also limit background connections, making the route work briefly in the foreground and fail after switching apps.
Command-line programs differ in their support for proxy environment variables. Some read HTTP proxies, some support SOCKS, and some ignore system proxy settings entirely. Before testing a command-line request, check that tool’s proxy documentation. If you need to route programs without proxy support, evaluate TUN mode instead of applying browser results directly to the terminal.
- ✅ First confirm that the client has selected the correct node and operating mode.
- ✅ Then use an exit lookup to verify the baseline browser.
- ✅ Next check the DNS location and the browser’s independent resolver settings.
- ✅ Then inspect the proxy, permissions, and rule hit for the affected app.
- ✅ Only then switch nodes or protocols, so you do not change several conditions at once.
- ❌ Changing configurations repeatedly without checking logs makes the original issue impossible to reproduce.
Complete troubleshooting checklist when it still does not work
If the cause remains unclear after the basic checks, review the path from the local device to the remote service in order. First rule out a wrong subscription selection and client-mode issue, then check system permissions, app overrides, DNS, and cache, and only afterward investigate node connectivity and target-service restrictions. This preserves a clear cause-and-effect trail.
- Confirm that the selected node belongs to the subscription currently in use, not an old configuration or duplicate group.
- Confirm that the client is using the expected option: system proxy, TUN, or in-app proxy.
- Check whether the operating system accepted permissions for the proxy, virtual adapter, and network extension.
- Disconnect and record the original exit, then reconnect and compare results in a new browsing session.
- Check the DNS location and confirm that the browser has not independently overridden the resolution path.
- Search the client log for the test domain and confirm that it matched a proxy rule rather than a direct rule.
- Repeat the exit check in another app to determine whether the issue is global or app-specific.
- Close old pages and connections before testing again to rule out cache, sessions, and connection reuse.
- With the configuration unchanged, switch nodes to determine whether the issue is limited to one node.
- Keep the relevant logs and reproduction steps, then send specific fault details to support.
When reporting an issue, include the operating system, client name, operating mode, protocol, affected app, whether the exit changed, whether DNS changed, and the error category in the logs. Do not include authentication details or the full subscription URL in screenshots or ticket text. Redacted logs are far more useful for diagnosis than “it won’t connect.”
The final test is not whether the client icon changed color, but whether the target app’s request path matches expectations: the exit location is correct, the DNS path is explainable, routing rules match correctly, and differences between apps are accounted for by their proxy settings. Following this order narrows most “looks connected but traffic is not routed” issues to a specific stage.