How can you tell whether a VPN is really working? You cannot rely solely on the client showing “Connected.” This status usually means only that the local proxy core has started or that the client has completed a handshake with the selected route. It does not by itself prove that traffic from your browser, desktop apps, and command-line tools is using the intended exit. A reliable check combines the exit IP, the DNS resolution path, and the actual behavior of specific apps.
Before testing, identify the connection mode. A client with TUN enabled usually creates a virtual network interface and takes over system routes. System proxy mode mainly affects software that follows the operating system’s proxy settings. A browser extension handles requests only in that browser. Split tunneling sends some destinations through the proxy while keeping others direct. Because each mode covers a different scope, one result cannot represent the entire device.
First, confirm what the client actually controls
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all carry proxy traffic, but the protocol name does not determine how system traffic enters the tunnel. Coverage depends on the client’s entry method, such as a system proxy, TUN virtual network adapter, in-app proxy, or manually configured local port. Even when a node connects normally, apps that are not routed through a proxy entry will still access the network directly.
| Connection method | Typical coverage | What “Connected” usually means | What still needs checking |
|---|---|---|---|
| TUN mode | Traffic routed by the system into the virtual interface | The virtual interface and proxy core are running | Default routes, exclusion rules, and IPv6 paths |
| System proxy | Apps that follow the system proxy settings | The local proxy port is running and has been added to system settings | Whether an app ignores the proxy or its settings have been overridden |
| Browser proxy | A specified browser or browser profile | The extension or browser proxy configuration is enabled | Other apps may still connect directly, and browser DNS needs a separate check |
| Split tunneling | Only domains, addresses, or apps matched by the rules | The rule engine and route are available | Whether the request matched a proxy rule or a direct-connection rule |
A subscription link is only a configuration entry point. After importing it, the client receives routes, protocol parameters, and possibly split-tunneling rules, but a successful import does not mean the system proxy is enabled. Some desktop clients separate “select a node,” “start the core,” and “set system proxy” into distinct actions. On mobile platforms, traffic is often handled through the system VPN interface. Check the current mode first, then decide whether the test result makes sense.
- ✅ Confirm that the selected route is the intended one, rather than an automatic choice or the route used last time
- ✅ Confirm that at least one entry point—system proxy, TUN, or an in-app proxy—is enabled
- ✅ Confirm the split-tunneling mode and know whether the test domain is expected to use the proxy or connect directly
- ❌ Assume that every app is covered simply because the client shows a timer or changes color
- ❌ Import a subscription without starting a route or sending traffic into the local proxy interface
Compare your exit IP before and after connecting
Your exit IP is the most direct thing to check. Do not simply open an IP lookup page after connecting. First disconnect the VPN and record your current public exit address, network operator, and approximate region. Close the test page, connect to the target route, and run the lookup again. If the address and network ownership change as expected, the test request probably passed through the proxy exit.
- Temporarily disconnect the client and disable any browser extensions with their own proxy settings.
- Look up your public IP in a browser and record the address, network owner, and region as your direct-connection baseline.
- Connect to the route you want to verify and confirm that system proxy or TUN mode is enabled.
- Run the lookup again in a new private window to avoid interference from cached pages or persistent connections.
- Send a request from another app and check whether it receives the same proxy exit.
If the address is exactly the same before and after connecting, do not assume the node has failed. The browser may have an independent proxy extension enabled, the system proxy may not have been applied, or the site may be reusing a persistent connection opened before the test. Close the relevant pages and reopen them, or test with a browser that has no extensions to eliminate these factors.
Also check split-tunneling rules. In rule mode, domestic sites, local network addresses, or specified services may be designed for direct access, so seeing your original network exit when checking a direct destination is not contradictory. Choose a destination that clearly matches a proxy rule, or temporarily switch to global proxy mode for comparison. Restore the original split-tunneling mode after testing so traffic that does not need the proxy does not take a longer route indefinitely.
The browser changes, but other apps do not
This usually means the proxy covers only the browser. A browser extension may be enabled, or the desktop client may have configured only the system proxy while the target app ignores it. Game launchers, sync tools, command-line programs, and some apps with their own networking stack may not read system proxy settings. Configure a proxy for the app separately, or use TUN mode to take over its traffic.
Check whether DNS requests resolve through the expected path
After the exit IP changes, DNS still needs checking. DNS converts domain names into network addresses. If web requests use the proxy route while domains are still resolved by the local network’s resolver, the destination and resolution paths are separated. This is commonly called a DNS leak. In a deliberately configured split-tunneling setup, however, direct domains using local DNS and proxy domains using remote DNS may be normal. Always judge the result against the intended rules.
A DNS test page in the browser can show which servers handled the lookup and who operates them. After connecting, if proxy domains continue to be resolved by a resolver provided by the local network, check the client’s DNS mode, remote-resolution option, and the browser’s own encrypted DNS settings. A browser may bypass the system resolver, while a client may use virtual DNS or domain sniffing for split tunneling. Conflicting settings can make the results difficult to interpret.
At the system level, start by viewing the current DNS configuration. The following command is for observation only and does not change network settings:
Windows
ipconfig /all
nslookup example.com
macOS
scutil --dns
nslookup example.com
Linux
resolvectl status
nslookup example.comnslookup shows the resolver used for the current query, but it may not fully represent the browser’s resolution path. If the browser has its own secure DNS enabled, the system command and browser test may differ. Check both system and browser results, and use the client log to see whether the target domain appears.
Why IPv6 can make the results look inconsistent
A device may have both IPv4 and IPv6 connectivity. If the client takes over only one protocol while the browser prefers another available path, some requests may use the route while others connect directly. An IP lookup page may then show an unexpected exit, and the address type returned by DNS can also affect the final path.
During troubleshooting, check whether the client supports IPv6, whether the TUN interface has the corresponding routes, and whether split-tunneling rules handle both address families. Do not treat disabling IPv6 as a universal permanent fix. A safer approach is to confirm that the client can take it over correctly, or explicitly prevent the system from exposing an unmanaged path to the target app.
Test apps individually instead of letting the browser represent the whole device
A successful browser test proves only that requests from that browser probably used the expected exit. If your use case includes meeting apps, cloud drives, developer tools, desktop clients, or terminal programs, test each one separately. Apps may read proxy settings differently or bypass system settings and establish connections directly.
- Keep the target route connected and confirm that the browser exit has changed.
- Fully quit the app under test and relaunch it to avoid reusing a session created before connecting.
- Check the client connection log for a new request when the app accesses the target.
- If the client supports viewing matches by process or rule, confirm that the request entered a proxy rule.
- Switch to direct mode and repeat the same action, then compare whether the app behavior and logs changed.
Logs are more informative than whether a page opens. If a service works in both direct and proxy environments, page availability alone cannot confirm the route. When the client log shows the target domain, destination address, matched rule, and selected route, you can connect app behavior to the actual forwarding path. Before sharing logs, remove subscription links, authentication details, and complete configuration content.
Command-line tools often have their own proxy settings. Terminal environment variables, a tool’s proxy arguments, and the system proxy may be independent. If the browser exit has changed but terminal requests still connect directly, check whether the current terminal session inherited old proxy variables or whether the tool explicitly ignores the system proxy. After making changes, reopen the terminal; this is usually more reliable than repeating tests in an old session.
Common reasons traffic does not use the route despite a connected status
The system proxy was not applied successfully
The client core can connect to the node normally, while the operating system still retains an old proxy, manual proxy, or automatic configuration script. The client then shows Connected, but no app sends requests to the local proxy port. Close other proxy tools, check the system network settings, and re-enable the system proxy in the client.
TUN routes were overridden by another network tool
Virtual machines, containers, enterprise network clients, and other virtual adapters can all change route priority. The TUN interface may exist while default traffic is carried away by a higher-priority route. Temporarily quit programs that modify network paths, reconnect the route, and restore them one by one to identify the conflict.
The rules classified the test destination as direct
Domain, address, and geographic rules may produce different results. After a target domain resolves to an address, another address rule may override the result. The final matched rule in the client log is more reliable than simply reading the rule list. If global mode works but rule mode does not, the issue is usually the interaction between rules and DNS, not the route handshake.
The browser kept an old connection or uses separate DNS settings
Modern browsers reuse connections and may enable their own encrypted DNS. Refreshing an old page immediately after connecting may not create a new network session. Fully close and reopen the browser, use a new private window, and compare system DNS with browser DNS results to reduce false conclusions.
An old configuration is still active after a subscription update
A subscription update may change route parameters or rules, but some clients require you to select the new node manually or reload the configuration before applying it. Check the active configuration name, update time, and selected route rather than only looking for new content in the subscription list. A subscription link is a sensitive credential and should not be pasted into public test sites or screenshots.
Use a fixed order for the final troubleshooting pass
When the client shows Connected but the access path has not changed, the most effective approach is to check each layer from entry to exit instead of repeatedly switching protocols or nodes. Change only one condition at a time so you can identify which setting caused the result to change.
- ✅ Check that the current configuration, route, and connection mode match your expectations
- ✅ Disconnect the route and record the direct exit, then reconnect and compare again in a new window
- ✅ Check the DNS resolver used for proxy destinations and the client’s DNS settings
- ✅ Test the browser, desktop apps, and command-line tools separately
- ✅ Check the final rule, destination address, and route actually selected in the logs
- ✅ Check for bypass paths caused by IPv6, virtual adapters, and other network tools
- ❌ Change the node, protocol, DNS, and split-tunneling rules at the same time, making the variable impossible to isolate
- ❌ Treat an imprecise region label as direct evidence that the connection is not working
If the exit IP does not change, first check the traffic entry point and system proxy. If the exit changes but the DNS path is unexpected, check remote resolution, browser DNS, and split-tunneling policy. If the browser works but one app does not, check whether it reads the system proxy and whether it needs TUN coverage. If only some destinations fail, focus on rule matches and address types. This order narrows the problem to one layer: the client entry point, DNS, routing, or app configuration.