How can you tell if your VPN is working? Don’t rely on the connection button alone. A better approach is to compare your public IP, check your DNS route, then test the apps you actually use. Each check answers a different question: a successful browser test doesn’t prove that all traffic from your device is routed through the VPN.
First, decide which traffic should use the VPN
“Working” depends on what you want the VPN to do. With rule-based routing, local sites may connect directly while selected international sites use the proxy—that may be exactly what you expect. If you want all supported traffic to use the VPN, check which traffic is covered, not just which region you selected. Define your goal before testing so you can tell normal split tunneling from traffic that isn’t being routed as intended.
Most clients can configure a system proxy and may also offer a virtual network adapter or TUN mode. A system proxy provides a proxy route for apps that honor the system settings; it doesn’t force every program to use it. TUN mode routes traffic through a virtual network interface, but coverage still depends on routing, excluded processes, protocol support, and client settings. “Global” may mean all proxy rules, not all traffic on the device.
A connected indicator shows that the client has entered a connection state. A node latency test shows that a particular probe received a response. Neither alone confirms that an app’s actual traffic is using the expected route.
Compare your public IP: establish a baseline before connecting
Your public IP tells you which internet address a website sees for your request. Check it on the What’s my IP page, but remember that the result reflects only the route used for that page’s request. If the lookup domain matches a direct-connection rule, the page may show your local public IP even while other sites use the proxy.
- Disconnect the client and record your baseline. Check your public IP in the browser you plan to use, and note the address, network provider, and reported region. Stay on the same internet connection throughout the test to avoid confounding results.
- Connect to the route you want to test and run the check again. Refresh the result; if the page may be cached, close it and reopen it. Don’t rely on text that was already loaded in an old tab.
- Check which rule matched. Review the client’s connection list or logs to see whether the lookup domain used the proxy or connected directly, and which node was selected.
- Continue testing in the app you want to use. Even if your browser’s IP has changed, check the target app too. A browser proxy extension may affect only the browser, not other programs.
A changed IP usually indicates that the request took a different route, but it doesn’t prove that it went through the node you selected. Switching networks, an upstream exit changing, or another proxy can also change the address. Conversely, an unchanged region doesn’t necessarily mean the VPN failed: geolocation databases can lag, and different nodes may share an exit IP. Check the address, network provider, and client logs together.
Check DNS: focus on the route, not just the region
DNS translates domain names into addresses that devices can connect to. A DNS leak generally means that lookup requests didn’t follow the expected protected route and instead went to the local network or another unintended resolver. The key question is whether the actual DNS route matches your configuration, not whether a particular country appears in the test results.
Browser-based DNS test pages typically trigger temporary domain lookups and show the resolver exits observed by the testing service. The addresses shown may not be the DNS servers configured directly on your device. Public DNS providers may use anycast or forwarding, so a resolver’s location doesn’t have to match the VPN node’s region.
- ✅ Run a DNS test while disconnected and record the results. Then connect to the VPN, test again, and compare.
- ✅ Check the client’s DNS interception, remote resolution, and routing settings. Names vary between clients, so refer to the relevant documentation.
- ✅ Check whether your browser has its own Secure DNS setting enabled. Browser-based and system DNS lookups may take different routes.
- ✅ Review the client logs to confirm whether DNS requests and their upstream connections use the expected route. Don’t rely only on the test page’s region labels.
- ❌ Don’t assume a leak just because the test lists multiple resolvers, and don’t assume that “encrypted DNS” means DNS traffic is necessarily routed through the proxy.
Encrypted DNS protects queries between your device and the resolver. If the connection to that resolver goes direct, the resolver may still see your local public IP. Conversely, a resolver in another region may be entirely consistent with your configuration. Judge the route, not the geographic label.
On Windows, nslookup example.com can help show which server handles a standard DNS lookup and what result it returns. It can’t confirm that your browser uses the same resolution method or, on its own, prove that there’s no leak. Browser Secure DNS, client-side resolution, and system DNS may all work independently.
Test individual apps: what to check after the browser
An app may ignore the system proxy or use a different transport. Start the client, then fully quit and reopen the target app before making a new search, refresh, or playback request. Cached pages, downloaded content, and old background connections don’t provide enough evidence.
Then look for the target process or related domains in the client’s connection list. Check the matching rule, whether the connection is direct or proxied, the selected node, and whether new connections or traffic appear when you perform the test. An app may contact several domains; sign-in, images, APIs, and media may match different rules, so checking only the home page isn’t enough.
| What you see | Possible explanation | What to check next |
|---|---|---|
| Browser exit changes, but the app’s doesn’t | The app ignores the system proxy or is excluded by a process rule | Check the app’s proxy settings, process rules, and TUN coverage |
| Exit changes, but DNS looks similar to the baseline | DNS may still use the original route or the same public resolver | Check DNS settings and logs; don’t judge by the resolver name alone |
| IP lookup still shows your local public IP | The lookup domain may be connecting directly, or the browser may not be using the proxy | Check which rule matched the lookup request, then review traffic interception settings |
| The client shows traffic, but the target app still doesn’t work | The traffic may come from background checks or another program | Trace the target domain or process instead of relying on total traffic |
| Web pages work, but real-time communication or media doesn’t | Relevant UDP traffic, domains, or address families may not be handled as expected | Check protocol support, routing rules, and the app’s connection records |
On mobile devices, a VPN indicator usually means that a network extension or tunnel is running; it doesn’t mean every app uses the same exit. Per-app settings on Android, excluded routes on Apple platforms, and settings in other network tools can all affect coverage. Check what your current client actually supports.
Common false alarms: cache, address families, and region restrictions
Old connections and cached data can hide changes
After switching nodes, existing connections may continue using the old route, and page content may come straight from the cache. Reopen the target app and make a new request; that’s more useful than repeatedly toggling the connection. If you need to clear the DNS cache, use the steps for your operating system and account for the browser’s own cache too.
Different address families may use different routes
A device may have public connectivity over more than one address family. A lookup that tests one doesn’t prove the other is covered too. If the client or routing rules cover only some traffic, an app may prefer a different route. Check the client’s address-family support and routing settings, then use a tool that reports each result separately. Don’t disable system features blindly.
Interpret WebRTC results by address type
Browser real-time communication may use a different route from ordinary web traffic. A local interface address or a masked hostname in a WebRTC test doesn’t automatically mean your public IP is leaking. If an unexpected local public IP appears, check browser policies, the UDP route, and the client’s traffic coverage. A single web test can’t speak for every app.
A platform’s region notice isn’t a general-purpose VPN test
A platform may determine access using account region, payment details, location permissions, past sessions, and IP risk signals. So if your exit IP has changed but the platform still reports a region restriction, that doesn’t necessarily mean the VPN isn’t working. Likewise, being able to open one platform doesn’t prove that other apps or DNS are routed as expected. VPN routing and platform authorization are separate issues.
Troubleshoot in order and keep reproducible evidence
When something goes wrong, don’t change the node, DNS, connection mode, and app installation all at once. Change one setting at a time and repeat the same request so you can identify what helped. First confirm that the subscription imported successfully, the route is still listed, and the client can connect. Then check traffic coverage and routing rules.
A subscription link lets the client retrieve configuration; importing it successfully doesn’t mean all traffic is using that configuration. If nodes are missing or the configuration won’t update, follow the steps in Quick Start. If a particular site isn’t working, see the troubleshooting tips in Access Troubleshooting.
When reporting an issue, include your operating system and client name, current mode, target domain, time of the problem, matched rule, and redacted screenshots. Don’t share your subscription link, access token, or full account credentials publicly; someone else could use them to access your configuration.
Bottom line: You can be reasonably confident that a particular setup is working when your public IP matches expectations, the DNS route matches your configuration, and new requests from the target app use the right route. Direct connections under split-tunneling rules aren’t necessarily a problem, and a successful browser test doesn’t verify the whole device.