WebRTC Leak Test

Check if WebRTC is exposing your real IP address behind VPN or proxy

HOW IT WORKS

WebRTC leak detection process

WebRTC API

Create peer connection

ICE CANDIDATES

Gather ICE candidates

IP COMPARISON

Compare with VPN IP

LEAK REPORT

Generate leak report

WebRTC Leaks Your Real IP. Browser Extensions Won't Save You.

In 2015 someone posted ten lines of JavaScript on TorrentFreak that read your real public IP straight through any VPN. The kicker: the browser was doing exactly what it was designed to do. WebRTC, the API behind video calls, Discord huddles, and Google Meet, was built to expose your actual network topology. Hiding it would break calls. The spec authors picked connectivity over privacy on purpose. Chrome started masking local IPs in 2019 with randomized .local hostnames. The original 2015 srflx leak (your real public IP, pulled via STUN) still fires on default Firefox in 2026. Most "WebRTC leak protection" extensions don't actually plug it. They hide the IP from JavaScript while the ICE candidate still ships out at the network level. Like putting a curtain over a window that's wide open.

How Ten Lines of Code Read Your Real IP

Open RTCPeerConnection. Point it at a STUN server, stun.l.google.com:19302 works fine. Listen for icecandidate events. Print whatever lands. Done. Ten lines, copy-paste from Stack Overflow. What comes through: every IP the browser thinks it can reach. Host candidates (your LAN addresses, 192.168.1.42 or 10.0.0.5). Server-reflexive candidates (your public IP as Google's STUN server sees it). Sometimes relay candidates if a TURN server is configured. WebRTC's design philosophy was completeness over privacy: hand the application every available network path and let JavaScript sort it out. Same logic as a hotel receptionist giving a guest the entire keyring instead of just the one for room 204. So what breaks? Those UDP packets for candidate gathering go through the OS default route. Usually the VPN tunnel. Not always. Chrome historically gathered candidates on all interfaces in parallel, not only the default route. VPN tunnel returns one set of candidates. Physical wifi returns another. Page reads both. Now it has your VPN IP and your real IP sitting side by side. Mozilla added a toggle in 2017: media.peerconnection.ice.proxy_only. Still off by default in 2026. Chrome's mDNS rollout only covered local IPs, leaving the srflx vector untouched. A decade after the original disclosure, the same ten lines still work on a stock Firefox install. Nope, not a typo.

Why Extensions and Browser Flags Don't Cut It

What does Reddit recommend circa 2024: install "WebRTC Leak Prevent" or "WebRTC Control." Advice sounds right. It's wrong in a way that matters. Extensions override RTCPeerConnection at the JavaScript layer. A page that reads pc.onicecandidate gets empty results. Looks fixed. But ICE gathering still happens underneath, at the network level. UDP packets still leave your real interface. ISP sees the STUN traffic. Office firewall logs it. Anyone with tcpdump on the local network catches it. Your IP didn't stop leaking. It stopped leaking to JavaScript. The network still got the memo. Soundproofing one wall of a glass house. Most VPN browser extensions pull the same trick. Override the API, leave the wire untouched. Turns out there's a meaningful difference between "the webpage can't read it" and "nobody can see it." Chrome's mDNS change from 2019 is better but incomplete. Local IPs (host candidates) become randomized hostnames like c0fb3b9e-3d05.local. Page can't read 192.168.1.42 anymore. Good. But mDNS doesn't touch srflx candidates. Your public IP discovered through STUN still goes out, still gets collected. Quick self-test: run any WebRTC leak checker with your current setup. If srflx candidates show your real public IP instead of the VPN's, nothing was actually fixed. The test just stopped advertising the reading. Like covering the speedometer while the car still goes 90.

Three Things That Actually Stop It

Exactly three fixes work. None of them are extensions. TURN-only mode. Force the browser to use relay candidates exclusively, never host or srflx. Firefox: about:config, media.peerconnection.ice.proxy_only = true. Chrome doesn't expose a flag for this. You need a Chrome Enterprise policy file or uBlock Origin's advanced mode with the WebRTC relay-only setting. Straight up, this is the cleanest fix. Trade-off: video calls route through a TURN server, adding 30 to 80ms of latency and roughly doubling bandwidth consumption. Worth it if you value the seal. Steep if you run three-hour team standups. Firewall rules on the network layer. Drop all UDP on non-VPN interfaces. Linux: nftables output chain, drop UDP unless source is the tun device. Windows: WireGuard's built-in kill switch handles this when configured strictly. macOS: pf rules, manual config because Apple removed pfctl from the GUI years ago. Once UDP can't escape outside the tunnel, STUN requests can't either, and srflx returns only the VPN's IP. Like welding the window shut instead of hanging curtains. Nuclear option: disable WebRTC entirely. Firefox: about:config, media.peerconnection.enabled = false. Chrome: enterprise policy only, no user flag. Side effects are obvious. Google Meet stops. Discord voice stops. Slack calls stop. Zoom in the browser stops. Correct answer for a journalist working a sensitive source. Wrong answer for anyone who actually uses video calls at work. The test here probes multiple STUN servers across different ICE candidate types and tells you which specific type leaked. Useful when you've applied a fix and need to verify it caught the srflx path, not just the host candidates everyone already knows about.

FREQUENTLY ASKED QUESTIONS

How do I disable WebRTC?

In Firefox: go to about:config and set media.peerconnection.enabled to false. In Chrome: install a WebRTC blocking extension. Most VPN browser extensions also include WebRTC leak protection.

What is an ICE candidate?

ICE (Interactive Connectivity Establishment) candidates are potential network paths for WebRTC connections. They include your local IP, public IP discovered via STUN, and relay addresses from TURN servers.

Is WebRTC leak dangerous?

Yes, a WebRTC leak can expose your real IP address to websites even when using a VPN. This defeats the purpose of using a VPN for privacy and can reveal your true location.

All our tests

Run the full WHOX toolkit from one place: leak checks, fingerprint probes, network diagnostics, reputation lookups, and privacy failure tests.