A WebRTC IP leak happens when a browser's real-time communication layer reveals your real public or local IP address through ICE and STUN, even while a VPN or proxy is active. The leak is not a bug; it is how WebRTC's connection machinery is designed to discover usable network addresses. You can mitigate it with browser settings, privacy extensions, mDNS obfuscation, and full-tunnel VPN configurations, and you can detect it with any reputable WebRTC leak test. Developers building with WebRTC should understand this behavior because it shapes how users perceive the privacy of video calling apps, including those built on platforms like VideoSDK.
Introduction
A privacy researcher joined a video call from a coffee shop network while connected to a commercial VPN. Mid-call, out of curiosity, she opened a WebRTC leak test page in a second tab. The test showed two public IP addresses: the VPN's exit address, and her carrier-assigned address from the coffee shop's upstream provider. Her VPN was working perfectly for normal browsing. WebRTC had simply routed around it.
That scenario plays out millions of times a day, and most people never notice. For privacy-conscious users, it is a silent exposure of their approximate physical location. For developers, it is a design consequence of the WebRTC stack that every real-time communication product inherits unless it is deliberately engineered around. The same mechanism that lets a video call connect in under a second is the mechanism that hands your network addresses to whoever is on the other end, or to any web page that quietly runs candidate gathering in the background.
This article walks through the full picture: what a WebRTC IP leak actually is, how ICE and STUN discover your addresses, why VPNs so often fail to block the exposure, what browser vendors have done to mitigate it, how to test for it yourself, and what practical steps actually work.
What Are WebRTC IP Leaks?
A WebRTC IP leak is defined as the exposure of a device's real network addresses, public or local, through the WebRTC API's address discovery process, rather than through the normal HTTP request path. WebRTC works by gathering ICE candidates, which are address-and-port pairs the browser collects from every network interface it can reach. These candidates include addresses obtained from STUN servers, which reflect back the public IP address that the request appears to come from.
The critical thing to understand is that the leak is a design feature, not a bug. Candidate gathering exists so that two peers behind different networks can find a direct media path to each other. Without it, peer-to-peer video calling would be impossible. The privacy cost is that those candidates are visible to the remote peer, and in some scenarios to the web page itself.
How WebRTC Discovers Network Addresses
WebRTC's address discovery is a multi-stage process, and each stage produces a different kind of candidate with a different privacy footprint. Understanding the stages tells you exactly which addresses leak and why.
ICE and Candidate Types
ICE, which stands for Interactive Connectivity Establishment, is the framework WebRTC uses to gather and test candidate network paths. It produces three main candidate types. Host candidates are the actual IP addresses of every network interface on your device, including your LAN address and any virtual adapters created by VPN software. Server-reflexive candidates, often abbreviated as SRFLX, are the public IP and port that a STUN server observes when your device contacts it. Relay candidates are addresses on a TURN server, used only when direct paths fail; these do not leak your real IP because the TURN server acts as an intermediary.
The privacy problem sits almost entirely with host and server-reflexive candidates. Host candidates expose local network topology, and server-reflexive candidates expose your real public IP whenever the STUN request bypasses your VPN's tunnel.
STUN and TURN in Plain Language
A STUN server's entire job is to answer one question: what address did this request come from? Your browser sends a UDP packet to the STUN server, and the server replies with the source address it saw. If that packet traveled through your VPN tunnel, the reply shows the VPN's exit IP. If the packet slipped out through a split tunnel or a raw UDP route, the reply shows your true ISP-assigned address. That single reflected packet is the core mechanism behind most WebRTC IP leaks.
TURN servers are the opposite from a privacy standpoint. When media flows through TURN, the remote peer only sees the TURN server's address. This is why enterprise deployments and privacy-sensitive applications route media through TURN relays deliberately, accepting higher latency in exchange for address hiding. VideoSDK, for example, provides managed TURN infrastructure as part of its real-time communication platform, so applications built on it can relay media without exposing participant addresses directly.
Role of UDP and Browser Network Stack
UDP is the transport that makes the bypass possible. Most traditional VPN tunnels were built around TCP, encrypting TCP traffic cleanly but handling UDP inconsistently. WebRTC's media and STUN traffic travel over raw UDP, and if the VPN client does not capture that UDP at the virtual interface level, the packets exit through the default route with your real address attached. Even modern VPNs with UDP support can leak if split-tunnel rules exclude the browser's traffic or if the VPN's kill switch does not cover UDP flows.
The overall flow can be described in words. The browser begins by enumerating every local network interface and turning each interface's address into a host candidate. It then sends a UDP request to a configured STUN server; the server replies with the public address it observed, which becomes the server-reflexive candidate. If direct connectivity checks between the two peers fail, the browser falls back to requesting a relay allocation on a TURN server, producing a relay candidate. Finally, the browser pairs its candidates with the remote peer's candidates and runs connectivity checks, selecting the first working pair as the media path. The leak occurs at the second step whenever the STUN request escapes the VPN tunnel, because the reflected address in the reply is then the user's true public IP rather than the VPN exit address.
Why VPNs Fail to Block WebRTC Leaks
Many users assume a VPN hides everything, so the persistence of WebRTC leaks surprises them. The failure has several distinct causes, and knowing which one applies to you determines the fix.
Split Tunneling and Route Exclusion
Split tunneling is a VPN feature that sends only selected traffic through the encrypted tunnel while everything else uses the default network route. It improves performance and reduces load on the VPN server, but it also means any traffic class not explicitly captured, most commonly raw UDP, exits with your real address. WebRTC's STUN requests are small, fast UDP packets that fit neatly into the gaps of a poorly configured split-tunnel rule set.
Virtual Adapters and Interface Enumeration
A VPN client typically creates a virtual network adapter. When WebRTC enumerates interfaces, it sees both the virtual adapter and the physical one. If the VPN's routing does not force all UDP through the virtual adapter, the physical interface remains a viable source for host candidates, and the browser will happily use it. Some VPN clients also register loopback or secondary adapters that leak additional local addresses into the candidate list.
Kill Switch Gaps
A kill switch is supposed to block all traffic if the tunnel drops. In practice, many kill switches only monitor the TCP connection state of the VPN itself. UDP flows can continue uninterrupted during a tunnel reconnection window, and a STUN request sent during that window reflects your real address. This is a narrow but real exposure window that most users never realize exists.
What Browser Vendors Have Done
Browser vendors are aware of the leak and have shipped meaningful mitigations, though coverage and defaults vary.
mDNS Obfuscation
Modern Chrome, Firefox, and Safari versions obscure host candidates by replacing local IP addresses with dynamically generated multicast DNS names, such as randomized local hostnames ending in the .local domain. The remote peer receives the mDNS name instead of the LAN address, and the browser resolves it only if the peer is on the same local network. This effectively hides local network topology from remote peers and web pages. However, mDNS obfuscation does nothing to hide server-reflexive candidates, so your real public IP can still leak through STUN.
Firefox's Media Peer Connection Settings
Firefox exposes a configuration option that controls whether WebRTC generates candidates from all interfaces or only the default route. Setting it to use only the default route means the browser will not enumerate every interface, which closes the most common host candidate leak on machines with multiple adapters. This is a per-user setting, not a default, so most users remain exposed unless they change it.
Chrome and Edge Policy Controls
Chrome and Edge offer enterprise policies that can disable non-proxied UDP traffic and restrict WebRTC to proxied connections. When UDP is restricted and a proxy is configured, STUN requests travel through the proxy, and the reflected address becomes the proxy's address rather than the user's real one. These policies are primarily aimed at managed deployments, but privacy-aware individual users can apply them through local policy configuration on some platforms.
How to Test for WebRTC IP Leaks
Testing is straightforward and requires no technical skill. Open your browser, connect to your VPN if you use one, and visit any reputable WebRTC leak test page. The test runs candidate gathering in your browser and displays every address it discovers.
Interpret the results by comparing what the test shows against your VPN's exit IP, which you can find by visiting any what-is-my-IP service in the same browser. If the test shows only the VPN exit address, you are not leaking. If it shows an additional public address that matches your ISP or carrier, you have a live WebRTC leak. If it shows local addresses such as a home LAN range, those are host candidates; modern browsers usually mask them with mDNS names, and seeing raw local IPs indicates an older browser or disabled obfuscation.
Run the test in every browser you use, because WebRTC behavior is per-browser, not per-device. Also re-run it after any VPN client update, browser update, or operating system upgrade, since any of these can change routing or candidate gathering behavior.
Practical Prevention Strategies
For End Users
The most reliable user-side fix is a properly configured full-tunnel VPN that captures UDP at the virtual interface level, combined with a kill switch that covers UDP flows. Check your VPN client's settings for options described as full tunnel, force all traffic, or block LAN bypass, and enable them. If your VPN client offers split tunneling, either disable it or verify that browser traffic is included in the tunnel.
Browser-level mitigations add a second layer. In Firefox, configure the media peer connection setting to use only the default route. In Chrome and Edge on managed platforms, apply the non-proxied UDP restriction policy. Privacy-focused browser extensions can also disable WebRTC entirely or strip local candidate generation, though disabling WebRTC breaks all in-browser video calling, so weigh that trade-off if you rely on browser-based meetings.
Finally, keep your browser updated. mDNS obfuscation and other mitigations arrive through normal updates, and older browsers remain fully exposed.
For Developers
Developers building real-time communication products have a different set of responsibilities. First, understand that your application inherits WebRTC's candidate gathering behavior, and that privacy-conscious users will test your product for leaks. Second, prefer relayed media architectures when address hiding matters: routing media through TURN means participants only ever see relay addresses, which eliminates both host and server-reflexive exposure at the cost of some latency. Managed platforms like VideoSDK make this straightforward by providing TURN infrastructure as part of the platform, so you get address hiding without operating relay servers yourself.
Third, be deliberate about which STUN servers you configure and what your application exposes to the page. Avoid triggering candidate gathering before the user actually joins a call, because gathering at page load hands addresses to any site that embeds your SDK. Fourth, document your privacy behavior clearly: tell users whether media is peer-to-peer or relayed, and what that means for address exposure. Transparency here builds trust and reduces support load.
Common Misconceptions
A few persistent myths deserve correction. WebRTC leaks are not caused by VPN bugs in most cases; they are caused by the VPN not covering the specific traffic class WebRTC uses. Disabling JavaScript does not stop leaks, because candidate gathering is part of the WebRTC API, not a script you can block selectively. Incognito or private browsing modes change nothing, since they affect history and cookies, not network stack behavior. And HTTPS is irrelevant here: an encrypted page can still run candidate gathering, because the leak is about what the browser reveals, not about what an attacker intercepts.
Conclusion
WebRTC IP leaks are a structural consequence of how real-time communication finds usable network paths. ICE gathers candidates from every interface, STUN reflects your public address, and UDP lets that traffic slip past VPN tunnels that were designed around TCP. The result is that your real IP can be exposed even when everything else about your setup looks private.
The mitigations are equally structural. Full-tunnel VPNs that capture UDP, browser settings that restrict candidate generation, mDNS obfuscation that hides local addresses, and TURN relays that hide public ones each close a different part of the exposure. Users should test regularly and configure their tools deliberately. Developers should design for address hiding from the start, favoring relayed architectures and managed infrastructure like VideoSDK when participant privacy matters. The leak will never be patched away entirely, because it is how the technology works, but with the right configuration it can be reduced from a silent exposure to a solved problem.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ