What Is a WebRTC Leak

What WebRTC actually does

WebRTC (Web Real-Time Communication) lets web pages establish direct connections between two browsers for voice, video, and data. Direct connections through home NAT are hard — the two parties need to discover each other's public IPs and the path through the NAT. The protocol that handles this is ICE (Interactive Connectivity Establishment), which gathers a list of "candidates" describing every network path the browser might be reachable on.

The candidate list includes:

• Host candidates — local IP addresses on each network interface (Wi-Fi, Ethernet, VPN tunnel, IPv6).
• Server-reflexive candidates — the public IPs the browser sees when it reaches out through a STUN server.
• Relayed candidates — TURN server addresses used when direct connection isn't possible.

For a normal video call this is exactly the right behavior. For a tracking script, the same machinery hands over a complete map of your network identities.

The leak in detail

A standard JavaScript snippet to create an RTCPeerConnection and read its ICE candidates is about a dozen lines. The script doesn't need to actually start a call. It just creates the peer connection, triggers candidate gathering, and reads each ICE candidate as it arrives. Within hundreds of milliseconds the script has:

• Your local IP behind your home router (e.g., 192.168.1.42).
• Your VPN tunnel's local IP (e.g., 10.8.0.5).
• Your real public IP if STUN was used and the non-VPN interface was active.
• Your IPv6 addresses, public and ULA.

Even if your browser is dutifully sending all your HTTP traffic through the VPN, the WebRTC API can independently reach STUN servers — sometimes through whichever route happens to be available. If your OS has the real interface still active for any reason, the public IP it sees through STUN is your real one.

The Chrome WebRTC handling policy

Chromium-based browsers expose a policy with four modes:

1. default — gather all candidate types. Maximum compatibility, maximum leak.
2. default_public_interface_only — use only the default public-facing interface. Eliminates local-IP leak.
3. default_public_and_private_interfaces — both public and private, no others.
4. disable_non_proxied_udp — block all WebRTC UDP traffic that doesn't go through a configured proxy. Strongest, but breaks WebRTC where the browser isn't already proxied.

For VPN users the practical recommendation is disable_non_proxied_udp combined with sending all traffic through the VPN. For users who don't use WebRTC at all, disabling it entirely is simpler.

How to test for a WebRTC leak

Several public test sites run an RTCPeerConnection in the browser and display the candidates that come back. A clean configuration shows only the VPN's IP (or no public IP at all if WebRTC is restricted). A leaking configuration shows your real public IP alongside the VPN's.

Test in these conditions:

1. VPN off — establish your baseline real IP.
2. VPN on, default browser settings — see what leaks.
3. VPN on, after applying mitigation — confirm the real IP no longer appears.
4. After a browser restart — confirm the fix persists.

VPN client–side protection

Some VPN clients include "WebRTC leak protection" as a checkbox feature. The mechanism varies:

• Browser extension that modifies the WebRTC API surface.
• Firewall rules that block traffic to known STUN server ports from outside the tunnel.
• Configuration suggestions in the VPN client UI.

None of these are infallible. The most reliable protection is browser-level, applied directly in the browser configuration. Treat VPN-client protections as a backstop, not a primary defense.

The trade-off: video calling stops working

Aggressive WebRTC blocking breaks legitimate use cases. If you actually use Google Meet, Discord, or browser-based video conferencing, you need WebRTC active during those calls. The compromises:

• Use a separate browser profile (or a separate browser) for video calling with WebRTC enabled, and your main profile with WebRTC disabled.
• Use default_public_interface_only mode — keeps WebRTC working for most call services while shrinking the leak surface.
• Toggle WebRTC on only when needed, off the rest of the time.

Relationship to other privacy leaks

WebRTC is one of three browser-level IP-disclosure mechanisms VPN users should think about:

1. DNS leak — domains leak to the ISP. See what is a DNS leak.
2. WebRTC leak — IP leaks via browser peer-connection APIs.
3. IPv6 leak — IPv4-only VPNs may not tunnel IPv6 at all, exposing both DNS and IP simultaneously through that path.

All three should be checked after setting up a new VPN configuration. Fixing one does not fix the others.

Frequently Asked Questions

What is a WebRTC leak?

A WebRTC leak is when a website uses the browser's WebRTC API to discover your real IP address through ICE candidate gathering, bypassing the IP address shown by a VPN. WebRTC was designed for peer-to-peer video calls and needs to know your local network addresses to negotiate a connection — that local-address discovery is the leak vector when misused by tracking scripts.

How does WebRTC leak my IP?

When a script calls the WebRTC peer-connection API, the browser uses STUN servers to discover its public IP for NAT traversal. Without restrictions, the browser reveals every IP it has on every network interface — including the non-VPN interface that the OS still has active. A simple script reads these from the ICE candidates and reports your real IP to the site.

How do I prevent WebRTC leaks?

Disable or restrict WebRTC in your browser. Firefox has a media.peerconnection.enabled setting. Chrome and Edge support WebRTC handling policy that can be set to default_public_interface_only or disable_non_proxied_udp. Extensions like WebRTC Network Limiter restrict the leak surface without disabling video calls. Some VPN clients include WebRTC leak protection by blocking the API at the application level.

Does Tor Browser leak via WebRTC?

Tor Browser disables WebRTC entirely by default. The trade-off is that voice and video calling sites don't work, but the privacy guarantee is absolute. For users who need WebRTC, Tor is not the right tool; for users who do not, the disabled-by-default behavior is the correct posture.

What is the difference between a WebRTC leak and a DNS leak?

A DNS leak exposes the domain names you visit by sending DNS queries to a resolver outside your VPN. A WebRTC leak exposes your real IP address by using browser peer-connection APIs to enumerate local network interfaces. They are independent — you can leak DNS without leaking WebRTC and vice versa. Each needs a separate fix.