To determine whether a VPN is working, do not rely only on the client showing “Connected.” A more reliable approach is to check the exit IP, DNS resolution path, and where traffic from the actual app is going. The connection status only shows that the client completed a network session; system proxies, virtual adapters, split-tunneling rules, or app-specific settings may still send some requests through the original network.
A complete check should answer several separate questions: which exit handles public traffic, which resolver handles domain lookups, whether the browser and command line use the same path, and whether the target app bypasses the system proxy. Reviewing these results together helps distinguish between a tunnel that was never established, only some traffic being routed through it, and a working tunnel with an unexpected result from the test site.
A connected client does not mean every request is using the tunnel
Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC establish the transport channel, but the client still determines which system traffic enters it. Common methods include a system proxy, virtual network adapter mode, and an in-app proxy. A successful protocol handshake only shows that the local client can communicate with the remote node; it does not by itself prove that every program uses this path.
A system proxy usually affects only apps that honor the operating system’s proxy settings. Browsers generally read those settings, but some command-line tools, games, download clients, and apps with their own network stack may connect directly. Virtual network adapter mode takes over traffic at a lower network layer and usually covers more traffic, though routing tables, exclusion lists, and LAN rules still apply. An in-app proxy affects only the programs configured to use it.
When testing, avoid equating “the browser can access the site” with “the entire device is using the route.” Conversely, a failed connection in one app does not necessarily mean the node is down; the app may ignore the system proxy, or its protocol may be configured for a direct connection by the current rules.
| Observed result | Possible cause | Next check |
|---|---|---|
| Browser exit changes, terminal exit does not | Only the system proxy is enabled | Check terminal proxy variables or virtual network adapter mode |
| Exit changes, but DNS still uses the local network | DNS requests are not being handled by the route | Check the client’s DNS and encrypted DNS settings |
| Some sites use the route while others connect directly | Split-tunneling rules are active | Review matching records for domains, IPs, and rule sets |
| None of the tests change | The proxy was not applied or the route was not established | Check the system proxy, virtual network adapter, and default route |
Start by using the exit IP to confirm the public traffic path
The exit IP is the public source address seen by the destination site. Before connecting, it usually corresponds to the current network’s public gateway. After connecting, if the test request actually passes through the remote node, the address shown by the page or API should change with the exit location. Compare the results before and after; do not judge quality solely by the country or carrier associated with the address.
Before testing, temporarily reduce the effect of browser caching and make sure the test page sends a fresh request. Confirm the result in both a normal window and a window without extensions, since proxy extensions can override system settings. If the device supports both IPv4 and IPv6, check both address types separately; checking only one may miss traffic that is still using the original network.
The command line provides an independent reference outside the browser. The following command requests a public exit-address lookup API:
curl https://api.ipify.orgIf the browser result has changed but the command line still returns the pre-connection exit, the current setup probably applies only to the browser or system proxy, while the command-line tool is not reading the proxy configuration. Run the test again with virtual network adapter mode enabled to further determine whether the operating system route has been taken over. With an in-app proxy, you can also specify the proxy explicitly in the command before comparing the results.
Databases that map exit IPs to locations may update slowly, and different lookup services may report different cities or network names. To determine whether the VPN is working, focus on whether the address changed and whether different apps produce consistent results—not on requiring every database to show exactly the same location.
DNS checks show where resolution requests go
Before accessing a domain, a device usually queries DNS to obtain its destination address. If web traffic enters the route while DNS requests go directly to a resolver provided by the local network, the resolution path and access path may diverge. The industry commonly calls an unexpected DNS request that bypasses the intended route a DNS leak.
However, a test page showing a local resolver does not always prove that the client is malfunctioning. Modern browsers may enable encrypted DNS, the operating system may use cached results, and the client may use remote resolution, mapped addresses, or a built-in DNS module. Corporate networks, home gateways, and security software may also rewrite the resolution path. Judge the result together with the client configuration and system state.
On Windows, use the following command to view domain lookup results:
nslookup example.com
Resolve-DnsName example.comOn macOS, view the resolver configuration maintained by the system:
scutil --dnsOn Linux environments using systemd-resolved, check the current interface and resolver status:
resolvectl status
resolvectl query example.comThese commands show system-level information, while a browser’s encrypted DNS may bypass the system resolver. If command-line and browser results differ, check the browser’s secure DNS setting. If you want the client to handle resolution consistently, make sure its DNS module is enabled and verify that split-tunneling rules have not incorrectly set the resolver itself to direct access.
Use per-app tests to find programs that bypass the route
Apps on the same device may use different network stacks. Browsers usually follow the system proxy, while command-line tools depend on environment variables and their own options. Some games and real-time communication apps use UDP and may ignore proxy methods that support only TCP forwarding. Other apps have built-in proxies, encrypted DNS, or connection reuse, so their behavior can differ from the system settings.
For troubleshooting, perform network requests separately in a browser, terminal, and the target app, while watching the client’s connection records. If the client can show logs by process or destination domain, focus on whether each request ultimately matched a proxy, direct, or reject rule. Do not just check whether a domain appears in the log; confirm the outbound policy recorded for that entry.
- Refresh the exit-address lookup page in the browser and record whether the address changes.
- Run the exit-address lookup command in the terminal and compare it with the browser result.
- Disable the browser’s built-in encrypted DNS, test again, and restore the setting if needed.
- Open the target app, perform a real request, and watch the client’s connection records at the same time.
- Check whether the default policy for unmatched rules is proxy or direct.
- If the app uses UDP, confirm that the current traffic-capture mode and route configuration support it.
If only the target app avoids the route, first check its proxy settings, process-based routing, and UDP handling instead of repeatedly changing nodes. If no app shows a change, return to the system proxy, virtual network adapter permissions, and routing table. Per-app testing narrows the scope of the problem and prevents a rule issue from being mistaken for a route issue.
Split-tunneling rules can make partial routing the expected result
Split tunneling is not intended to send every request through the same exit. It selects proxy or direct access based on the domain, IP, app, or network type. For example, local services may connect directly, cross-border requests may use an international route, and LAN addresses may remain on the local network. Different sites seeing different exits may therefore be exactly what the rules specify.
Rule matching usually follows a priority order. Domain rules may take effect before IP rules, while a final rule handles requests with no match. After a subscription rule set is enabled, legacy rules, custom user rules, and client defaults may all coexist. Troubleshoot by tracing actual connection records back to the matched rule instead of inferring behavior only from the text of the rule file.
DNS policy also affects the accuracy of split tunneling. If the client relies on the domain to choose a route but the app resolves the domain to an IP first and connects directly, the client may see only the address and be unable to apply the original domain rule. DNS hijacking or address mapping in virtual network adapter mode can improve visibility, but inconsistent settings can also produce successful resolution followed by a failed connection.
What to check on each platform
Windows
On Windows, check the system proxy, virtual network adapter status, and DNS interface priority together. Some desktop programs do not read the system proxy, so it is common for the browser to work while other programs connect directly. After changing the traffic-capture mode, reopen the target program so existing connections do not continue reusing the old path.
macOS and iOS
A macOS client may use the system proxy or create a network extension, and the two methods cover different traffic. On iOS, clients generally use the system-provided VPN network extension, but the app’s own encrypted DNS, LAN access policy, and on-demand connection behavior can still affect test results. After changing the configuration, let the test page establish a new connection.
Android
Android clients generally handle traffic through the system VPN interface and may provide per-app proxy settings or a bypass list. If only one app keeps the same exit, first check whether that app is excluded. Android’s Private DNS may also operate independently of the client’s DNS policy; consult the client documentation to decide whether to keep it or let the route handle resolution.
Linux
On Linux, differences mainly come from desktop proxy settings, environment variables, routing tables, and DNS management components. A graphical interface setting may not affect terminal processes, and proxy variables in a terminal may not affect system services. Check the current shell, service processes, and virtual network adapter routes separately rather than assuming they share one configuration.
Troubleshooting order when the interface says connected but tests fail
When the connection appears normal but the exit does not change, checking each network layer in sequence is usually more effective than repeatedly reinstalling the client. First confirm that the request enters the client, then confirm which outbound path the client uses, and finally check the remote route and resolution results.
- Disconnect the route and record the current exit IP and DNS state to establish a baseline for comparison.
- Reconnect and confirm that the client reports no handshake, permission, or configuration parsing errors.
- Check whether the system proxy was applied, or whether the virtual network adapter was created successfully and received a route.
- Review the connection record for the test request and confirm that it matched a proxy rule rather than a direct rule.
- Test the browser, terminal, and target app separately to determine whether the issue is limited to one program.
- Check whether browser encrypted DNS, system DNS, and client DNS are overriding one another.
- Confirm that both IPv4 and IPv6 traffic meet expectations so that only one protocol stack is not being handled.
- Test again with another route to distinguish a local configuration issue from a connection issue affecting a specific node.
If the test request does not appear in the connection records at all, the issue usually lies between the app and the client; check proxy settings, virtual network adapter permissions, or the app’s exclusion list. If the record shows direct access, focus on the split-tunneling rules. If it shows proxy access but the exit remains unchanged, confirm that the test page did not use a cached result and check the remote node and outbound path actually selected by the client.
IEPL dedicated lines, relay routes, and direct routes describe different transport paths. With a direct route, the device connects straight to the remote node. A relay route connects to an entry point first, then uses the relay network to reach the exit. An IEPL dedicated line generally provides dedicated transport between the entry and exit. Regardless of the route type, the site should ultimately see the exit configured for the connection, not the entry node. An exit check can verify the final source address, but a test page alone cannot reveal the entire transport path.
How to reach a reliable final conclusion
A reliable conclusion comes from several results confirming one another: browser and command-line exits match expectations, DNS queries follow the configured policy, the target app’s connection records show the correct outbound path, and direct and proxied results in split-routing scenarios match the rules. If only one test site reports a problem, use another way to verify it and consider differences caused by location databases, caching, or browser networking features.
After testing, restore the encrypted DNS, split-tunneling rules, and app exclusions needed for everyday use. The goal is not to keep all traffic on one exit permanently, but to confirm that each traffic type follows its configuration. A connected status is only the starting point; the exit IP, DNS path, and per-app records together provide a more complete verification chain.