WebRTC leak test

What WebRTC hands out

WebRTC is the technology behind voice and video calls that run straight in the browser, with nothing installed. For two machines to talk directly, each has to work out which addresses it can be reached on. That discovery is called gathering ICE candidates, and it is what the table above is showing.

Here is the part that matters: that discovery does not travel over the browser's HTTP connection. It uses UDP, talks straight to the network, and can be started by any page with a handful of JavaScript lines — no permission, no prompt, and no request for camera or microphone access.

Why it breaks proxies and VPNs

Most proxies configured inside a browser cover HTTP and HTTPS only. WebRTC's UDP traffic leaves through a different door: the network interface, directly. The result is that the site sees two addresses — the proxy exit on the normal connection, and your real address, handed over by WebRTC. Nothing has to be broken; the two just get compared.

A system-level VPN usually fares better than a browser proxy, because it captures all machine traffic including UDP. Test it anyway: partial configurations and leaks through a secondary interface are common. The difference between the approaches is covered in anti-detect vs VPN vs private browsing.

How to read the candidate types

• host — an address on the machine itself. Modern browsers usually replace it with a randomly generated name ending in .local (mDNS). That is protection, not a leak.
• srflx — the address as an outside server sees you. This is where the public IP appears, which is why it only shows up when a STUN server is involved.
• relay — an address on an intermediary TURN server. Rare in ordinary browsing.
• prflx — discovered midway through negotiation between the two peers.

If you only see .local names, your browser is doing the right thing: it hides the internal network address behind a random identifier that changes per origin. If you see addresses like 192.168.x.x or 10.x.x.x in plain text, mDNS protection is off and your local network layout is exposed.

How to treat the leak

There are five possible treatments, and they are not interchangeable:

• Block — no candidates are gathered at all. It removes the leak, but it also breaks every voice and video call, and a total absence of WebRTC in a browser claiming to be Chrome is an anomaly in its own right.
• Fake — the browser hands out a synthetic address consistent with the proxy. Functionality survives and no mismatch appears, as long as the fake address matches the exit.
• Pass through — only correct when the proxy genuinely carries UDP.
• Forward — routes WebRTC traffic through the same path as the browsing.
• Disable UDP — forces WebRTC onto TCP, which does go through the proxy.

Extensions that promise to "disable WebRTC" normally land on the first option, and rarely mention the side effect. Consistency between the faked address and the exit address is the only path that passes both tests at once: it does not leak and it does not look blocked.

For the full picture, including what to do once a leak has already happened, see WebRTC leaks end to end and how to test whether your browser is leaking.