How can you tell if your VPN is really working? Don’t rely on the client’s “Connected” status alone. A more reliable approach is to note your IP before connecting, connect to the route you want to use, compare the IP afterward, and check whether DNS requests and the apps you use follow the expected path. Each check answers a different question: an IP comparison shows where websites see your connection coming from, a DNS test shows which resolver looks up domain names, and an app-by-app check confirms whether the apps you’re using are excluded by split-tunneling rules.
First, clarify what you need: should your browser use a specific route for international websites, or should relevant apps across your device use it? The right way to verify depends on your goal. Follow the repeatable checks below, then troubleshoot individual settings if the results don’t match.
Check your exit IP first: compare the same test before and after connecting
Your IP is the public address a website sees—not the local address your device uses on your home or office network. Disconnect from the VPN, open My IP in your browser, and note the public IP and approximate location. Then connect to the route you plan to use, refresh the page, and note the result again. For a meaningful comparison, use the same browser, page, and network both times; switching networks in between can invalidate the results.
If your public IP changes after connecting and roughly matches the selected route’s exit region, that shows this page’s request used a different exit. It only confirms that requests from the page you checked changed; it doesn’t prove that every app or domain is using the same route. IP geolocation databases can also be out of date, so a different city name doesn’t necessarily mean the connection failed. Focus first on whether the address changed and whether it belongs to the expected exit region.
The result reflects the exit used when you accessed the test page. With rule-based routing, the test page and the website you actually want to visit may match different rules. Check from within the target app instead of relying on a screenshot of an IP lookup.
| Check | What to look for | What it can’t prove on its own |
|---|---|---|
| IP before and after connecting | Whether the public address on the same lookup page changes | That other apps also use the route |
| Exit region | Whether it roughly matches the selected route’s destination region | That geolocation databases are perfectly accurate |
| DNS resolution path | Whether DNS requests are handled by the expected resolver | That webpage requests follow the same path |
| Target app | Whether the app can access the service as expected and shows the corresponding exit | That every program on the device follows the same rules |
Then check DNS: distinguish leaks from normal differences in DNS resolution
When you enter a domain name, your device usually looks it up through DNS to get an IP address before connecting. Your public IP alone won’t tell you which path that lookup took. Run a trusted DNS test before and after connecting, and compare the listed resolver and location. Keep your client and browser settings the same, and wait for the test to finish—don’t mistake the pre-connection results for the post-connection ones.
A DNS leak means that a query that should be handled through the selected route is instead sent to an unexpected local network resolver. A difference between the location shown by a DNS test and your exit IP location doesn’t automatically mean there’s a leak: the route may use a separate public DNS service, and the resolver’s location may not match the exit. Check your client’s DNS settings first, then see whether your browser’s “Secure DNS” feature is set to use a specific resolver, and finally review your routing rules.
Encrypted DNS in the browser can be especially confusing. When enabled, the browser may bypass the system’s default resolver and send encrypted queries directly to the selected service, so the DNS test may show a different resolver from the one configured in your operating system. Another possibility is that domain lookups go direct under your rules while webpage traffic uses the VPN route. Check your actual settings in either case; an unfamiliar name in the test results alone isn’t proof of a problem.
A DNS test isn’t a report of every traffic path. It mainly shows the DNS requests generated by the test. To check whether a particular app’s web traffic or connections use the VPN route, verify the exit and routing rules from within that app.
Test each app: a working browser doesn’t mean your whole device is covered
Some clients run in system VPN mode, while others only forward requests from apps configured to use a proxy. Even when the client says it’s connected, routing rules may send some domains or apps directly. First compare IP and DNS results in your usual browser, then repeat the relevant checks in the app you actually want to use. If the app doesn’t show exit information, check whether it can open a webpage, or review the client’s connection logs and rule-match details to see where requests are going.
Be careful not to mix browser configurations during testing. One browser may have its own proxy extension, while another uses the system’s network settings. An extension typically affects only the requests it manages, so it doesn’t show that other programs have switched routes. Incognito mode isn’t a network-path testing tool either; it mainly changes how browsing history is stored locally and doesn’t override the client’s routing rules.
Network status appears in different places on different platforms. Windows and macOS users can check both the client’s connection status and the system’s network settings. On iOS and Android, make sure the configuration you intend to test is enabled, then check again in the target app. An operating system’s VPN-connected status only means a tunnel has been established; it doesn’t guarantee that every app uses it. To check other programs, follow the mode and routing details provided by your client.
- ✅ Disconnect and note the original public IP on the same lookup page.
- ✅ Connect to the route you want to test, refresh the lookup page, and note the new exit IP.
- ✅ Run a DNS test in the same browser and check the resolver against your configuration.
- ✅ Open the app you actually want to use and check its results or rule-match logs.
- ✅ After switching networks or reconnecting, check your exit again; don’t rely on old results.
- ❌ Don’t assume all traffic is using the VPN based only on a “Connected” indicator or the exit region shown.
Connected but not working? Troubleshoot the traffic path
Your exit IP hasn’t changed: First make sure you refreshed the lookup page and aren’t looking at a cached result. Then check whether the client is using system VPN mode, system proxy mode, or only routing traffic from selected apps. If you’re using rule-based routing, check whether the IP lookup site is set to go direct. You can temporarily switch to the client’s global mode for comparison, then restore your original rules. Global mode is a diagnostic tool, not a setting you necessarily need to use all the time.
The browser changed, but other apps didn’t: Check whether the apps follow the system proxy, need to be handled by the client, or are excluded by app-specific rules. Support for system proxies varies between programs. Importing a subscription link into a client only adds route configuration; it doesn’t mean app traffic is being routed. Make sure the route is connected and the selected mode fits your needs.
IPv4 looks right, but IPv6 doesn’t: If your network and the target website both support IPv6, check the exit for each address type separately. Whether the client handles IPv6 depends on its configuration. If IPv6 requests aren’t using the expected route, check the client’s IPv6 support and routing settings. Don’t ignore the path used by IPv6 just because an IPv4 lookup shows the expected region.
It works right after connecting, then stops: Check what happens when your device sleeps, switches networks, or the client reconnects. The tunnel may recover at a different time from the app’s next connection attempt, and existing connections may not immediately use the new path. Reload the page, restart the affected app, and then check the client’s logs or connection status. If the issue only happens after a network switch, check the automatic reconnect and disconnection settings first.
DNS results don’t match expectations: Check the browser’s Secure DNS setting, the client’s DNS configuration, routing mode, and your local network’s DNS settings—in that order. Change one setting at a time and retest so you can identify what affected the result. Keep a record of the before-and-after checks, too, to avoid comparing results from different network conditions.
How to tell when you’re done checking
Your original goal should determine what counts as a successful check. If you only need specific websites in your browser to use the VPN route, compare the exit in that browser, confirm the site matches the expected rule, and check the relevant DNS path. If you want several apps to use the route, check them individually; a browser result isn’t a substitute. A location label from a lookup tool, a connection icon in the client, and the actual result in an app are evidence from different layers.
Bottom line: Compare your IP before and after connecting, check the DNS resolver, and then verify routing in the target app. If all three match your expectations, the VPN is working for that use case. If any result is off, troubleshoot that part of the path instead of repeatedly switching routes and hoping for the best.
With VPNSL, start by comparing your exit on the My IP page, then check the mode and routing rules in your client against what happens in the apps you use. Repeat the checks whenever you switch routes, change DNS settings, or move to another network. A successful test only describes that connection at that time; it doesn’t guarantee the same result on future visits.