How can you tell if your VPN is working? First compare your exit IP before and after connecting, then check where DNS requests go, and finally test the apps you actually use. “Connected” is only a starting point: it usually means a session has been established, but does not prove that your browser, desktop software, and background services are all using the intended route.
Before testing, define what you expect: should only selected websites use an international route, or should most device traffic enter the tunnel? With split tunneling, some requests staying on a local direct connection is normal. Clearly defining the intended route gives you a basis for judging the test and helps avoid mistaking correct routing for a failed connection.
Distinguish Connection Status from the Actual Route
What people commonly call a VPN client may use a system tunnel or forward traffic through a local proxy. A system proxy usually affects only apps that honor that setting. TUN mode takes over matching traffic through a virtual network interface, but is still subject to routing, exclusions, and system permissions. The same button color does not mean the same coverage.
Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC do not tell you directly which apps are using the connection. Protocols handle different parts of connecting and transmitting; whether an app uses that connection still depends on the client’s routing mode and rules. Successfully importing a subscription only means the configuration can be read—it does not replace a real-world access test.
| Check | What it can confirm | What it cannot confirm on its own |
|---|---|---|
| Client shows connected | The client reports that a session is established | That every app is using the route |
| Website exit IP changes | That this web request used a different exit | The route used by other apps and DNS |
| DNS test lists resolvers | That these DNS services handled the test queries | The complete path between the queries and the resolvers |
| Target app works normally | That the app’s current function is available | That all its background connections follow the intended route |
Compare Your Exit IP Before and After
Your exit IP is the source address a website sees for a request; it is not your device’s address on a local network. Start by disconnecting the client, opening the IP check page, and recording your public address, network attribution, and the test time. Then connect to the intended route and run the test again in the same browser. Avoid changing your browser, network, and node at the same time, or the results will be difficult to compare.
- Record a baseline while disconnected. If the device has another proxy, a browser extension, or a corporate network tunnel, check whether it is still handling traffic.
- Connect to the intended route and confirm the node and split-tunneling mode currently selected in the client. Do not rely only on the status shown on the home screen.
- Reload the test page. If needed, close the old tab before reopening it to reduce errors caused by caching, an existing connection, or a page that has not refreshed.
- Compare the complete public address and network attribution. Also check whether the client’s rules route the test site directly or through the proxy.
- Disconnect and run the test again to see whether the route returns to the baseline. This round trip provides more context than seeing an address outside your region just once.
If the IP has not changed, do not rush to switch protocols. The test site may be set to connect directly by a routing rule, or the browser may not follow the system proxy. You can temporarily use a test mode with more clearly defined coverage, then check the same page again. Restore your original split-tunneling settings when you finish. Changing modes is a troubleshooting step, not a configuration you must keep using.
IP geolocation databases can be out of date, and a route’s labeled region may not match the city shown in a database. Focus first on whether the public address and network attribution changed; do not judge a connection solely by a city name.
Check Where DNS Goes, Not Just Its Region
DNS translates domain names into addresses that devices can connect to. If your exit IP has changed but domain lookups still take an unexpected route, investigate further. Common causes include the system retaining DNS settings from the original network, the client not handling DNS, or the browser using encrypted DNS independently.
Use a DNS test that makes new domain lookups, and record the resolver attribution it shows before and after connecting. A regular webpage loading does not prove that DNS went through the tunnel; the browser may have used its cache and made no new query. Conversely, detecting a resolver associated with your local region does not by itself prove a leak. Public DNS services may use nearby servers, and their location data may be inaccurate.
A more reliable approach is to compare the results with your configuration: which DNS service should the client use, should requests reach it through the proxy, and which domains are allowed to resolve locally? Browser Secure DNS or system-level encrypted DNS can change the lookup route, but encryption and using your selected route are different things; one does not guarantee the other.
If you suspect a leak, first review the client’s DNS handling and leak-protection options, then check whether the browser overrides system settings. Change only one related option at a time and retest with a new query. Clearing the cache is not a fix: it removes old results, but does not change the route of the next request.
How to interpret the results: Judge a DNS leak by whether queries bypass the intended route. The country, number of resolvers, or a prominent warning label on a test page cannot reveal the entire path. If the evidence is inconclusive, mark it for further checking rather than declaring that privacy protection has failed.
After Your Browser Passes, Test Apps Individually
A successful browser test only shows that the relevant requests from that browser followed the expected route. Desktop apps may use their own network libraries and ignore the system proxy. Some games, voice apps, and meeting tools may also require the client to support the relevant UDP forwarding. If a webpage loads but an app cannot connect, check the app’s route instead of assuming the node is completely unavailable.
On Windows and macOS, first distinguish system proxy settings from tunnel routing, then check whether the target app has its own proxy settings. On mobile devices, review system VPN permissions, per-app exclusions, and background operation. Linux desktop proxy settings can differ from command-line settings, so results from a terminal do not automatically apply to graphical apps.
- ✅ Open the app you actually want to use and perform an online task. Do not just look at its local home screen or cached content.
- ✅ Check the client’s connection logs to confirm that the target domain or process matched the intended rule. Logging options depend on the client you use.
- ✅ Review the app’s own proxy settings, exclusion list, and split-tunneling rules to make sure conflicting routing methods are not enabled at the same time.
- ✅ Repeat the key task while disconnected, connected, and after switching networks. Check whether the result changes with the route.
- ❌ Do not use one browser’s exit IP result to draw conclusions about every app, background service, or other device.
Being able to access a service also does not mean its service region has changed. Account region, payment details, location permissions, cached data, and the service’s own risk controls can all affect what you see. When checking a network route, start with the exit IP and connection logs before considering the region displayed by the service. This helps distinguish app policies from routing problems.
Additional Dual-Stack and WebRTC Checks
A device may support both IPv4 and IPv6 connections. If the client handles only one address family, some apps may choose another available route. When your test tool supports it, check both public exits separately. If the test does not detect one address family, that only means the current test did not obtain that connection; it does not guarantee coverage in every situation.
If one address family still uses the original network, first check the client’s documentation on how it handles that family and review system routing settings. Decide whether to change system configuration based on your network and the client’s capabilities. Do not disable system features just to make every indicator on a test page turn green. After any change, confirm that your everyday apps can still connect.
WebRTC supports real-time browser communication, and related tests may display candidate connection addresses. Private local network addresses, obfuscated local identifiers, and public exit addresses are not interchangeable. If a public address from the original network appears, check browser policies and the actual candidate connections. A single address field alone is not enough to show that the page sent all its traffic outside the tunnel.
When It Looks Connected but Is Not Working: Troubleshoot by Layer
Configuration: Check whether the selected configuration is the one you just imported, whether the subscription has been updated as required by the client, and whether the chosen node is still part of the active configuration. Avoid repeatedly importing the same subscription and creating several similar profiles. First confirm which one is running, then review any connection errors.
Traffic handling: Check system permissions, proxy settings, TUN status, and other network tools. Multiple proxy clients, browser proxy extensions, or corporate tunnels may compete for control. For troubleshooting, keep one clearly defined traffic-handling method active and re-enable other tools one at a time to find the source of any conflict.
Rules: Check which rules match the test site and the target app. Rule order, domain matching, and process exclusions can produce different results. If a temporary test mode works but your everyday mode does not, investigate split tunneling before switching routes again.
Network: Public networks may require portal authentication, and switching networks can invalidate an existing session. First confirm that the local network can access the internet, then reconnect. IEPL, transit, and direct connections describe route paths and arrangements; they do not replace checks for device permissions, DNS, or routing.
Subscription links may contain access credentials. Do not share a complete link, password, or unredacted logs when asking for help. Include your system, client, mode, actions, and error message, but remove credentials and unnecessary network addresses first.
Keep Retest Notes Before Drawing a Conclusion
A useful test record does not require complex tools. Note your system and client, current network, node, traffic-handling mode, exit IP before and after connecting, DNS resolver attribution, and the target app’s actual results. If a problem appears after waking the device from sleep, switching networks, or updating rules, repeat the same steps. This is more useful for finding the cause than relying on an impression that “it feels slower today.”
Also distinguish “not working” from “working, but with poor performance.” If the exit changes as expected and the app’s connection logs show that it matched the proxy, but loading is slow, check congestion, packet loss, DNS lookup time, or the target service itself. Repeatedly refreshing an IP page will not explain throughput, nor does it prove that a particular protocol is faster.
Bottom line: A solid verification combines an expected exit IP, DNS routing that matches your configuration, and confirmation that the target app follows the right rule. If any part is unclear, check the corresponding layer again. For help using a client, see the setup guide. For rules and protocol concepts, see the protocol reference.