The Four Kinds of VPN Leak, and How Each Is Detected
A leak is not a hole in the encryption. It is traffic — or a single revealing value — that never entered the tunnel in the first place, because something on your device chose a different path. That is why leaks are silent: nothing fails, nothing errors, and the client keeps reporting a healthy connection.
There are four recognised categories, they have different causes, and no single test covers all four. Knowing which category you are looking for is most of the work.
The word covers four different events
Grouping them under one label hides the fact that they escape at different layers.
An address leak means the destination sees an address other than the provider’s exit address. Either the tunnel is not carrying that traffic, or the traffic never went near it.
A DNS leak means your name lookups reach a resolver outside the tunnel — typically the one your router advertised. Your traffic can be perfectly tunnelled while the list of everywhere you went is not.
An IPv6 leak means the tunnel carries one address family and your device quietly prefers the other for anything that supports it.
A WebRTC leak means a browser feature volunteers your device’s own addresses to a page, using a mechanism that has nothing to do with routing at all.
The first three are routing and configuration failures. The fourth is an application handing over information it was designed to collect, which is why it survives an otherwise flawless tunnel.
Detecting an address leak
Compare the address a destination reports against a value you noted with the tunnel down, on the same device.
The failure signature is that the two match. A less obvious one is that they differ but the reported address still belongs to your own provider’s network, which happens when a client routes some destinations outside the tunnel by design.
Where this gets subtle is that “the address seen” is not one thing — different applications can arrive from different addresses on the same machine at the same moment, which is why the case has its own treatment in is my real IP address still showing.
Detecting a DNS leak
You are looking at which resolvers answered on your behalf, not at whether resolution worked.
Any check that reports the resolvers observed at the far end will do. Interpretation is the part that needs care: a result naming your internet provider is a clear failure, one naming your VPN provider is a pass, and one naming a large public resolver is ambiguous until you work out whether you, your browser, or your router chose it.
Two false readings are common enough to plan around. An answer already cached on your device never reaches any resolver, so a result can reflect the state of things before you connected — clear the cache first. And a browser with its own encrypted DNS reports its own resolver regardless of system settings. The mechanism behind genuine failures, including why setting a resolver is not the same as enforcing one, is in what a DNS leak is.
Detecting an IPv6 leak
Establish whether your network has IPv6 at all, then establish whether the tunnel carries it.
If no IPv6 address is reported with the VPN off, there is nothing to leak today — though that changes the moment your provider enables it or you join a different network, so it is worth re-checking rather than concluding once.
If IPv6 is present, the acceptable outcomes with the tunnel up are an IPv6 address belonging to the provider, or no IPv6 result at all because the client blocked the family. The same IPv6 address you had before connecting is the leak. These addresses are usually per-device rather than per-household, so the exposure is more specific than an ordinary address leak; why IPv6 is the leak people forget covers what the client can do about it.
Detecting a WebRTC leak
This one is browser-specific, so it must be tested in each browser you actually use.
The value at risk is not your exit address but the addresses on your own interfaces, which the browser can enumerate and offer to a page in order to set up direct connections. Depending on your setup that includes your private LAN address.
Because the mechanism lives above the network layer, the result can differ between two browsers on one machine while every routing check passes. Browsers have narrowed what they expose and the details keep shifting, which is why testing beats assuming — the current shape of the problem is in what WebRTC reveals about your local address.
Why a clean result is weaker evidence than it feels
Each check is one sample, of one application, at one moment, for one address family.
A test page tells you about the browser it ran in. It says nothing about a mail client, a messaging app with its own networking, or a background updater. And a result gathered shortly after connecting says nothing about what happens when the connection drops an hour later — traffic reverting to the open path on drop is the leak that exposes the most.
Repeat the checks after anything that changes the connection’s shape, and provoke a disconnection deliberately at least once per device rather than discovering the answer by accident.
Reading the failure correctly
Three causes look identical in a test result and need different responses.
Configuration. A setting is not what you thought — the client is set to leave system DNS alone, IPv6 protection is off, split tunnelling includes something you forgot. Fixable in the app.
Enforcement. The setting is right and the operating system is querying several resolvers or falling back to another interface anyway. This needs firewall-level blocking of the alternatives, which is what the “leak protection” toggles actually do, rather than a corrected setting.
Design. The client has no relevant setting and leaks regardless. That is a gap in the product, not a mistake you made, and a fair reason to use something else.
Before concluding any of the three, confirm the tunnel is carrying default traffic at all. A tunnel that is up but unrouted gives a perfect impression of a total leak while nothing has leaked — it was simply never in use.
What does not count as a leak
Several alarming-looking results are the system working correctly.
Your private LAN address appearing in your own local settings is normal and unavoidable. A site knowing your approximate region from a language setting, a time zone, or an account you are signed into is not an address leak. A service correctly identifying that you are using a VPN is not a leak either — the exit address’s ownership records say so plainly, and no configuration hides that.
The line worth holding is narrow: a leak is a case where something that should have travelled inside the tunnel did not.