Free tools Windows power users keep installed
One-click scans. No signup required.
To check whether your VPN is routing traffic as intended, compare your public IP address and DNS results with the VPN off and on, then test IPv6, WebRTC, and what happens during a connection interruption. A “connected” label in the VPN app is not enough: the checks below show what a particular browser and device reveal, but they do not prove that every app or network transition is protected.
Before you start: record your normal connection
Use the same device, browser, and test pages for each check. Turn off the VPN and any other VPN or privacy relay that could obscure your ordinary connection. Record your public IP address and apparent network or provider, run a DNS leak test and note the resolvers it reports, and check whether IPv6 is available. This baseline gives you something meaningful to compare against.
For browser-based checks, BrowserLeaks provides an IP address test, a DNS leak test, and a WebRTC leak test. These are third-party diagnostics, not a complete audit of your VPN client or device.
Run the checks with the VPN connected
1. Check the public IP address
Connect to the VPN and reopen the same IP test. The reported public address should reflect the VPN’s internet exit rather than the address you recorded with the VPN off. If it still matches the ordinary connection, investigate whether the VPN is connected, whether routing is working, and whether split tunneling excludes the browser.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
2. Check DNS separately
Run the DNS leak test while connected. Compare its reported resolvers with the VPN-off results, then check your VPN provider’s documentation to understand what resolver behavior is expected. An IP check does not reveal where DNS queries went; resolver branding or apparent location alone may also be insufficient to prove that queries bypassed the tunnel.
3. Check IPv6, if your baseline had it
Repeat the IPv6 check with the VPN connected and look for an address or traffic associated with your ordinary connection. If IPv6 was absent before you connected, its absence during the VPN test is inconclusive: there was no IPv6 traffic on the baseline network to test for leaks.
Rank #2
4. Check WebRTC in the browser you use
Run the WebRTC test while connected and look for your ordinary public address rather than the VPN route. WebRTC address handling is a distinct browser privacy consideration, described in IETF RFC 8828. The result applies to the browser and configuration tested; it does not certify native apps or every browser.
Test interruptions, network changes, and split tunneling
Verify the kill switch during a controlled drop
If your VPN has a kill switch, enable it and cause a controlled VPN disconnection. Check whether internet access is actually blocked until the VPN reconnects; do not rely only on the app’s status indicator. Once it reconnects, confirm access returns. AMTSO’s guidance states that “No data packets should exit the device unencrypted (via any other network interface except the VPN interface).” Its procedure checks connectivity and leaks during a drop, then checks that access returns after reconnection.
Repeat checks after changing servers or networks
Recheck after changing VPN servers, switching Wi-Fi access points, or moving between Wi-Fi and mobile data. A steady-state browser test is only a snapshot; it cannot establish how the VPN behaves during a transition. AMTSO recommends testing these conditions rather than relying on the app’s connected display.
Check which apps use the tunnel
Review split-tunnel settings and confirm that the browser you are testing is included if it is supposed to use the VPN. If possible, compare an excluded browser with an included one, and check whether traffic expected to use the VPN exits through another network interface. An excluded app may intentionally use the ordinary connection, so interpret its result in light of your settings.
Rank #4
How to interpret the results
- VPN-on IP matches the VPN-off IP: Treat this as a reason to investigate routing, split tunneling, or whether the VPN is actually connected—not as a diagnosis by itself.
- DNS results differ: Compare the resolvers with the VPN provider’s documented behavior. A different resolver name or location by itself does not conclusively establish a leak.
- No IPv6 appears: That result is useful only if IPv6 was available with the VPN off. Otherwise, the test is inconclusive.
- WebRTC shows an ordinary address: Investigate the tested browser’s WebRTC behavior and configuration. This result does not establish how other apps or browsers behave.
- Internet access continues during a VPN drop: Check the kill-switch setting and whether traffic can leave through another interface. A status message alone cannot confirm that traffic was blocked.
For a fair comparison between two VPN setups, keep the device, browser, test pages, access network, VPN location, and test sequence consistent. Compare the public IP, DNS behavior, IPv6 where available, WebRTC in the tested browser, and protection during a controlled interruption and network transition. State which platform and configuration were tested; results from one setup should not be generalized to all devices or VPN configurations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
