To confirm that a VPN is really working, do not rely only on the client’s “Connected” status. That status usually proves only that the client and remote node completed a handshake; it does not prove that your browser, desktop apps, DNS queries, and other traffic are using the intended route. A reliable check covers the public IP, DNS resolution path, and per-app results.
The safest approach is to compare results before and after disconnecting: record your local network’s public IP and DNS details, connect to a node and repeat the tests, then open the app you actually plan to use. If any layer differs from expectations, check the proxy mode, split-tunneling rules, system permissions, and the app’s own network settings instead of repeatedly clicking Connect.
First define “working”: connecting does not mean taking over traffic
When the client shows a connection, the control plane has usually completed node selection, protocol negotiation, and authentication. Access results are determined by the data plane: whether the operating system sends target traffic to the client, whether the client forwards it according to its rules, and whether the remote endpoint becomes the actual egress for the request.
System proxies, virtual network adapters, and in-app proxies are different ways of taking over traffic. A system proxy mainly affects software that reads the system proxy settings; virtual-adapter mode receives more traffic at the network layer; an in-app proxy applies only to programs where a proxy address has been configured. The connection status may look identical while the coverage differs completely.
| Check layer | What to observe | What it proves | What it does not prove by itself |
|---|---|---|---|
| Client status | The node is connected without repeated reconnects | This device can establish a session with the node | That business apps are using the session |
| Public IP | The location or network provider changes before and after connecting | The tested request reached a new public egress | That all apps and DNS use the same path |
| DNS resolution | The resolver matches the expected route | Domain queries are not visibly routed back through the local network | That the resulting business connection definitely passes through the node |
| Per-app testing | The target app’s egress and access results match the rules | The app’s actual traffic is being handled by the tunnel | That other untested apps use the same path |
Check the public IP: compare results before and after connecting
Your public IP is the most straightforward first layer of evidence. After disconnecting the client, use a browser to check your current public egress and record the country or region, network provider, and address type. Then connect to the target node, close the old results page, open it again, and compare the results. If the egress location changes with the node, that browser request most likely passed through the remote egress.
- Disconnect, then pause browser proxy extensions and any other tools that may rewrite traffic.
- Open a new private browsing window, check your current public egress, and record its location details.
- Connect to the target node and wait for the client status to stabilize. Do not reuse cached results from the old page.
- Open the test page again and compare the egress location, network provider, and address type.
- Switch to another browser or desktop app that you actually use, then run an independent test.
Do not rely only on the city name shown on a map. IP geolocation databases can lag behind updates, and the same address range may be associated with another nearby city. More useful than the city label are whether the public address changed, whether the network changed, and whether the destination website sees an egress broadly consistent with the selected region.
Dual-stack networks can create another common false positive: one address family may pass through the node while the other still exits through the local network. Some test pages prioritize one address type, making the result look correct even though apps using the other type may bypass the tunnel. If different websites show different egress locations on the same device, check whether the client fully handles both address families, or temporarily disable the unmanaged address type and test again.
- ✅ Use a new page and new requests before and after connecting so cached content is not mistaken for the live egress.
- ✅ Compare the address, network, and region together instead of relying on one city label.
- ✅ Retest with the app you actually use rather than drawing conclusions from a single browser tab.
- ❌ If the client says connected but the egress remains identical to the disconnected state, continue checking the traffic-handling mode.
- ❌ Different egress results across apps usually indicate inconsistent proxy settings or split-tunneling coverage.
Check DNS resolution: distinguish local queries from remote queries
Before visiting a website, a device usually resolves its domain name into a reachable address. If business traffic passes through the node while DNS queries still go to a resolver on the local network, a DNS leak may occur. It may not stop pages from loading, but it can expose queried domains to the local network and cause the region, content delivery, or resolution result to conflict with the egress.
Before testing, clear old DNS cache, visit a domain you have not opened recently, and check which resolver the test page detects. The ideal result is not necessarily a resolver whose name matches the VPN brand, since the node may use a public DNS service or a provider-side resolver. The key is that the resolver should not consistently belong to the local access network or reveal a path that clearly conflicts with the target egress.
Browser secure DNS can change the test result
Modern browsers may enable secure DNS and bypass the operating system’s default resolver settings. In that case, a browser test shows only how the browser resolves names, not how other software does. Conversely, if the browser specifies an encrypted DNS service, seeing that service on the test page does not necessarily indicate a leak; it may be the expected result of the browser configuration.
First clarify the goal. If you want the client to handle all DNS queries, temporarily disable the browser’s custom resolver and test again. If you want the browser to keep using a specified secure DNS service, confirm that this connection itself uses the node and separately verify DNS paths for system apps. Do not equate “the resolver name is not the node name” with a failure.
Caching can mix old and new routes
The operating system, browser, and apps may all cache DNS results. If you refresh an old page immediately after connecting to a node, the app may use an address obtained before disconnecting without making a new DNS query. A more reliable approach is to clear system and browser caches, close and restart the app, and request a domain that has not been visited recently.
- ✅ Clear the DNS cache before making a new domain request.
- ✅ Check the browser and system apps separately to see whether they use the same resolution strategy.
- ✅ Assess the detected resolver together with the expected egress and the client’s DNS settings.
- ❌ If a resolver from the local access network keeps appearing, check the client’s DNS traffic-handling options.
- ❌ Refreshing an already open page cannot rule out an old DNS result still being cached.
Run per-app tests: confirm which route each app actually uses
Once the public IP and DNS look correct, check the apps you actually use one by one. The reason is simple: programs handle proxy settings differently. Browsers commonly support system proxies, some desktop apps use their own network stacks, command-line tools may connect directly by default, and games or real-time communications apps may use transports that do not pass through traditional web proxies.
With system-proxy mode, only apps that follow the system setting enter the proxy path. Virtual-adapter mode usually covers more network requests, but routing tables, exclusion rules, and system permissions still matter. In-app proxies have the clearest boundary: apps with the proxy configured use the node, while apps without it keep their original route.
| App type | Common traffic-handling method | Common false positive | Recommended test |
|---|---|---|---|
| Web browser | System proxy, extension, or virtual network adapter | An extension and the client are both active, making the actual route unclear | Disable extra extensions, then check the public IP and DNS in a new window |
| Desktop productivity software | System proxy, in-app proxy, or virtual network adapter | The sign-in page uses the proxy while background sync connects directly | Test sign-in, syncing, file transfers, and notifications together |
| Command-line tool | Environment variables, app parameters, or virtual network adapter | The browser works, leading you to assume the terminal is also covered | Request egress information directly from the terminal and inspect proxy variables |
| Real-time communications app | Virtual network adapter or a proxy that explicitly supports the required transport | Text messaging works, but voice or video uses another route | Test messaging, calls, media, and file features separately |
The protocol name alone does not define traffic coverage. Shadowsocks, VMess, Trojan, and VLESS describe how data is encapsulated, authenticated, or transported between the client and node; Hysteria2 and TUIC place more emphasis on QUIC-based transport characteristics. Whether an app enters these sessions is still determined by the system proxy, virtual adapter, routing, and split-tunneling rules. A successful protocol handshake does not eliminate the need for per-app testing.
When testing the target app, do not check only whether its home page opens. For productivity software, test sign-in, message sync, attachments, and background notifications separately; for streaming apps, check search, detail pages, and actual playback requests; for developer tools, check web authentication, terminal requests, and package downloads independently. A single app may use multiple domains and transport methods, so one working feature does not prove that all traffic follows the same route.
Read the split-tunneling rules instead of only switching to “Global”
Split-tunneling rules usually determine direct or proxied traffic by domain, address range, app, or rule set. If the target domain matches a direct rule, the egress remains on the local network even when the node is connected. Conversely, if only specific services match proxy rules, other websites continuing to show the local egress may be the expected result.
When troubleshooting rules, first inspect the client’s connection log or session list to see which rule matched the target request, then check rule priority. Domain and address rules may coexist, and the first matching rule usually determines the route. After changing rules, close the target app, clear its cache, and create a new request so an old connection does not keep using the previous path.
Handle common cases where the client says connected but traffic is not using it
If the client stays connected but the egress does not change, check the traffic-handling mode before changing the protocol. The system proxy may not have been written successfully, the app may ignore system settings, the virtual adapter may lack required permissions, or another network tool may have taken over the route. First quit programs that modify the proxy, DNS, or routing, then reconnect and watch whether the system network settings change with the client status.
System proxy is enabled, but the app still connects directly
This usually means the app does not read the system proxy or reads it only at startup. Fully quit and reopen the app, then check its network settings. If it supports a manual proxy, enter the local proxy endpoint provided by the client; if it mainly uses traffic that traditional proxies cannot easily handle, test with virtual-adapter mode instead.
The browser works, but other software does not
First rule out the possibility that only a browser extension is working. Disable the extension; if the browser’s egress returns to the local network, only the extension was handling browser traffic. If the browser still works while other apps connect directly, check the system proxy, virtual-adapter permissions, and in-app settings. Do not generalize the browser result to the entire device.
The egress is correct, but domain resolution is still wrong
Check the client’s DNS options, browser secure DNS, and system cache. Enterprise and public networks may apply additional policies to DNS requests, causing resolution results to differ from the remote egress. Within the client’s supported options, try remote resolution and establish a new connection. If only one app is affected, check whether it uses an embedded resolver.
The old region still appears after switching nodes
Close the old connection first, then clear the app cache and existing sessions. A web service may determine content from sign-in state, account region, cache, or a previous session rather than the current IP alone. Use a new private window to check the public egress, confirm the network layer has changed, and only then assess the app-level region information.
- ✅ Quit other tools that modify the proxy, DNS, routing, or virtual network adapter.
- ✅ Check whether the client mode covers the traffic type used by the target app.
- ✅ Review matched rules and connection logs to confirm whether the request was sent direct or through the proxy.
- ✅ Fully restart the target app after changing settings and establish a new network session.
- ❌ Repeatedly switching nodes without checking the traffic-handling method usually will not fix an app bypassing the tunnel.
- ❌ Mistaking the account region or page cache for the live egress can turn an app issue into a routing issue.
Follow a repeatable connection check workflow
A one-off visit to a test page is easily affected by caching and app settings. A more effective approach is to use a fixed sequence every time you change devices, networks, or rules. This makes it easier to identify whether the problem lies in the node connection, system traffic handling, DNS, or a specific app.
- Establish a baseline. Disconnect the client and record the current egress location, system resolution method, and the target app’s access results.
- Connect to a node. Confirm that the client is no longer reconnecting repeatedly, and check whether the selected mode was successfully applied to the system settings.
- Check the egress. Compare the public egress in a new browsing session, and watch for different paths on dual-stack networks.
- Check DNS. Clear the cache, make a new query, and distinguish browser-specific resolution from system resolution.
- Check the app. Test each relevant feature and use the session list or rule log to confirm where the traffic went.
- Restore the baseline. Disconnect and check the egress again, confirming that the system proxy, routes, and DNS have returned as expected.
The final step is often overlooked. An abnormal exit can leave system proxy or DNS settings behind, preventing normal access after the client disconnects. Checking the restored state distinguishes an unavailable node from local settings that were not reverted and prevents the next test from using a faulty baseline.
The connection status has full meaning only when the public IP, DNS, and app tests all match expectations. If one layer fails, you do not need to replace every setting at once: an unchanged egress points to the traffic-handling mode, a DNS issue points to resolver settings, and a single app bypass points to its proxy and split-tunneling rules. Layer-by-layer diagnosis is faster than blindly switching protocols and nodes.