WebRTC Leak Test

WebRTC stands for Web Real-Time Communication. It is a browser API that enables peer-to-peer audio, video, and data transfer without plugins. Zoom, Google Meet, Discord, and most browser-based video calling tools rely on it.

When you join a video call, your browser needs to establish a direct connection to the other participant. To do this, it has to figure out its own public IP address and network topology. That discovery process uses STUN servers—external servers that tell your browser how it appears on the internet.

The problem is that this discovery happens automatically, in the background, triggered by any website with a few lines of JavaScript. You do not need to be on a video call. You do not need to grant permission. The browser will happily reveal your IP to any page that asks.

Here is what happens. A website creates an RTCPeerConnection object and points it at a STUN server (usually Google’s public server at stun.l.google.com). The browser sends a STUN binding request. The STUN server responds with the public IP address it sees the request coming from. The browser then exposes that IP through the ICE candidate event.

The critical detail: this STUN request can bypass your VPN tunnel. Most VPNs work by routing traffic through a tunnel interface at the network layer. But WebRTC operates at the application layer. Depending on your OS, browser, and VPN configuration, the STUN packet may leave through your real network interface instead of the tunnel.

The result is that a website sees two things at once: your VPN IP (from the normal HTTP request) and your real IP (from the WebRTC STUN response). It can trivially compare the two. If they differ, it knows you are using a VPN and it knows your actual location.

This happens silently. No popup. No permission dialog. No indicator in the address bar. The entire process takes less than a second and requires roughly ten lines of JavaScript.

A WebRTC leak defeats the purpose of your VPN. You paid for privacy. You connected to a server in another country. Your HTTP traffic goes through the tunnel. But your real IP is exposed to every site that runs the check—and many do.

Ad networks use WebRTC fingerprinting to de-anonymize VPN users. Streaming services use it to enforce geo-restrictions. Authoritarian governments can use it to identify dissidents who think they are browsing anonymously. The leak is silent, invisible, and most VPN users have no idea it is happening.

Unlike DNS leaks, which require infrastructure to detect, WebRTC leaks can be triggered by any website with client-side JavaScript. No server cooperation needed. No special permissions. The browser hands over the IP voluntarily.

Chrome and Chromium-based browsers

Chrome enables WebRTC by default with no user-facing toggle to disable it. Google introduced mDNS obfuscation for local IP addresses, replacing them with randomized .local addresses. But this only masks your local network IP—your public IP is still discovered via STUN and fully exposed. Extensions can limit WebRTC behavior, but Chrome provides no native protection.

Firefox

Firefox is the only major browser that lets you disable WebRTC entirely. Navigate to about:config, search for media.peerconnection.enabled, and set it to false. This completely prevents WebRTC IP discovery. The trade-off: video calls in the browser will stop working.

Safari

Safari has limited WebRTC support and applies stricter restrictions than Chrome. It does not expose local IP addresses through ICE candidates by default. However, public IP leaks through STUN are still possible depending on configuration.

Brave

Brave provides built-in WebRTC leak protection. Under Settings > Privacy and Security, you can set the WebRTC IP handling policy to block non-proxied UDP connections. This is the best built-in protection of any Chromium browser.

Modern versions of Chrome and Edge replace your local IP addresses with mDNS addresses—random UUIDs like a1b2c3d4-e5f6-7890-abcd-ef1234567890.local. This prevents websites from learning your private network layout (whether you are on 192.168.1.x or 10.0.0.x, whether you have multiple interfaces, etc.).

This is a real improvement for local network privacy. But it does not fix the main problem. STUN-discovered public IPs are not replaced with mDNS. If a STUN server returns your real public address, that address appears in the ICE candidate as-is. mDNS only protects local addresses—it is not a WebRTC leak fix.

If this test shows mDNS addresses but no public IPs, your local network is hidden but the real question is whether STUN requests are being routed through your VPN or escaping to the open internet.

Most VPNs rely on routing rules to direct traffic through the tunnel. Routing rules work for normal HTTP traffic. They do not reliably intercept WebRTC STUN requests, which can use UDP on non-standard ports and bypass per-application routing.

Fexyn VPN takes a different approach. The kill switch uses Windows Filtering Platform (WFP) rules—the same kernel-level firewall API that Windows Defender uses. When the VPN is connected, WFP blocks all traffic that does not pass through the tunnel interface. This includes STUN requests. If a STUN packet tries to leave through your real network interface, the kernel drops it before it reaches the network stack.

The result: when you run this WebRTC leak test with Fexyn VPN connected, the STUN server sees your VPN IP, not your real one. The browser still functions normally for video calls—WebRTC works, it just routes through the tunnel like everything else. No extensions needed. No browser settings to change. The firewall handles it at the OS level.