VPN Leak Test — Check If Your VPN Is Actually Protecting You

A VPN leak test is not one test. It is four, and they check different layers. Most people run the first one, see a different IP, and conclude the tunnel is working — while three other paths stay open.

The four things that can leak

Layer	What leaks	What the leak reveals	Where it usually breaks
IP	Traffic routed outside the tunnel while the VPN is connected	Your real egress address, and your provider	Kill switch not enabled, split tunnelling, app bound to the physical adapter
DNS	Hostname lookups sent to the local or ISP resolver	Every domain you visit, in sequence	System resolver list not replaced, IPv6 DNS outside the tunnel
WebRTC	Public addresses gathered through the media stack	Your real IP, even while the page loads through the VPN	STUN reachable on the physical interface; VPN client not tunnelling UDP or IPv6
TLS	Not a leak in the usual sense — a stable client identifier that survives IP rotation	That all your "different locations" are the same machine	Proxies relay the handshake instead of originating their own

The first three are leaks of data you meant to hide. The fourth is a consistency problem: it does not expose an address, it undermines the story that you are somewhere else.

Why testing only the IP is misleading

IP leaks are the loudest failure and the easiest to fix, so clients handle them first. That leaves the quieter paths. A connection can show the VPN's address in the browser while DNS queries go to the ISP and a WebRTC candidate advertises the home address. Every individual check that the user actually ran passed.

There is a second, subtler issue: many leaks are intermittent. They appear when a second interface wakes up, when the Wi-Fi reconnects, when the machine resumes from sleep, or when a mobile hotspot switches from Wi-Fi to cellular. A single test taken thirty seconds after connecting samples the calmest moment in the whole session.

A test sequence that finds real leaks

1. Baseline, VPN off. Record your real IP, your resolver, and your WebRTC candidates. Without a baseline you cannot tell a leak from a routing choice you made deliberately.
2. Connect, then test immediately. This catches configuration errors — the resolver list that was never replaced, the kill switch that was never armed.
3. Test again after ten minutes of browsing. This catches interface churn. Reconnect the Wi-Fi deliberately before testing if you want to provoke it.
4. Suspend and resume the machine, then test. Kill switches frequently fail to re-arm after resume, and the tunnel may reconnect while the routing table does not.
5. Repeat one check through a second device behind the same exit, if you are comparing providers. It separates client behaviour from provider behaviour.

Reading the combination, not the individual result

The useful signal is the pattern across all four layers:

IP	DNS	WebRTC	What it means
VPN	VPN	mDNS name or VPN	Clean. Nothing to fix.
VPN	Local or ISP	Clean	DNS is outside the tunnel. The IP check alone would have said "fine".
VPN	VPN	Real public IP	Classic WebRTC leak. Common on IPv6-enabled networks with IPv4-only clients.
VPN	VPN	Private 192.168.x.x	Host candidate exposure. Reveals LAN structure rather than your identity.
Real IP	Any	Any	The tunnel is not carrying traffic at all. Check the routing table before anything else.

The three failures that cause most leaks

The kill switch is a label, not a guarantee. Some clients implement it as a firewall rule that is removed on disconnect; others only block traffic while the client process is running. If the client crashes, the rule goes with it. Verify by killing the VPN process and checking whether traffic still flows.

Split tunnelling is a feature that leaks by design. Anything excluded from the tunnel uses the normal route, including its DNS lookups. If you exclude a subnet for a local service, be aware that name resolution for that path is outside the tunnel too.

IPv6 is the quiet one. An IPv4-only VPN on an IPv6-capable network leaves a complete, unmanaged path. Disabling IPv6 on the adapter is the reliable fix; relying on the client to "handle it" is not.

Fixing, in the order that actually resolves problems

1. Turn off IPv6 on the adapter if the provider does not tunnel it. This removes an entire class of leak in one step.
2. Point DNS explicitly at the provider's resolver and confirm the VPN adapter carries it.
3. Enable the kill switch, then test it by killing the process, not by reading the settings screen.
4. Disable WebRTC if you do not need browser calling, or restrict it by policy.
5. Re-run all four checks after every client update. Updates routinely reset DNS settings and firewall rules.

FAQ

If the IP test passes, am I safe?

No. It proves one layer. DNS and WebRTC are independent and fail separately.

Does a leak test itself put me at risk?

No. It observes what your browser and network already expose to any site you visit.

Why does my VPN show the right IP but the site still knows my location?

Usually a DNS or WebRTC leak, or a timezone and language mismatch. Test the other three layers before blaming the provider.

Do free VPN clients leak more?

Not categorically, but free clients more often omit kill switches and IPv6 handling, and some route DNS through their own resolver in ways that are hard to verify. The test tells you which case you are in.

Is a TLS mismatch a leak?

Not in the data-exposure sense. It is an inconsistency that reveals client identity rather than an address, and it survives changing IPs.