WebRTC Leak Test: Is Your Browser Giving Away Your Real IP?

What a WebRTC leak actually is

WebRTC is the part of your browser that makes video calls work without a plugin. For two people to talk directly, each browser has to find out how it can be reached — and that means collecting every address it might be reachable on: the one your router handed it, the one your ISP handed your router, and anything in between. Those addresses are called ICE candidates, and the browser gathers them before anyone has agreed to a call.

The problem is that gathering them does not require permission. A camera needs a prompt. A microphone needs a prompt. A list of your own IP addresses needs about three lines of JavaScript and no prompt at all, because from the browser's point of view nothing private is happening — it is just getting ready to make a connection.

That is fine until you are deliberately presenting a different address. If you have set a proxy in your browser, told it to route through an extension, or connected a VPN that only covers the browser, then the whole point is that sites see the proxy's address and not yours. WebRTC was never part of that arrangement. It asks the operating system what addresses are available, gets your real one, and offers it to any page that looks. The site then has two addresses for you: the one you are showing and the one you are hiding — which is worse than showing no proxy at all, because now the mismatch itself is the signal.

How this page tests for it, and what goes where

The test is a comparison, and both halves of it are visible above. The first half is the address this page was served to: that is what our server recorded when your browser asked for this URL, and it is what every ordinary site sees. The second half is whatever your browser volunteers when it starts gathering ICE candidates.

To gather a routable candidate the browser has to ask a STUN server "what address did my packet arrive from?", because nothing inside your network knows the answer. There is no WebRTC leak test without that question — a page that claims to test for leaks without contacting anything is testing nothing. This page asks Cloudflare's public STUN server, directly from your browser. The question and the answer do not pass through us, and the result is not stored anywhere: press the button, and the only thing that changes is the text on your screen.

Everything else happens locally. Your browser collects candidates, we sort them into routable and private, and compare the routable ones with the address at the top of the page. If they match, there is nothing hidden and nothing leaking. If a routable candidate differs from the address the page was served to, your browser is handing out something you are not showing, and we say which one.

The detail most leak tests get wrong

Chrome, Edge and Safari no longer offer your local network address as a plain 192.168.x.x. They replace it with a random name ending in .local, resolved over mDNS only by machines on your own network. This is a genuine privacy improvement, and it breaks any test that decides "no LAN address visible" means "nothing is leaking". The absence proves the browser is hiding it, which tells you nothing about the routable address — the one that actually identifies you. We report the two separately, so a hidden LAN address is reported as what it is rather than quietly counted as a pass.

Reading your result

Same address as the page. No leak. This is also what you see with no proxy at all, which is worth saying plainly: the test cannot tell you that you are protected, only that WebRTC is not contradicting you. If you are not routing traffic anywhere, a match is simply your own address, correctly reported twice.

A different routable address. This is the leak. Your proxy covers your page requests and not your WebRTC candidates. The most common cause is a proxy configured inside the browser, or an extension that sets one: both intercept HTTP, neither intercepts the UDP that WebRTC uses.

No routable address at all. Nothing to read, which is the cleanest result there is. Usually it means WebRTC is disabled, an extension is blocking the STUN request, or your network drops it. Some corporate networks produce this result by accident.

A visible private address. On its own this does not identify you — 10.0.0.4 describes several hundred million machines. It does tell a site how your network is arranged, and it is one more value in a fingerprint.

Stopping it

There is no browser setting that routes WebRTC through an HTTP proxy, so "set the proxy properly" is not the fix people expect it to be. What works:

• Turn WebRTC off. In Firefox, set media.peerconnection.enabled to false in about:config. Chrome has no equivalent switch and needs an extension. Video calls stop working in that browser — which is the trade.
• Route the whole device, not the browser. A system-level tunnel or a proxy applied at the OS or router carries WebRTC's UDP traffic along with everything else, so the candidates it gathers are the tunnel's addresses.
• Use a browser built for it. Anti-detect browsers bind WebRTC to the same address as the rest of the session on purpose; it is most of what you are paying for.
• Do not rely on an extension that only hides the result. Several extensions spoof the reported candidate rather than preventing it being gathered, and the mismatch between the spoofed value and the rest of your fingerprint is itself detectable.

Re-run this test after any change. The failure mode worth avoiding is believing the setting worked, and the whole test takes under a second.