I noticed my real location may still be visible while connected to my VPN. What’s the most reliable way to test for DNS, WebRTC, and IP leaks and confirm my VPN is protecting my privacy?
A VPN can hide your public IP without hiding every clue about your location. Check your IP, IPv6, DNS servers, and WebRTC results before connecting, then repeat in a private browser window after connecting. None of the original addresses should remain. Disable browser location permission so GPS or Wi-Fi geolocation does not confuse the test. Finally, interrupt the VPN connection while loading a page. If your real IP briefly appears, the kill switch is not working properly.
If split tunneling is enabled, a different IP may be intentional rather than a VPN failure. Turn it off before testing, and close any apps or browser tabs that were already open so old connections do not muddy the results.
For a clean test, connect to the VPN and check from two unrelated leak-testing services. Verify the reported IPv4 and IPv6 addresses, DNS resolvers, and WebRTC candidates. Your normal public IP should never appear. A DNS server does not necessarily need to be in the same city as the VPN exit, but it should belong to the VPN provider or a resolver you deliberately configured. WebRTC may display private or randomized local addresses, which is usually harmless. The problem is seeing your actual public ISP address.
@binarytester9433poin is right about testing the kill switch, though I would do it with a fresh page that reloads repeatedly rather than relying on one cached tab. Test once with the VPN disconnected unexpectedly, then again after restarting the computer. IPv6 is the common edge case here: if the VPN does not support it, it should block it completely instead of letting your ISP’s IPv6 address bypass the tunnel.
Do not test a browser-extension VPN and assume the result applies to your whole computer. Many extensions only proxy browser traffic, while email clients, games, cloud-sync tools, and other apps keep using the normal connection. For a real system-wide test, use the VPN’s desktop app and temporarily disable any browser “secure DNS” setting so it does not hide which DNS path the operating system is using.
Record your public IPv4, IPv6, and DNS provider while disconnected. Then connect and test through a browser, followed by a non-browser app or command-line IP check. WebRTC showing a private address such as 192.168.x.x is not normally a public leak. Seeing the same ISP-issued public address you recorded earlier is the red flag. An unfamiliar DNS resolver is not automatically bad, but your ISP’s resolver appearing while connected deserves investigation.
I agree with @binarytester9433poin about IPv6, but leaks often happen during transitions rather than while the tunnel is stable. Repeat the test while switching VPN servers, waking the computer from sleep, changing from Wi-Fi to a hotspot, and briefly interrupting the network. If your real public address appears at any point, the kill switch or tunnel handling is not doing what you expect.
A leak-test page can give you reasonable confidence, but no single green result proves every connection stays inside the VPN. Those sites only report what reaches that particular page at that moment. Use two independent tests, as @neontiger7942 suggested, but treat that as the quick check rather than final proof.
The most reliable verification is a packet capture or firewall log on your physical network adapter. While the VPN is connected, ordinary internet traffic on that adapter should be going only to the VPN server. You will still see local network chatter, and you may see the VPN endpoint itself. What you should not see is a direct connection to the website or service you are testing. Direct DNS requests to an ISP resolver are another warning sign. This takes more effort than a leak-test site, but it removes much of the guesswork caused by inaccurate location databases.
For the browser tests, compare actual addresses rather than city names. A VPN address showing the wrong city is often just stale IP geolocation data. WebRTC showing 192.168.x.x, 10.x.x.x, an IPv6 local address, or an obfuscated candidate is not the same as exposing your ISP-issued public address. DNS is similar: the resolver may be operated by the VPN, a third party chosen by the VPN, or a service you configured yourself. The concern is whether the request is bypassing the tunnel, not whether the resolver pin lands beside the VPN server on a map.
I would test in stages: first with the connection stable, then during server changes, sleep and wake, and a forced VPN disconnect. Keep a page refreshing or use firewall logging so a brief fallback is not missed. @omegahive5590lab is right that transition failures matter, although I would be cautious about intentionally dropping the tunnel while logged into anything sensitive. Use a harmless test page and close unrelated apps first.
Finally, test the type of traffic you actually care about. A browser result says little about a torrent client, virtual machine, game, or app with its own proxy settings. If the VPN allows application exclusions, split tunneling, “trusted network” bypasses, or local-network access, disable those temporarily. If your original public IPv4 or IPv6 appears anywhere, or traffic reaches an outside destination directly during a tunnel interruption, assume protection is incomplete until you find the setting responsible.
A site guessing your real city is very different from a site showing your exact ISP-issued public IP. City guesses can come from browser location permission, nearby Wi-Fi data, timezone, language, old cookies, or a logged-in account. A VPN only changes the network path. It does not automatically erase those other location clues.
Start by recording your disconnected IPv4, IPv6, ISP name, and DNS resolver. Then connect the VPN and compare the actual addresses, not the map pin. Your original public IPv4 or IPv6 should be gone. For DNS, your ISP’s resolver is suspicious, while a VPN-operated or intentionally configured third-party resolver is usually fine. With WebRTC, ignore private addresses like 192.168.x.x or 10.x.x.x. The bad result is the same public address your ISP gave you.
Use a clean browser profile with location access denied, no extensions, and no logged-in accounts. That helps separate an actual VPN leak from Google, a weather site, or some other service remembering where you normally are. I’d still check from a second browser or device because browser settings such as secure DNS can change the result without changing what the rest of the computer is doing.
One small trap with kill-switch testing: clicking the VPN app’s normal Disconnect button may deliberately restore your regular connection, so that does not prove the kill switch failed. Test an unexpected interruption instead, such as killing the VPN process, putting the machine to sleep and waking it, or briefly dropping and restoring the network while a harmless IP-check page refreshes. If the original public IP appears even briefly, protection is incomplete. @crystalfalcon5757nod is right that packet capture or firewall logging is the strongest check, but for most people, matching exact addresses across two independent tests plus a proper interruption test is enough to catch the common failures.
Phones are the blind spot here. Everyone’s talking desktop apps and packet captures, but most people actually browse on a phone where you get almost no visibility into what’s happening. On Android, look for the ‘always-on VPN’ plus ‘block connections without VPN’ toggle in settings, and turn it on. Without that, the tiny window between the network coming up and the tunnel connecting is wide open, especially after you unlock the phone or swap from Wi-Fi to cellular. iOS is worse for checking, since the built-in VPN can silently reconnect and you won’t see the gap unless something is watching the traffic.
The rest of the thread is solid, and @crystalfalcon5757nod is right that a green leak-test page only tells you about that one request. I’d just add that on mobile you basically can’t do the firewall-log check most people are describing, so match exact addresses across two tests, toggle Wi-Fi off and on a few times, and treat any flash of your carrier IP as a fail.
Don’t run a DNS test using only pages you already visited, because cached lookups may create no new DNS request at all. Clear the browser and operating-system DNS caches, connect the VPN, then test fresh random hostnames while checking IPv4, IPv6, DNS, and WebRTC. Compare exact addresses with your disconnected baseline. Private WebRTC addresses are fine, but your ISP-issued public IP or ISP DNS resolver is a failure. Repeat after sleep, a server switch, and a network change, since a stable connection is the easiest case to pass.
Don’t rely only on an exact IP match, since ISPs can rotate your address and make a leak look “different.” Check the network owner or ASN too: if the result still belongs to your ISP instead of the VPN, congratulations, you found the leak wearing a new number.