What is a WebRTC leak, and how do you test for one?

WebRTC is the browser technology behind video calls and peer-to-peer connections. To connect two people directly, it collects ICE candidates: the addresses a peer could use to reach you. Any web page can ask for these with a few lines of JavaScript, no permission prompt needed. A WebRTC leak is when those candidates reveal an address you meant to hide, usually your real public IP while you are using a VPN or proxy.

There are two kinds of address involved. Host candidates describe your own network interfaces; historically that meant your local address, such as 192.168.1.20. Server-reflexive candidates come from asking a public STUN server what address it sees; that is your public IP. The leak happens because WebRTC sends that STUN request over UDP, directly, even when your web traffic goes through a proxy. The page then sees one address in the connection and another over WebRTC.

What a normal result looks like today. Chrome, Firefox and Safari no longer publish your local address by default. They replace it with a random name ending in .local (mDNS), unique per site. So a host candidate like c6d5cfe9-….local is your browser protecting you, not leaking. Some test pages still count it as a leak; CreepJS is one of them. A public IP in the server-reflexive candidate is only a leak if it differs from the IP you are browsing from.

How to test. Connect to your VPN or proxy, then open a WebRTC test such as the WebRTC page on BrowserLeaks, the WebRTC section of BrowserScan, or the Clearcote audit, which runs seven WebRTC checks and explains each one. Compare the public address WebRTC shows with the IP the site shows for your connection. Same address: no leak. Your real home address: a leak.

One common false alarm. On a dual-stack home connection, a page may load over IPv6 while WebRTC reports your IPv4 address. Both are genuinely yours and there is no VPN to bypass, but some tests read the difference as a hidden IP. In our own test, BrowserScan took 10% off a genuine Chrome for exactly this, on a home line with no proxy at all.

How to fix a real leak. Use a VPN app with WebRTC leak protection turned on, or restrict WebRTC in the browser. In Brave, set Settings → Privacy and security → WebRTC IP handling policy to "Disable non-proxied UDP". In Chrome, there's no built-in setting: install Google's own WebRTC Network Limiter extension, or, on managed machines, set the WebRtcIPHandling policy. In Firefox, setting media.peerconnection.enabled to false in about:config turns WebRTC off entirely, which also breaks video calls in the browser.

Disabling WebRTC completely closes the leak, but it is visible: a site can tell a browser that offers no candidates at all from one that offers a protected .local address, and the first is much rarer. For automation behind a proxy, the cleaner answer is to make WebRTC report the proxy's address. In Clearcote's latest build, --webrtc-ip does exactly that: the engine presents the given address as the public candidate and sends no real STUN request, so the real IP never leaves the machine and the two addresses agree. See the fingerprint flags.