WebRTC leak test

How the leak works

WebRTC is the API behind video and voice calls that run in a browser tab with no plugin. To connect two people directly it has to solve a hard problem: work out how each machine can be reached from the other, through whatever routers and firewalls are in the way. It solves it by collecting every possible address, called ICE candidates, including the addresses on your local network and the public address a STUN server reports seeing.

The problem is that any script on any page can start that collection and read the answers, with no permission prompt, no camera indicator and nothing visible on screen. The addresses come from the operating system's network interfaces rather than from the connection the page arrived over, so a VPN that reroutes normal traffic can be sidestepped entirely.

The issue was first published in 2015 and has been narrowed since. Chromium and Firefox now replace local network addresses with random .local mDNS hostnames by default, which closed the local-address half of it. The public-address half depends on how your VPN is set up, which is what this test measures.

Reading your result

• A public address that is not your VPN exit address. This is the real finding. Your actual address is being handed to any page that asks, and the VPN is not covering the browser.
• A public address that matches your exit address. Not a leak. WebRTC is reporting the VPN server, which is exactly what should happen.
• An address like 192.168.1.42 or 10.0.0.5. Minor. These exist on millions of home networks at once and cannot be routed to from outside, so they identify nobody by themselves. They add one weak signal to a browser fingerprint.
• Hostnames ending in .local.Good. That is the browser's mDNS protection replacing your local address with a random name that is meaningless outside your own network.
• Nothing at all. Either WebRTC is blocked, or an extension is preventing candidate gathering. Browser-based calls will not work, and nothing is exposed.

How to stop WebRTC leaking

1. Firefox. Open about:config, accept the warning, search for media.peerconnection.enabled and set it to false. This is the only built-in off switch any major browser ships.
2. Chrome, Edge, Opera and Brave.There is no setting. Install uBlock Origin and turn on "Prevent WebRTC from leaking local IP addresses" in its settings, or use a VPN extension that blocks the API.
3. Use a VPN browser extension alongside the app. An extension sits inside the browser and can block the API outright, which the system-level tunnel cannot do.
4. Make sure the tunnel carries every interface. Many WebRTC leaks are really split-tunnel configurations where a physical adapter is still reachable and therefore still describable.

Disabling WebRTC breaks video and voice calls in the browser. If you use those, the honest trade is to leave it on and confirm through this test that the only address it reports is your VPN exit.

About the STUN servers

This test contacts a public STUN server because that is the mechanism under test. STUN exists for exactly one purpose: to tell a client which public address it appears to be coming from. It is what a tracking script would call, and the server learns nothing that every website you open does not already see.

Test the other two paths as well

WebRTC is one of three ways a VPN commonly fails to cover something. The other two are DNS and plain address exposure, and both have their own page: the DNS leak test and the IP address check. A configuration is only sound when all three agree.