WebRTC Leak — Why Most Anti-Detects Still Get It Wrong
WebRTC reveals your real IP unless properly tunneled. How the leak happens and what 'proper handling' means in 2026.
WebRTC was designed to enable peer-to-peer connections (video calls, file transfer). To do that, it must learn your real IP — and tell the peer. Every modern fingerprinting library picks up that "real IP" automatically.
How the leak happens
- Browser opens an RTCPeerConnection
- ICE gathering starts — the browser sends UDP packets to STUN servers to discover its external IP
- STUN returns the IP visible to the server — your real public IP, regardless of any HTTP proxy
- The fingerprinting script reads the candidate list from the JS API
- Real IP is now known to the page
This works because most "proxies" tunnel TCP only. WebRTC uses UDP for STUN. The UDP traffic egresses from your real IP.
The four wrong fixes
- Disable WebRTC — flag (real users don't disable)
- Block STUN responses — flag (real users return candidates)
- Return localhost as the candidate — flag (impossible value)
- Return random IPs — flag (not in the proxy's ASN)
The right fix is to tunnel UDP so STUN sees the proxy IP, not the real IP. See our deep dive on UDP support in anti-detect.
How to test
- Open the profile
- Load browserleaks.com/webrtc
- Public IP should match the proxy IP
- Local IPs should be hidden or randomised (no .local mDNS)
- No "private network" IPs leaked
If your real IP appears, your anti-detect is misconfigured or your proxy doesn't support UDP. Switch.
Top engines that handle this correctly
- Afina — native SOCKS5-UDP + WireGuard
- Linken Sphere 2 — WireGuard
- Octo Browser — WireGuard
Everything else either blocks or partial-tunnels.
Bottom line
WebRTC leak is the single most common reason a "good" anti-detect profile gets flagged. Solve it once, at the proxy + browser level, and forget about it. Don't trust per-page workarounds.