liarjs.dev
Single test · WebRTC

WebRTC leak test

Your browser opens a WebRTC connection to a public STUN server, which reports back the address it saw. If that address is not the IP this page was loaded from, WebRTC is going around your VPN or proxy.

Running the test…
Connection IP
…
WebRTC public IP
…
Local address
…
ICE candidates
…

This page, unlike the main scan, contacts stun.l.google.com:19302 from your browser. That request is what a leak test is. Nothing is stored. Privacy

How to read the result

  • Same IP on both lines: WebRTC shows the address your traffic already comes from. Without a VPN or proxy that is normal and is not a leak.
  • Different IP of the same family (two IPv4 or two IPv6 addresses): WebRTC exposed an address your connection did not use. Behind a VPN or proxy this is the classic WebRTC leak, and usually it is your real one.
  • Different family (IPv4 on one line, IPv6 on the other): this page sees only one of your two addresses, so it cannot tell whether they belong to the same exit. Load the page over the other protocol to compare like with like.
  • No public IP: STUN got no answer over UDP, or the browser keeps WebRTC to the proxy path. Nothing leaked here.
  • WebRTC disabled or zero candidates: nothing can leak. Real Chrome always gathers at least one candidate, though, so a silent WebRTC is itself rare, and detectors do read it.

What a WebRTC leak is

WebRTC finds a path between two peers with ICE, which lists every address the browser might be reachable on before any call starts. One candidate type, srflx, is your public IP as a STUN server saw it. A proxy configured for page traffic does not cover the UDP sockets ICE opens itself, so unless the browser confines them, the STUN reply carries the real address.

Since Chrome 76 the local address in host candidates is hidden behind a random.local mDNS name, which is what the "Local address" line checks. mDNS does nothing for the public address. Blocking WebRTC outright is not the fix either: a site sees that too. The fix is a configuration where the exposed IP is the one your connection already uses.

The long version, with the candidate parsing code and the IP-handling policies: WebRTC IP leaks: ICE candidates, mDNS and the public-IP mismatch. For the clock-versus-IP check that catches the same proxies from another side, see timezone vs IP.

What this test does not do

It looks at one STUN server over UDP and at the single IP this connection arrived from. It does not test DNS leaks, and it does not tell you whether a site will block you: that depends on far more than one address. The full browser fingerprint test runs WebRTC alongside the rest of its roughly seventy checks.

Other tests