WebRTC Leak: Why Your Real IP Escapes a Working VPN

Your VPN app shows connected. The tunnel is genuinely up. And a web page just read your real IP address anyway.

That is a WebRTC leak, and the reason it surprises people is that nothing is broken.

Why the feature exists

WebRTC is what makes voice and video calls work in a browser without installing anything. To connect two people as directly as possible, it has to find out which addresses your machine can be reached on: the address on your local network, and usually the public one too.

That discovery happens below the browser's ordinary request handling, and the results are available to JavaScript on the page. A page can therefore ask, and get an answer, without your knowing.

The handle is closed and it is still dripping. That is the whole shape of the problem: the thing you turned off is off, and the water is arriving by a path that does not go through it.

Why the VPN cannot see it

The VPN operates at the network layer. The leak happens above it, inside the browser.

Your tunnel is faithfully carrying everything handed to it. WebRTC simply learned an address by another route and handed it to the page directly. The VPN was never asked and has nothing to report.

This is why the green icon is telling the truth and is still not an answer. It describes the tunnel. It cannot describe what the browser volunteered.

How to test it properly

Open a WebRTC test page with the VPN connected, and compare what it reports against the address your VPN app claims to give you. If your real one appears, you have a leak.

Three conditions that most instructions leave out:

• Test in every browser you use. The behaviour differs between them, and between versions of the same one.
• Test again after browser updates. This has regressed and been re-fixed repeatedly over the years, in both directions.
• Use two different test pages. A single site's implementation can be incomplete, and one result is not a measurement.

The fix, and its cost

Disabling WebRTC entirely works and breaks things. Video conferencing, browser voice chat and some screen sharing all depend on it. If you never use those, this is a clean answer. If you do, you will turn it back on and forget.

The better options, in order:

1. A VPN client that handles this at the system level, so the addresses WebRTC can discover are the tunnel's ones. This is a genuine differentiator between providers and worth checking before subscribing rather than after.
2. A browser setting that restricts which addresses WebRTC may expose, rather than switching the feature off. Available in most browsers, sometimes only behind a configuration page.
3. An extension, last, because it operates inside the browser and adds to your fingerprint.

What this does not fix

A WebRTC leak is one specific hole. Closing it does not make you anonymous. Your login still identifies you, your cookies still identify you, and your browser fingerprint still identifies you whether or not this particular address escaped.

And the honest inverse, which matters if you are worrying about the wrong thing: if you are not logged in anywhere and your threat model is the cafe wifi, a WebRTC leak may cost you nothing at all. The address it reveals is the one your cafe already knows.

Test it, close it if it is open, and then go back to the two things that actually decide the outcome: what you are signed into, and which browser profile you did it from.