WebRTC Leak Test

WebRTC uses ICE (Interactive Connectivity Establishment) to discover network paths for peer-to-peer connections. ICE sends UDP packets to public STUN servers to learn the browser's public IP. SOCKS5 only intercepts TCP application traffic — those UDP STUN packets escape the tunnel and reveal your real public IP to any WebRTC-enabled site.

The tool lists three candidate types: host (your LAN IP), srflx (your public IP as seen by a STUN server), and prflx (peer-reflexive, only during active calls). If the srflx candidate matches your SOCKS5 proxy exit IP, WebRTC is safely tunneled. If it matches your home ISP IP, you have a leak.

Chrome has no native toggle. Install the 'WebRTC Network Limiter' extension (published by the Chromium team) or enable uBlock Origin's 'Prevent WebRTC from leaking local IP addresses' toggle under advanced settings. After enabling, reload this tool and confirm no srflx candidate appears.

Open about:config, search for media.peerconnection.enabled and set it to false. Reload this page — the candidate list should be empty. This fully disables WebRTC and breaks video-call sites; toggle it back to true when you need Google Meet or Discord.

No. The test creates an RTCPeerConnection locally and reads ICE candidates entirely in your browser. STUN packets go from your browser directly to Google's public STUN servers (stun.l.google.com). Best SOCKS5 servers are never contacted during the test.

Modern browsers gather candidates on every network interface: physical Ethernet, Wi-Fi, VPN adapter, virtualization bridges. Each interface produces its own host candidate. Only srflx candidates matter for proxy leak testing — host candidates are LAN-only and cannot escape your network.

iOS Safari 15+ blocks public IP disclosure via WebRTC without user interaction — the srflx candidate is empty until the user grants camera or microphone permission. Chrome on Android still leaks the public IP; use a mobile browser like Brave which blocks it by default, or install a browser extension equivalent.

Load their proxy in your browser, reload this tool, and confirm the srflx candidate either matches the proxy exit IP or is absent entirely. If it matches your home ISP IP, the provider's claim is false — file a support ticket with a screenshot of this page as evidence.

Chrome and Edge replace local host candidates with random .local mDNS hostnames — this hides your LAN IP but does not stop srflx candidates from revealing your public IP. mDNS obfuscation is not a fix for proxy leaks. Only extensions or network policies that block STUN traffic entirely stop srflx leaks.

No. Chrome's --proxy-server flag only routes TCP traffic. WebRTC ICE gathering uses UDP STUN, which bypasses the SOCKS5 socket entirely and reaches Google's STUN servers directly. You must combine SOCKS5 with an extension or Chromium policy that limits WebRTC network interfaces.

Yes — any page with a script that instantiates RTCPeerConnection can enumerate candidates silently, without permission prompts. Ad networks and fingerprinting scripts do this routinely. Assume every third-party script on a page can trigger the leak surface unless you've blocked WebRTC.

If your ISP provides native IPv6, the browser will offer both v4 and v6 srflx candidates. SOCKS5 tunnels IPv4 only for most clients — so IPv6 traffic (including STUN over IPv6) bypasses the tunnel. Disable IPv6 in your OS or force the proxy to handle both to eliminate this leak.

Reputable antidetect browsers (Multilogin, GoLogin, Kameleo, AdsPower) either block WebRTC entirely or replace the srflx candidate with the proxy exit IP. Run this tool inside your antidetect profile to confirm the behavior matches the setting — a silent misconfiguration is common on custom profiles.

Open a fresh incognito/private window, load your proxy configuration, then load this tool. Incognito windows create new browsing contexts that discard old ICE agent state. Reload the page 2–3 times and confirm candidate readings are consistent.