WebRTC Leak Test - Detect Real IP Behind VPN

Most WebRTC leak tests return a list of addresses and no explanation. People read the first line, see something that is not their VPN address, and either panic or ignore it. This page explains what the test is actually collecting, why several addresses appear, and which combinations are real leaks.

For what WebRTC is and how to disable it per browser, see the WebRTC leak overview. What follows is about the measurement.

What the test actually does

The page creates an RTCPeerConnection and asks the browser to gather ICE candidates. To do that, the browser contacts a STUN server, which replies with the public address it observed. Each candidate carries a type:

• host — a local address on one of your interfaces.
• srflx — the public address a STUN server saw, which is what matters for a leak.
• relay — an address allocated by a TURN server. This is a relay, not your address, and it is normal when a VPN or privacy tool provides TURN.

Only srflx and unmasked host candidates tell you anything about exposure. A result full of relay candidates means the session is being routed through someone else's server, which is the opposite of a leak.

Why the list has several entries

A machine with Ethernet, Wi-Fi, a VPN adapter, IPv4 and IPv6 has several paths, and each can produce candidates. Seeing four addresses does not mean four leaks. Read them by family and by interface:

Address shown	Type	What it means
The VPN provider's IP	srflx	Tunnel is carrying the media stack. Correct.
Your ISP's public IP	srflx	The real leak. The media stack bypassed the tunnel.
192.168.x.x, 10.x.x.x, 172.16-31.x.x	host	LAN structure exposed. Not your public identity, but still a fingerprinting signal.
An IPv6 address beginning with 2xxx or 3xxx	srflx or host	Most common remaining leak: an IPv6 path outside an IPv4-only tunnel.
A random name ending in .local	host, obfuscated	mDNS protection is working. This is the modern default, not a leak.
An address belonging to a TURN service	relay	Relayed on purpose. Not exposure.

Four results that look like leaks but are not

• A .local hostname instead of an address. Browsers replace host candidates with random mDNS names unless the page holds a media permission. This hides LAN structure from arbitrary pages. It is the desired state.
• A private address only, with no public one. Candidate gathering partially succeeded but STUN did not respond. Exposure is limited to your subnet range.
• Several addresses, all from the same provider. Multiple exits or a dual-stack allocation. Leaks are defined by which network sent the request, not by how many addresses come back.
• No addresses at all. WebRTC is disabled, blocked by an extension, or restricted by policy. That is not a leak, though it does break browser calling.

Testing properly

1. Disable extensions that touch WebRTC, or test in a clean profile. Otherwise you are measuring the extension, not the browser.
2. Test once with the VPN off, then on. The comparison is the point. A single result tells you nothing about whether the tunnel is carrying the stack.
3. Provoke the second interface. Turn Wi-Fi off and on, or switch from Wi-Fi to a hotspot, then test again. Many WebRTC leaks appear only after a network change.
4. Repeat in a second browser. Different browsers gather differently — Safari restricts far more than Chrome by default. If only one browser leaks, the fix is browser-specific.

Fixing what the test found

The order matters, because a partial fix looks like a complete one:

1. Turn off IPv6 on the adapter when the provider does not tunnel it. Most residual leaks are this, and no browser setting fixes it.
2. Disable WebRTC if you do not use browser calling. Firefox exposes a switch; Chromium-based browsers need policy or an extension.
3. Use a client that tunnels UDP — candidate gathering is UDP, and a TCP-only tunnel does not cover it.
4. Re-test after every VPN client update. Updates commonly reset interface handling without saying so.

FAQ

Does a WebRTC leak expose my real IP or just my LAN?

Either, depending on which candidate escaped. A srflx candidate carrying your ISP address is a real IP leak; a host candidate is a LAN leak.

Is it a leak if the address matches my VPN?

No. That is the stack working as intended.

Why does the test show nothing on mobile?

Mobile browsers restrict candidate gathering more aggressively, and some networks block STUN entirely. An empty result usually means "could not gather", not "nothing exposed".

Can I pass the test and still leak?

Yes, if the leak only occurs on an interface that was not active during the test. That is why provoking a network change matters more than repeating the same test five times.

Does the test use my bandwidth?

Negligibly. It exchanges a handful of small UDP packets with a STUN server; no media is transmitted.