To determine whether a VPN is working, do not rely only on the client’s “Connected” status. This usually means the client has established a connection or handshake with the remote route; it does not prove that browser, download, or other app traffic is passing through it. The most reliable approach is to record your network state before connecting, then check your public IP, DNS resolution path, and specific apps in order. Finally, review split-tunneling rules, the system proxy, and routing mode.
Separate these questions during troubleshooting: can the route be established, is the system taking over traffic, and does the target app follow that method? The first can work while the others fail, even though the client reports a successful connection. Conversely, a changed public IP does not mean every request uses the same path. DNS, IPv6 traffic, local-network requests, and apps excluded by rules may still use the original network.
First distinguish “connected” from actually handling traffic
A proxy or VPN client usually completes several separate steps: reading the node configuration, establishing a session with the server, setting the system proxy or a virtual network interface, writing routing rules, and then processing requests according to split-tunneling policies. The connection toggle usually summarizes only some of these steps. If another program changes system policies, the virtual interface lacks routes, or an app ignores the system proxy, the toggle can remain on while the access path stays unchanged.
Different protocols do not change this logic. Shadowsocks, VMess, Trojan, and VLESS are commonly used with a proxy client alongside a system proxy or virtual network interface; Hysteria2 and TUIC likewise require the client to pass app traffic to the corresponding connection. A successful protocol handshake only proves that the client can reach the node. Whether the whole device is covered depends on the client mode, operating-system routing, and split-tunneling rules.
| Observed signal | What it indicates | What it does not prove |
|---|---|---|
| The client shows Connected | The node session has probably been established | It does not prove that every app uses the route |
| The browser’s public IP changed | That browser’s test request used the new exit | It does not directly represent other apps or the DNS path |
| The target website opens | A usable path exists for the current request | Accessibility alone cannot show which path was used |
| A DNS test shows unfamiliar resolvers | DNS requests may be handled by the route side or a custom service | The resolver name alone cannot identify the exit for all traffic |
You also need to distinguish between the two common traffic-handling methods: the system proxy and a virtual network interface. A system proxy depends on apps reading the operating system’s proxy settings; browsers generally support this well, while some games, command-line tools, and standalone updaters may ignore it. Virtual-interface mode takes over more traffic at the network layer and usually offers broader coverage, but it is still affected by excluded routes, split-tunneling rules, and local network settings.
Use your public IP for the first check
Your public IP is the most straightforward item to verify. First disconnect the client, open this site’s IP check page, and note the current address and approximate location. Close the page, connect to the target route, and open the test page again. Do not simply refresh a tab that has been open for a long time: browser caching, page-script state, or reused connections can affect the result.
- Disconnect the route and confirm that the client has returned to its disconnected state.
- Open the IP check page and record the original network exit.
- Close the test tab, then connect to the route you plan to use.
- Open the test page again and compare the address and location with the selected route.
- Repeat the check in another browser or a private window to rule out extension and cache effects.
If the address has not changed, first check the client’s current mode. Rule-based mode may classify the IP test site as a direct connection, so it still shows the original exit. During troubleshooting, temporarily switch to global or virtual-interface mode for comparison; once the cause is clear, restore the split-tunneling settings suited to everyday use. Do not keep temporary troubleshooting rules indefinitely, as local websites, LAN devices, or work resources could take an unnecessary remote path.
If the address changed but the location clearly does not match the selected node, first account for database differences. IP geolocation comes from different databases, and city-level results can vary. A single city name is not evidence of a route failure. More useful checks are whether the address changed from the original network exit and whether several test sources broadly point to the target country or region.
If the browser test is normal while other software still uses the original network, the issue has usually narrowed from “is the route connected?” to “is the app being handled?” There is no need to keep changing nodes; continue by checking the client mode and the behavior of the specific app.
Check whether DNS resolution falls back to the original network
When you access a domain, the device usually performs a DNS lookup first, translating the domain into a reachable address. Web content passing through a remote route does not automatically mean DNS requests use the same path. If the system continues sending lookups to a resolver provided by the original network, this is commonly called a DNS leak. It may not prevent pages from loading, but it makes the resolution and access paths inconsistent and can cause incorrect location results, resolution errors, or unexpected split-tunneling behavior.
Run a DNS test both while disconnected and while connected, then compare the resolver ownership. If only resolvers from the original network appear after connecting, the client may not have taken over DNS. If both original-network and route-side resolvers appear, parallel resolution, browser-encrypted DNS, system caching, or multiple active interfaces may be involved.
- ✅ Run tests before and after connecting, and save both results for comparison.
- ✅ Check whether the browser has its own Secure DNS setting enabled.
- ✅ Check whether the client offers remote DNS, proxy DNS, or leak-protection options.
- ✅ After changing settings, close old tabs and start a fresh test.
- ❌ Do not assume the route is faulty just because an unfamiliar resolver appears.
- ❌ Do not clear only browser records while ignoring the operating system’s DNS cache.
A browser’s built-in encrypted DNS can make results more complicated. It may bypass system DNS settings and connect directly to the resolver selected by the browser, or it may downgrade automatically according to system policy. During troubleshooting, temporarily make the browser follow system settings and see whether the client can take over resolution. Once the path is clear, choose either browser-managed or client-managed resolution to avoid competing policies.
A split-tunneling client may also decide the path by domain rules. If DNS resolution uses one policy before rule matching and another afterward, some domains may receive an address suited to the original network and then be sent through the remote route; others may receive a route-side address but be classified as direct. This often appears as some sites working while others time out, even though the public IP test looks normal.
IPv6 also deserves a separate check. If the original network supports IPv6 but the route handles only IPv4, dual-stack apps may prefer an unmanaged IPv6 path. If the test page shows both address types, confirm that both match expectations. If the client does not handle IPv6, enable the relevant support in the client, adjust routing, or temporarily disable that path for comparison during troubleshooting. Do not change system network parameters without recording the original settings.
Verify each app separately, not just the browser
A successful browser test does not mean the entire device is covered. Apps handle networking differently: browsers usually follow the system proxy; some desktop software uses its own proxy settings; command-line programs may read environment variables; games and real-time communication tools may send UDP directly; store apps and system services may also be constrained by operating-system sandboxing or background policies.
Test the apps you actually plan to use instead of opening many at once. Close the app, connect the route, restart the app, and use a feature that clearly reflects its network location or exit. An already-running app may retain an old connection; even after system routes change, its existing session may not rebuild immediately.
Browser
Start by checking extensions. A proxy extension may override the system proxy or proxy only the current browser. If the client and extension are enabled together, traffic may be double-proxied or rules may conflict. Keep only one traffic-handling method during troubleshooting. Private windows often disable some extensions and are useful for comparison, but confirm whether the browser allows extensions to run in private mode.
Desktop software and command-line tools
If desktop software offers options such as “Use system settings,” “No proxy,” or “Custom proxy,” first confirm which one is selected. Command-line tools may read environment variables such as HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY. An existing terminal window does not always receive variables added later, so reopen the terminal after changing them and test again.
Check sequence
Disconnect the route → record the original exit
Connect the route → run a test in a new browser window
Restart the target app → perform the actual access test
Compare the client connection log → confirm whether the rule matched
Switch the traffic-handling mode → run the comparison againReal-time communication and UDP-based apps
Some apps use TCP for login requests but UDP for voice, video, or real-time data, which can result in “login works, but calls fail.” Confirm that the node protocol, client, and current network can handle the UDP traffic the app requires. System-proxy mode usually covers this traffic less completely than virtual-interface mode, so use virtual-interface mode for cross-checking during troubleshooting.
If only one app is failing while the exits and DNS for other apps are normal, first check that app’s settings, firewall permissions, existing connections, and split-tunneling match. Changing routes repeatedly is unlikely to locate the issue. If the client provides connection logs, check whether the target domain or address was marked as proxied, direct, or blocked. Use logs to evaluate rules, not just total traffic volume.
Common false-connection symptoms and fixes
“It looks connected, but traffic is not using the route” is rarely a single-issue failure. The patterns below can help narrow it down. Change one thing at a time and repeat the same test after each change; changing the node, protocol, DNS, and mode together makes the result impossible to attribute.
| Symptom | Possible cause | Check first |
|---|---|---|
| No app shows a changed exit | The system proxy was not set, the virtual interface did not take over, or routes conflict | Traffic-handling mode, system proxy status, virtual-interface permissions |
| The browser works, but other software does not | Other software ignores the system proxy or uses its own proxy | App network settings, virtual-interface mode, per-app rules |
| The exit changed, but DNS still belongs to the original network | DNS was not taken over, or the browser uses its own resolver | Client DNS options, browser Secure DNS, system cache |
| Some sites connect directly while others use the route | Rule-based split tunneling is working as configured, or a rule is matching incorrectly | The rule matched by the target domain and the rule order |
| The old location still appears after changing routes | A reused connection, cache, or geolocation database differences | Restart the app and test again with another source |
| The app logs in, but real-time features fail | UDP is not covered, the network is restricted, or split tunneling is inconsistent | Protocol support, client mode, and the app’s traffic type |
Subscription links and client configuration can also create misleading results. After a subscription update, the client may still have an old node selected, and nodes with the same name may not share the same configuration. For persistent problems, refresh the subscription, check its update time and the currently selected node, then reconnect. Do not paste a subscription link into a web testing tool or send it to anyone else; it usually contains account-linked information.
Running multiple clients at the same time is another common source of conflicts. One client may set the system proxy while another creates a virtual interface; closing one may restore old settings, making the final state difficult to interpret. During troubleshooting, fully exit other proxy or VPN clients and keep only the software being tested. Closing a window does not always mean the app has exited; check its background status.
After switching from Wi-Fi to Ethernet, a hotspot, or waking from sleep, the existing virtual interface and default route may stop working. The client can still show a connection because the session has not updated yet. Disconnect and reconnect first; if that fails, quit and relaunch the client. Corporate, hotel, and public networks may also restrict certain connection methods. Trying another protocol can provide a comparison, but first confirm that basic web access works normally.
Complete the final verification in a fixed order
After making changes, run the complete check from the beginning. Do not combine results from different settings. The final result should come from the same connection, rule set, and network environment. This checklist is useful after changing clients, importing a new subscription, or adjusting split-tunneling rules.
- ✅ Record the original exit and DNS baseline while disconnected.
- ✅ After connecting, the exit address changes as expected and broadly matches the selected route’s location.
- ✅ The DNS test does not unexpectedly show only the original network’s resolution path.
- ✅ IPv4 and IPv6 are handled as specified by the current client configuration.
- ✅ Browser extensions do not override or duplicate the client proxy.
- ✅ The desktop app you use has been restarted and tested separately.
- ✅ The split-tunneling log shows that the target request matched the expected rule.
- ✅ Any temporary global mode or test setting has been restored.
- ❌ Do not treat whether one website opens as the only test.
- ❌ Do not change every network option at once during a single troubleshooting session.
If the public IP, DNS, and several apps all match expectations, the connection can be considered to be correctly handling the traffic that needs it. If only one app fails, continue with its settings and split-tunneling rules. If every app fails, return to the system proxy, virtual interface, and routing layers. If the exit is normal but resolution is not, focus on DNS and the browser’s independent resolver settings. Layered troubleshooting is more stable and easier to reproduce than repeatedly switching nodes.