DNS and WebRTC Leaks: How a Working VPN Still Gives You Away

What a DNS leak is

Before your computer can reach a site it has to turn the name into an address, and it asks a DNS resolver to do that. By default the resolver is your internet provider's.

When the VPN connects it should also take over DNS, so that lookups travel inside the tunnel and are answered by the VPN's own resolver. A DNS leak is what happens when they do not — the encrypted tunnel carries your traffic, while the *questions* about where you are going go to your provider in the clear.

The consequence is precise and worth stating plainly: your provider cannot read the pages, but it has a timestamped list of every site you asked about. For most people that is the exact record they installed a VPN to prevent.

It happens for ordinary reasons. The operating system falls back to a hard-coded resolver when the VPN's is slow. A router advertises its own DNS and the machine prefers it. A browser runs DNS-over-HTTPS to a third party independently of the system. On Windows, more than one adapter is active and the system queries all of them and takes the first answer — which is a design choice for speed, not a bug.

What a WebRTC leak is, and why it is worse

WebRTC is the browser technology behind video calls and peer-to-peer connections in the page. To connect two people directly it has to discover the addresses each machine can be reached on — including private ones on your local network and your real public address.

It does this through a STUN server, and here is the part that catches people: that request can come from the browser itself, not from the operating system's normal networking path. Your VPN can be carrying every other byte on the machine while WebRTC asks the question separately and gets the true answer.

Any page you visit can run this in JavaScript, silently, with no permission prompt and no camera or microphone involved. It takes milliseconds.

So a WebRTC leak does not merely reveal which sites you asked about. It hands the site you are on your actual IP address, while your VPN is connected and working.

Why the tunnel does not prevent either one

The mental model that causes the confusion is that a VPN is a wall around your computer. It is not. It is a *route* — a path that traffic takes if it is directed onto it.

DNS leaks happen when the resolver is chosen outside that route. WebRTC leaks happen when the browser asks a question the route was never given.

Everything that follows comes from that single fact: a VPN protects traffic that goes through it, and nothing else. Both leak types are cases of traffic going somewhere else entirely, which is why neither is fixed by better encryption or a faster server.

The related failure: IPv6

A third case belongs here because it produces the same result by the same logic. Many VPNs were built for IPv4. If your connection also has IPv6 and the VPN does not carry it, IPv6 traffic goes straight out unprotected.

The symptom is confusing: sites that only support IPv4 appear correctly protected, and the ones that support IPv6 quietly see the real you. A leak test that only checks IPv4 will report everything as fine.

A VPN that handles this either routes IPv6 through the tunnel or disables it entirely while connected. Both are acceptable. Silently ignoring it is not.

How to actually check

Testing has to be done in the right order or the result is meaningless.

• Note your real public address with the VPN off, so you know what a leak looks like.
• Connect, and confirm the reported address has changed.
• Run a DNS leak test and read the *resolver* names, not just the IP. Seeing your provider's name there is the leak.
• Run a WebRTC test in each browser separately. This is not a system-wide setting and one browser being clean says nothing about another.
• Check whether IPv6 is being reported at all.

Our VPN IP leak test guide walks through the checks, and how to check your VPN is working covers what a pass actually proves.

Repeat after anything changes: an operating system update, a new browser, a different network. A leak-free result on your home connection does not transfer to a hotel.

What fixes them

For DNS: use a provider that runs its own resolvers and forces all queries through the tunnel, and turn off any browser-level DNS-over-HTTPS that bypasses the system. Two resolvers competing is the common cause.

For WebRTC: the browser is where this is solved. Disable WebRTC where you do not need it, or use an extension that restricts it to the tunnel's address. No VPN can fix this from outside the browser, which is why reputable providers ship a browser extension specifically for it.

For IPv6: confirm your provider either tunnels it or disables it. If the documentation does not say, treat that as an answer.

And underneath all three, a kill switch is what protects you at the moment the tunnel drops — the window in which everything leaks, including things that were never leaking before.

The summary

A leak is not a failure of encryption. It is traffic taking a road the VPN was never put on.

That is why a green connection light is not evidence of anything, and why the only way to know is to test — separately for DNS, for WebRTC in each browser, and for IPv6.

Frequently Asked Questions