WebRTC Leaks: Why Your VPN Shows the Wrong IP and How to Fix It

The leak that bypasses your tunnel

WebRTC is the browser technology behind in-page voice and video calls. To establish direct peer-to-peer connections, it needs to discover every network path your device has—and it does this by asking the operating system for all local interfaces and by querying STUN servers, a process that happens entirely outside your HTTP proxy settings. On many configurations, WebRTC traffic does not follow the VPN tunnel at all, because it uses direct UDP sockets rather than the browser’s normal fetch path.

The result: a website can run a few lines of JavaScript, create an RTCPeerConnection, and learn your real public IP while your VPN icon proudly shows a foreign country. This is not a bug in your VPN and not a hack of your machine—it is WebRTC doing exactly what it was designed to do. The design goal (fast calls) simply conflicts with the privacy goal (one visible address).

How to test for the leak

Connect your VPN or proxy first—the test is only meaningful while the tunnel is up. Then run an IP check and note the address; separately, open any WebRTC leak test page (or your browser console: create a peer connection, add a STUN server, and read the ICE candidates). Compare the two. If the WebRTC result shows an address belonging to your real ISP instead of your VPN exit, you are leaking. Also compare IPv6: many setups tunnel IPv4 correctly while the device’s global IPv6 address sails straight through.

Repeat the test in every browser you actually use. WebRTC handling differs between Chrome, Firefox, Safari, and Edge, and fixing one does not fix the others.

Fixes that actually work, browser by browser

• Firefox: type about:config, set media.peerconnection.enabled to false. This is the only major browser with a complete built-in off switch.
• Chrome / Edge: no built-in switch; install the provider’s official WebRTC-control extension (most reputable VPNs publish one) or use "WebRTC Network Limiter" type extensions that force the "public interface only" policy.
• Safari: leaks are rarer because of stricter permission prompts, but test anyway—older versions exposed candidates freely.
• All browsers: handle IPv6 at the system level—disable IPv6 on the device or ensure the VPN tunnels it; browser settings cannot fix an untunneled IPv6 stack.

What you give up by disabling WebRTC

Browser-based calling (Google Meet in the browser, Discord web voice, many telehealth and interview platforms) depends on WebRTC. Disabling it entirely breaks those calls, which is why the "public interface only" policy is usually the better fix: it keeps calls working while hiding non-tunneled addresses. If a specific site needs calls, re-enable for that session rather than leaving the leak open permanently.

Finally, retest after every browser update and every VPN client change. Leak behavior is a moving target: browser defaults change, VPN clients add and remove their own WebRTC protections, and an extension can be silently disabled by a policy update. A leak test takes thirty seconds; making it part of your routine after updates is the only durable fix.

References and source material

These sources are provided so readers can verify the technical background. Inclusion does not imply endorsement of TrustIP.

• MDN — WebRTC API overview
• RFC 8825 — WebRTC security considerations