WebRTC leak test

Why a browser can know more than one address

Loading a web page is a simple exchange. Your browser asks, a server answers, and the server learns one thing about your network, which is the address the request came from. A video call works differently. Two browsers try to send audio and video straight to each other, and for that each one has to tell the other where it can be reached.

WebRTC is the browser feature that takes care of this. Before a call, it collects every address that might work, a step called ICE gathering. It lists the addresses of the network interfaces on your device, then asks a public helper called a STUN server one question: “what address do you see me coming from?” Each answer becomes a “candidate”.

Any web page can start this gathering with a few lines of JavaScript. It doesn’t need a call or a permission prompt, and nothing shows on screen. If the STUN question travels outside your VPN tunnel, or over an interface the VPN doesn’t cover, the candidate list contains the address your provider gave you. That’s what a WebRTC leak is.

What the test does

1. When the page loads, our server notes the address your request came from and names the network that owns it. That’s box 01.
2. Your browser opens a WebRTC connection that goes nowhere, pointed at two STUN servers, one run by Google and one by Cloudflare, and collects candidates for up to seven seconds.
3. The candidates get sorted. Private ranges (10.x, 172.16 to 172.31, 192.168.x), carrier-shared addresses (100.64 to 100.127), link-local addresses and .local names are set aside as local. The rest are public.
4. Up to six public addresses go to our server, which sends back the network each one belongs to.
5. Each public address is compared with box 01 and gets a label.

Reading the labels

Under the list, the page says whether local addresses are visible. Current browsers replace them with a random name ending in .local, which tells a website nothing. A plain 192.168.x.x address doesn’t lead back to you either, but it’s one more detail a tracker can use to tell devices apart.

“No public address” and “WebRTC is turned off” both mean this door is shut. Either the browser refused to gather candidates or no STUN answer came back.

Closing the leak

In the VPN application

Look for “WebRTC leak protection”, “IPv6 leak protection” and “kill switch”, and turn on all three. If the provider doesn’t support IPv6, disable IPv6 on the network adapter while you’re connected. A VPN that only exists as a browser extension protects page traffic and may leave WebRTC alone, so go for the full application.

Firefox

Open about:config and set media.peerconnection.ice.default_address_only to true. WebRTC then sticks to the default route, which is the tunnel. Setting media.peerconnection.enabled to false removes WebRTC entirely.

Chrome and Edge

There’s no built-in switch. Google publishes an extension, WebRTC Network Limiter, with the option “Use my default public interface only”. The uBlock Origin extension has a similar setting, “Prevent WebRTC from leaking local IP addresses”.

Brave

Settings, Privacy and security, “WebRTC IP handling policy”: choose “Disable non-proxied UDP”.

After each change, reload this page with the VPN connected. You’re aiming for every public line marked “Same” or “Same provider”, or no public address at all.