A leak around the proxy
WebRTC asks a STUN server “what address do you see me on?” — and it does that outside the HTTP proxy this page is loaded through. That is how a proxied browser can still hand a site your real address.
The test contacts a public STUN server from your browser — the same thing any site with video calls does. Press when you are ready.
The test runs entirely in your browser. It is your browser that talks to the STUN server, not our server.
WebRTC is the browser's real-time media stack, and it was designed to connect two machines directly. To do that it has to discover the addresses it can be reached on, so it asks a STUN server on the internet: "what address do you see me at?" That exchange happens inside the browser, outside the HTTP traffic your proxy settings apply to — which is how a page can learn your real address while every request it makes goes through the proxy.
The candidates the test shows are of three kinds. Host candidates are local addresses (192.168.x.x, 10.x.x.x or an mDNS name ending in .local) — they identify your machine on its own network and are not a public leak. Server-reflexive candidates are the public address a STUN server saw, and this is the one that matters: if it is not your proxy's exit address, it is the leak. Relay candidates come from a TURN server and reveal nothing about you.
This is the only tool on the site whose check leaves the network — and it is your browser that leaves, not our server. It opens a peer connection against Google's and Cloudflare's public STUN servers and collects whatever candidates come back. Because it makes your browser talk to a third party, it runs only when you press the button, never on page load.
Candidate gathering is closed both by the browser's end-of-candidates event and by a four-second timer, because a browser that never sends the empty final candidate would otherwise leave the test spinning forever.
Firefox: open about:config and set media.peerconnection.enabled to false. This disables WebRTC entirely, including calls that use it.
Chrome and Edge: there is no built-in switch. Use an extension that restricts WebRTC to the proxied interface rather than one that claims to disable it.
A VPN with a kill switch routes WebRTC too, because the tunnel is below the browser rather than inside it — this is the structural reason a VPN leaks less here than a browser proxy.
Seeing only .local names is the expected modern behaviour: browsers hide local addresses behind mDNS by default.
A clean WebRTC result is one leak closed, not anonymity achieved. Check what your headers say on the HTTP headers page and what survives on the fingerprint test.
It is your browser revealing your real IP address through WebRTC’s address-discovery exchange while your HTTP traffic goes through a proxy. The page reads the address from the browser API, never having seen it in a request.
Usually, because a VPN moves the whole system’s traffic including WebRTC’s, rather than only the browser’s HTTP requests. Test it rather than assume it: split-tunnel configurations and IPv6 handled outside the tunnel both reintroduce the leak.
No. Those are local network addresses, meaningless outside your router, and a site cannot reach you at them. The address to look at is the public one discovered via STUN.
Only if you do not need it. Video calls, screen sharing and some collaboration tools stop working without it. Restricting WebRTC to the proxied interface keeps the functionality and closes the leak.
Because it makes your browser contact third-party STUN servers. Doing that without asking would be exactly the sort of silent outbound connection the tool exists to expose.
It means your browser produced no candidates: WebRTC is disabled, blocked by an extension, or unsupported. That is a safe outcome for the leak, and it also means anything on the web that needs WebRTC will not work.