WebRTC Leak Test

WebRTC is a real-time communication stack built into every modern browser. It powers in-page voice and video calls, screen sharing, and peer-to-peer file transfer — it's running whether or not you've installed anything. The trouble is how it negotiates a direct connection between two devices: to find the shortest path, the browser uses the ICE (Interactive Connectivity Establishment) framework to gather a list of candidate addresses. That list includes your LAN-private IP and, critically, your real public IP as reflected back by a STUN server (most commonly Google's stun.l.google.com:19302).

Here's the dangerous part: those candidate probes travel over UDP, while many proxies and VPNs only capture the browser's TCP/HTTP traffic. So a site sees your HTTP requests arriving from the proxy IP, but a few lines of JavaScript on that same page can pull your real public IP — the one that went out directly, bypassing the tunnel. This isn't an exploit; it's WebRTC's default behavior. Any web page can instantiate an RTCPeerConnection and read both addresses without you ever noticing.

For developers, cross-border e-commerce sellers running multiple accounts, and VPN/proxy users, the implication is blunt: you think swapping your IP made you anonymous, but an anti-fraud system already has your true public IP at the front end. Line it up against the proxy IP and the mismatch gives you away. The detector at the top of this page runs that exact ICE-gathering flow inside your own browser, compares the candidates against your current exit IP, and tells you whether you're actually leaking.

To read a leak result you first need to tell the candidate types apart. A host candidate is an address on the machine's own network interface — usually a private LAN IP like 192.168.x.x or 10.x.x.x. Modern browsers (Chrome, Firefox, Safari) replace it by default with a random .local hostname via mDNS (e.g. a1b2c3d4.local), so a string of .local addresses is not cause for panic — that's the browser shielding your internal topology. But note: mDNS only masks the private IP. It does nothing for your public IP.

The candidate that actually betrays you is srflx (server-reflexive) — that is precisely your public IP as seen from the outside by the STUN server. If this address differs from your proxy exit IP, that is a genuine real-IP leak, and an anti-fraud system can use it to pin your true location. The third type, relay, comes from a TURN relay server, is uncommon in ordinary browsing, and doesn't directly expose your real IP.

So the verdict logic is clean: only .local (mDNS) means no leak; an srflx that equals your proxy exit means safe; an srflx showing a public address different from your exit means leak. There's also a sneaky case: you route only an IPv4 proxy, but WebRTC offers your real IPv6 address as a candidate too. Many people get caught in this dual-stack blind spot. The detector lists the IPv4 and IPv6 families separately precisely to catch that extra exposure.

Different proxying methods vary enormously in how well they contain a WebRTC leak — and this is where most people are mistaken. SOCKS5 proxies and WebRTC mix poorly almost by design: Chrome long ago removed support for routing WebRTC traffic over SOCKS5, and WebRTC's media probing leans heavily on UDP, which browsers usually treat as TCP-only for SOCKS5 — so the UDP probes go straight out, bypassing the proxy. Setting a bare SOCKS5 proxy in your browser will, in practice, still leak your real IP via WebRTC unless you separately disable it.

A full-tunnel VPN that captures the entire interface (including UDP) can, in theory, carry the srflx candidate inside the tunnel — but only if there's no leak window. Many VPNs leak UDP through the physical interface during a reconnect, or whenever the 'block non-VPN traffic' kill switch isn't enabled. The reliable move is to turn on that kill switch so every scrap of out-of-tunnel UDP is dropped.

Anti-detect / anti-association browsers common in cross-border e-commerce and multi-account work (AdsPower, Octo, and the like) take a different path: they rewrite WebRTC behavior at the engine level so pages see the proxy IP rather than nothing — effectively forging an srflx consistent with the proxy, wired together with matching timezone, language, and IP geolocation into a self-consistent fingerprint. This is the relatively most robust option for multi-account scenarios, but only if you verify it actually works — a misconfiguration leaks all the same, so test every new profile.

The strongest defense isn't a single layer — it's layered hardening. (1) Chrome/Edge: the engine has no about:config, so the reliable route is a reputable WebRTC-control extension (setting WebRtcIPHandling to disable_non_proxied_udp, i.e. WebRTC only over the proxy tunnel), or the equivalent browser policy in a managed environment. (2) Firefox: go to about:config; setting media.peerconnection.enabled to false fully disables WebRTC; if you want to keep calls but stop leaks, set media.peerconnection.ice.proxy_only to true to force ICE through the proxy and kill bare UDP. (3) Safari (macOS) ships mDNS for partial LAN protection, and Brave blocks WebRTC leaks by default, so both are lower-maintenance.

Mind one trade-off: fully disabling WebRTC breaks anything that depends on it — Google Meet, web-based Tencent Meeting, Discord voice, and similar. If you live in web meetings, prefer 'proxy-only' (proxy_only / disable_non_proxied_udp) over a blanket kill: you keep the feature and still plug the hole.

After any change, re-test — don't go by feel. The WebRTC detector at the top of this page runs RTCPeerConnection entirely in your local browser, gathers ICE candidates, and compares them against your current exit IP. Unlike tools such as ping0, IPOK does not POST the captured candidates back to a server, keeps no IPv4↔IPv6 cross-referencing logs, and tests only when you click. We also don't log the IP you query. Change a setting, re-test, and repeat until the result shows only .local or an srflx that exactly matches your proxy exit — that's when you're genuinely covered.