webrtc leaks explained

Your VPN promises to hide your real IP address. Most consumer VPNs, operating in 2026, fail at this promise specifically because of WebRTC — a browser API that bypasses the VPN tunnel by design. A single line of JavaScript on a website can silently expose the real IP address of a VPN-using visitor. This page is the technical explanation, the per-browser fix, and the verification procedure. As of this writing, the fix takes about 60 seconds.

What WebRTC is supposed to do

WebRTC ("Web Real-Time Communication") is the browser API that makes video calls, voice chat, and peer-to-peer file transfer possible without plugins. Zoom, Google Meet, Discord, Slack Huddles, WhatsApp Web — all of them use WebRTC under the hood. For WebRTC to work, two browsers on opposite sides of the internet need to establish a direct path for audio and video, bypassing the web server that introduced them.

Finding that direct path requires a protocol called ICE (Interactive Connectivity Establishment). ICE enumerates every network interface the local machine has — WiFi, wired Ethernet, VPN adapter, cellular, virtual adapters — and generates a list of candidate addresses. The candidates are shared with the peer, the peer does the same, and ICE finds the pair of addresses that can talk to each other most directly.

This enumeration is the problem.

How the leak happens

When the browser's WebRTC asks the operating system "give me every network interface and its address," the OS responds honestly with the complete list — including the underlying wired or WiFi interface even while a VPN is connected. The VPN creates a virtual network interface above the application layer; the OS sees all of them. The local LAN IP and the real public IP (via STUN lookup to a public STUN server) both end up in the candidate list.

If a web page creates a WebRTC peer connection — even one it never intends to complete — it can read the candidate list via a one-line JavaScript call:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('leak');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

The logged candidates include both the local LAN IP (192.168.x.x, 10.x.x.x, etc.) and the real public IP — even while the VPN tunnel is supposedly active. The page now knows the user's real location, real ISP, and real LAN setup. A tracker running this code on thousands of sites has effectively un-VPN'd every visitor.

This is not theoretical. Academic research in 2015-2018 documented the leak affecting the vast majority of VPN-using browsers. Mitigations shipped in browsers starting around 2018, but they are not on by default in most cases and require manual configuration.

Why VPN software often doesn't fix it

VPN clients operate at the network layer. They create a virtual tunnel interface and ideally route traffic through it, but the ICE enumeration question happens one layer up — at the operating system, from the browser process. The VPN tunnel cannot intercept a question that is never asked of it. Some VPN clients include browser-level WebRTC fixes (Mullvad's browser, some NordVPN extension versions, ProtonVPN's browser extension) but the majority leave the application-layer defense to the user.

The practical test: connect your VPN, then run SNITCHTEST. If the WebRTC row shows a local IP or a public IP that matches your real location rather than your VPN exit, you have a leak. If it shows "blocked" or a VPN-range IP, the defense is working.

The fix, per browser

Chrome, Edge, Opera, Arc (Chromium family)

Install Google's official WebRTC Network Limiter extension from the Chrome Web Store. Open its options page and set the mode to "Use my proxy server (if present); otherwise use any other routes". This flag tells Chromium's WebRTC to only enumerate interfaces reached through the proxy or default route — the VPN interface, when one is connected. The other network interfaces are never enumerated, so their IPs never land in the candidate list.

Effect: video calls continue to work fully; leaks stop. The extension is ~30 KB and is published directly by Google, so its provenance is about as clean as Chrome extensions get. No account, no signup.

Brave ships with stronger defaults than stock Chromium. Settings → Shields → Fingerprinting → Strict applies several mitigations including WebRTC IP masking. The Network Limiter extension is still worth installing for the strictest layer of defense.

Firefox

Type about:config in the Firefox address bar. Accept the warning. Set two preferences:

media.peerconnection.ice.default_address_only = true
media.peerconnection.ice.no_host = true

The first forces ICE to use only the default route. The second suppresses enumeration of local host candidates entirely (so LAN IPs never leak either). Both are safe; video calls continue to work because the default route is usable for establishing connections.

Firefox with privacy.resistFingerprinting = true also closes the leak as part of its broader anti-fingerprinting suite. If you already enabled RFP for anti-fingerprinting, the WebRTC fix is included.

Safari

Safari closes the WebRTC local-IP leak by default on non-HTTPS origins, and its ICE candidate gathering is more conservative than Chromium or Firefox by default. There is no specific configuration needed. Users can verify with SNITCHTEST — the WebRTC local-IP row should show as blocked or hidden.

Older Safari versions (pre-13) had leak issues; any current Safari release (2020 onward) is safe out of the box.

Mobile browsers

iOS Safari — same defaults as desktop Safari. Leaks are suppressed by default.

iOS Chrome / Firefox / Brave — on iOS, all browsers are WebKit under the hood (Apple requires this). The same WebKit defaults apply; leaks are suppressed.

Android Chrome / Firefox / Brave — the desktop configuration applies, with one caveat: extensions are not available in stock Chrome on Android. Firefox for Android supports about:config; set the same two preferences as desktop. Bromite + Brave both ship with WebRTC mitigations enabled by default.

Verifying the fix

After applying the fix, verify with a live test. Run SNITCHTEST while your VPN is connected. Check two specific rows:

• LAN IP — should show as "hidden" or an mDNS hash ending in .local. If it shows a real 192.168.x.x or 10.x.x.x address, the local-IP leak is still active.
• IP / WebRTC srflx — should show your VPN exit's public IP, not your real ISP-assigned IP. Cross-check against what the VPN's own "what's my IP" page shows; they should match.

SNITCHTEST also includes a server-observed IP check that catches a different leak class: if the server sees an IP different from what WebRTC reveals, split-tunnel misconfigurations are flagged.

What the fix does not address

Closing the WebRTC leak fixes the most common VPN failure mode but does not close every information channel. A determined tracker can still infer your real location or ISP through:

• Browser fingerprinting — canvas, audio, font, timezone. VPN does nothing for these. See Canvas Fingerprinting Explained.
• Server-side IP correlation — if you log into the same service logged-in-at-home and logged-in-via-VPN, the service correlates the sessions server-side regardless of IP.
• DNS leaks — separate category from WebRTC. A DNS leak is when your DNS queries go to your ISP's resolver instead of the VPN's resolver, revealing which sites you visit even when the connections are VPN-routed. Most modern VPN clients fix DNS leaks; verify with a DNS leak test separately.
• Time-zone mismatch — browser timezone reporting real location while IP says VPN location is a correlation attackers exploit. SNITCHTEST's geo-vs-timezone check flags this.

For a comprehensive defense, pair the WebRTC fix with browser anti-fingerprinting (Brave Strict or Firefox RFP), a content blocker (uBlock Origin), and a careful approach to logged-in services. See How to Stop Fingerprinting for the full layered guide.

FAQ

Related: The Dossier · How to Stop Fingerprinting · Canvas Fingerprinting Explained · Glossary