WebRTC leak test

What WebRTC actually is

WebRTC — Web Real-Time Communication — is the standard the major browsers ship for peer-to-peer video, voice, and data without plugins. It is the engine behind in-browser Google Meet, Zoom Web, Jitsi, Discord, Whereby, every telehealth widget, and most modern customer-support video chats. Whenever you click "Join from browser" instead of "Open in the app," WebRTC is doing the heavy lifting.

For two browsers to talk directly, they need to find a network path between each other. That path is rarely obvious: most users sit behind NAT, behind firewalls, sometimes behind carrier-grade NAT, and increasingly on dual-stack IPv4+IPv6 connections. WebRTC solves this with a protocol called ICE (Interactive Connectivity Establishment) which gathers every plausible address the peer might be reachable on and offers them all as "candidates."

The candidate gathering step is where things leak

When you initiate a WebRTC session, the browser asks the operating system for every network interface that's up. It then categorizes the addresses it sees into three buckets:

• Host candidates — the literal addresses of your network interfaces. Your Wi-Fi's 192.168.1.42, your Ethernet, your VPN's TUN interface, your IPv6 SLAAC address. Anything the OS thinks is "up."
• Server-reflexive candidates — what a STUN server on the public internet sees as your source IP when the browser pings it. This is your real outside-the-router public IP (or your VPN's exit, depending on how the VPN routes UDP).
• Relay candidates — if a TURN server is configured, the address it allocates for relaying the call. Usually only present in enterprise setups.

All three categories get bundled into an SDP offer and handed to the other peer. The problem is that "the other peer" doesn't have to be a real call. Any JavaScript on a page can create an RTCPeerConnection, set its own dummy STUN servers, listen for the candidate event, and read the strings — no microphone permission, no camera permission, no user prompt. That's the leak.

Why a VPN doesn't always save you

A consumer VPN client routes IP traffic over a tunnel: packets leave your machine, get encrypted, and emerge from the VPN provider's exit node. Sites you visit normally see the exit's address. WebRTC subverts this in two ways:

First, host candidates come from the OS interface table, not from any actual network probe. If your VPN added a virtual interface on top of the real one (which is the normal architecture for OpenVPN, WireGuard, and most commercial clients), the browser sees both. The real interface's address is still in the list. With a split-tunnel VPN this is even worse — entire ranges of your real connection stay visible.

Second, STUN happens over UDP, which some VPNs handle differently from TCP. A poorly-configured VPN may let UDP escape outside the tunnel, in which case the STUN response reveals your real public IP — your server-reflexive candidate becomes a smoking gun. This was the original 2015 WebRTC leak everyone talks about, and while modern reputable VPNs handle it, free and bargain VPNs frequently do not.

mDNS: the partial fix browsers already shipped

Around 2019, Chromium added an mDNS-based mitigation: instead of putting raw private addresses in candidates, the browser generates a random <uuid>.local hostname and resolves it locally for the call. To an eavesdropper, the candidate is opaque — a hex string, not 192.168.1.42. Safari followed. Firefox supports it via media.peerconnection.ice.obfuscate_host_addresses.

mDNS protects host candidates only. Server-reflexive (public IP via STUN) and relay candidates are not obfuscated — they cannot be, because the call setup logic on the remote peer needs a real reachable address to dial back to. So mDNS plus a properly-routed VPN closes the common cases; an mDNS browser without a VPN still reveals your public IP.

How to lock it down per-browser

Chrome / Edge / Brave

Chromium ships the WebRTC IP handling policy as a managed setting. The most useful value is "Disable non-proxied UDP" — it forces WebRTC to use a configured proxy for ICE traffic, which means the STUN candidate goes through whatever proxy chain the browser uses for HTTP. In Brave, this is exposed directly under Settings → Privacy and security → WebRTC IP handling policy. In vanilla Chrome and Edge you can install the official "WebRTC Network Limiter" extension, or set the policy via group-policy if you manage the device.

Firefox

Open about:config and set media.peerconnection.ice.obfuscate_host_addresses to true (it already is on recent builds). If you do not need video chat at all, set media.peerconnection.enabled to false; that switches WebRTC off entirely. The downside is that Google Meet, Jitsi, etc. will stop loading until you flip it back.

Safari

Safari uses mDNS for host candidates by default and respects macOS's network and proxy settings. There is no in-UI toggle. If you need stronger isolation, use a VPN client that configures itself as a system-level network filter (the modern ones do this through Apple's NetworkExtension framework) rather than only as a routing change.

When you actually need to care

A WebRTC leak matters when your threat model demands that a specific website cannot learn a specific address you have. Common real-world scenarios:

• You are a journalist or researcher visiting a sensitive site from a country where the site's operator works with local authorities and you cannot afford your home IP to land in their logs.
• You are testing a competitor's geo-fenced product from a VPN exit and they fingerprint your real IP, marking your account.
• You are running an investigation and need every fetch from a target page to route through Tor or a research VPN — a WebRTC leak undoes all of it.

For everyday browsing, especially on home networks behind a NAT router, the leak is much less interesting — your LAN address is shared by every house on the block running the same default router, and your public IP is what every other site sees anyway.

How to read the probe results above

Each candidate line ends with a type: typ host (interface address), typ srflx (STUN-derived public), typ prflx (peer-reflexive, rare), or typ relay (TURN). If you are connected to a VPN and you see a srflx candidate that does not match your VPN exit's known IP — that is a leak. If you see host candidates that look like real IP addresses (rather than <uuid>.local hostnames), your browser does not have mDNS host obfuscation enabled, which is a smaller leak but still a fingerprintable signal.

FAQ

Will incognito mode stop the leak?

No. Private browsing affects cookies and history, not the OS-level network state the browser inspects to build ICE candidates.

Is this leak the same as a DNS leak?

No — though they often appear together. A DNS leak happens when DNS queries escape outside your VPN's tunnel, exposing which domains you visit to your ISP. A WebRTC leak exposes which IP address a site can attribute to you. They are independent failures.

Should I use a TURN relay?

For most users, no — TURN is for enterprise call infrastructure. The Cloudflare and Google public STUN servers are fine for ICE gathering; the leak is not "STUN found my address," the leak is "JavaScript on a page I did not consent to a call with was allowed to read the candidates list."

Can a site detect that I have WebRTC disabled?

Yes — the JavaScript constructor throws or returns nothing, which is itself a fingerprint. If you are trying to look like a normal browser, "WebRTC enabled but no public candidates revealed" is stealthier than "WebRTC missing."

Keep going

The privacy story doesn't end at WebRTC. Three more tools on IPFerret are worth a minute:

• DNS leak test — checks whether your DNS queries are actually going through your VPN.
• Request headers — shows every header your browser advertises to a server, including Accept-Language and Sec-CH-UA hints used for fingerprinting.
• User-agent inspector — decodes your User-Agent string into browser, OS, and device, including spoof detection.