WebRTC Leak Test

WebRTC is what lets browsers make video and voice calls without a plugin. To connect two people directly it has to work out which addresses each side can be reached on, and it does this eagerly, the moment a page asks. The side effect is that any website can trigger the same discovery and read the addresses it finds, including, in the worst case, the real public IP a VPN is supposed to be hiding.

This test performs that discovery in your browser and shows you what came back. Nothing is sent anywhere except the single public-IP lookup used for the comparison line.

To establish a direct connection, WebRTC gathers what are called ICE candidates: a list of every address a peer might use to reach you. Host candidates come from your own machine. Server-reflexive candidates come from a STUN server, which reports back the public address your traffic appears to come from on the internet. If neither side can connect directly, a relay candidate from a TURN server is added as a fallback.

The problem is that this happens in the background and needs no permission. A script can create a peer connection it never intends to use, harvest the candidates, and read addresses straight out of them. The key detail is that WebRTC runs over UDP. A VPN that only tunnels TCP, or that has split tunnelling switched on, can send the STUN request over your ordinary connection, which is how the real address escapes.

Older descriptions of this leak talk about pages learning your 192.168.1.5. That is largely history. Browsers now replace the local address in a host candidate with a random hostname ending in .local, a technique known as mDNS obfuscation, so the candidate a page sees looks like an unguessable name rather than a real private address. Chrome turned this on by default in 2019, and Firefox before it.

This is the modern default rather than a sign that anything is wrong, and it means a scan like this one often reports no local address at all. It does not close the leak on its own. The obfuscation covers local addresses only; the public address that a STUN server reports is still gathered, and that is the one that matters when you are behind a VPN. Treat a missing local address as normal and keep your attention on whether a public address appears.

The result groups any discovered addresses into two kinds, and that distinction is the whole point.

• Local / private. Addresses such as 192.168.1.5 or 10.0.0.4 exist only inside your own network. They cannot be used to locate you across the internet, so they are marked low-risk, and on current browsers they rarely appear at all.
• Public. A routable address is the one that identifies your connection to the world. Seeing one here, especially while a VPN is on, means the discovery step reached the internet outside your tunnel.

The comparison line places the public IP from the ordinary lookup beside what WebRTC exposed, so you can see at a glance whether they match. If they match while a VPN is running, the tunnel is not covering WebRTC.

If a public address appeared and you did not expect it, here is how to close the gap.

• Use a leak-protection extension. Add-ons such as uBlock Origin can restrict WebRTC so it no longer reveals your real address, while leaving calls working.
• Enable your VPN’s WebRTC protection. Many VPN clients and browser extensions include a specific WebRTC-leak setting. Turn it on and check whether split tunnelling is sending UDP outside the tunnel.
• Disable WebRTC entirely. In Firefox you can set media.peerconnection.enabled to false in about:config. This is the strongest fix but breaks in-browser calls.
• Use a privacy browser. Brave and the Tor Browser handle WebRTC addresses far more cautiously by default.

A leak is only closed once you have watched it disappear. After changing an extension setting, a VPN option or a browser flag, fully restart the browser rather than just reloading the tab, because extensions and the WebRTC stack are set up when the browser process starts.

WebRTC is only one exit route, so check the others while you are here. A tunnel that covers WebRTC but leaks DNS leaves a different trail, and an overlooked IPv6 route can carry traffic your VPN is not handling at all. Run the DNS leak test and the IPv6 test alongside this one, and treat them as one check rather than three.

If you do not use a VPN or proxy, a WebRTC leak mostly exposes an address the internet can already see anyway, so the stakes are lower. The people who should care most are those relying on a VPN, a proxy or the Tor network to hide where they are. For them a single leaked public address undoes the protection they are paying for, and it does so silently, with no prompt and no visible sign.

Hiding your IP is only part of staying private. Your browser still looks the same to trackers regardless of your address. Combine this test with the VPN and proxy detection test and the fingerprint test for the full picture of what your connection and browser reveal.