WebRTC Leak Test

The earlier version of this page gathered candidates, printed them, and left the judgement to you. That looks like a test and is not one. A leak is by definition a comparison: an address WebRTC hands out that differs from the address the site already has. Print one column and there is nothing to compare it against.

So the tool now fetches the address this site sees your HTTP request arriving from, and measures every public candidate against it. One public candidate matching that address is not a leak — it is WebRTC telling a site something it knew before you pressed the button. Two different public addresses is the finding, because it means one path is going around whatever the other is going through, and the usual culprit is a VPN that routes TCP but not UDP.

The reference address comes from this site’s own server rather than a third-party echo API, deliberately. A third party can sit on a different network path, and then a mismatch tells you about that path rather than about your browser.

The comparison is made within an address family, which matters more than it sounds. A dual-stack connection genuinely has one public IPv4 address and one public IPv6 address, and treating that pair as a contradiction would flag half the internet as leaking. So an IPv4 candidate is checked against an IPv4 reference, and a second family is reported separately as something to interpret rather than as a confirmed bypass — normal on plain dual-stack, and a real problem if you are on a VPN that only tunnels one of the two.

Candidate gathering needs a STUN server to answer. Ask it “what address did my packet come from?” and the reply becomes the server-reflexive candidate. If a firewall drops the outbound UDP, or an extension has switched WebRTC off, no reply arrives and no server-reflexive candidate exists.

At that point a tool that reports “no leak detected” is misleading you by omission. Nothing was observed, so nothing can be concluded, and the two states are not remotely the same: one means WebRTC disclosed nothing extra, the other means the measurement failed. The old version of this page printed “No candidates were exposed” in exactly that situation, which reads as reassurance.

This version calls it Test could not complete and says which part failed. On a corporate network that blocks outbound UDP you should expect to see it — and the honest conclusion is that you learned nothing about your browser, only about your firewall.

Run this in Chrome or Safari and your host candidate almost certainly reads something like af9324f2-a53e-4d01-b933-46f5cf0bfaeb.local rather than a 192.168 address. People report that as a leak. It is the opposite.

The mechanism comes from Using Multicast DNS to protect privacy when exposing ICE candidates, and one detail is worth knowing before you cite it: that document is an expired Internet-Draft (draft-ietf-mmusic-mdns-ice-candidates-03, last revised December 2021), not an RFC. It never completed standardisation, yet Chromium and Safari ship it — so the behaviour you see here is browser policy rather than a standards guarantee.

What it specifies is exact. The name “MUST consist of a version 4 UUID as defined in [RFC4122], followed by ‘.local’”, one distinct name per address, and it goes in the candidate’s connection-address field in place of the IP. The remote peer resolves it over multicast DNS on the local network and swaps the real address back in. The page never sees it. The draft also caps reuse — names “SHOULD be scoped by the web application origin” and last only the page’s lifetime, because a persistent name “would provide applications an even more reliable tracking mechanism than the private IP addresses” it exists to hide.

Two consequences follow. A raw private address in the output means your browser is not applying this protection, which is a real finding and why the tool flags it in red. And if resolution fails the candidate is simply dropped — the draft requires that failure stay invisible to the page, with statistics that “SHOULD NOT leak whether the mDNS resolution succeeds or fails,” so a call can quietly fall back to relaying with no error you can see.

A public-address mismatch is nearly always a routing problem rather than a browser one. WebRTC media travels over UDP; your page loads over TCP. A VPN client that captures TCP but leaks UDP produces exactly two different public addresses, and the fix belongs in the VPN rather than the browser — look for a kill switch, or an option covering all protocols.

Order of things to try, cheapest first: re-run in a private window with extensions off to establish whether an extension is involved; re-run on a different network to separate the VPN from the local firewall; check whether your VPN has an IPv6 setting, since an IPv6 candidate escaping an IPv4-only tunnel is a common cause. Disabling WebRTC outright is the last resort, and it breaks video calling in that browser.

Note that disabling WebRTC is itself detectable. RFC 8828 tells applications to infer a restrictive configuration by checking whether host candidates are absent, so a browser with WebRTC switched off is a smaller crowd to hide in, not a larger one. Whether that trade is worth making depends on what you are protecting against.

It checks one disclosure path. DNS queries, IPv6 routing, ordinary HTTP requests and your operating system’s routing table are separate, and a VPN can be watertight on WebRTC while leaking on any of them. A clean result here is one signal, not a verdict on your setup.

It cannot see peer-reflexive candidates, because those are learned during connectivity checks against a real peer and this test has no peer. It cannot see relay candidates, because no TURN server is configured. Both absences are structural rather than a sign of protection.

Results depend on the exact conditions you test under. Same browser, same profile, same VPN state, same network — change any of them and you have measured something else. A test run in a private window with extensions disabled is not a test of your normal browsing.

The candidates never leave your browser. Gathering happens locally, the STUN servers see only what any WebRTC connection would show them, and nothing is stored between visits. The one request this page makes to our server asks for the address that request arrived from, which is the same address every HTTP request to any site already carries.