Why a correctly configured proxy still leaks your real IP over WebRTC

A proxy is configured correctly. Every HTTP request goes out through the right exit IP, timezone matches, DNS resolves through the tunnel. A site still reads the real public IP address in two lines of JavaScript, before any of the HTTP-layer checks even run. WebRTC does not use the HTTP or SOCKS proxy path at all.

Why WebRTC sits outside the proxy

A browser's HTTP proxy setting governs HTTP and HTTPS traffic. WebRTC is a separate subsystem built for real-time audio, video, and data, and it establishes its media path using ICE (Interactive Connectivity Establishment), negotiating over UDP directly between peers, or between a peer and a STUN or TURN server. Chromium does not route that UDP traffic through an HTTP or SOCKS proxy configured at the browser level. The proxy setting was never designed to cover it. A page does not need to load an image or call an API to get your real address. It only needs to open an RTCPeerConnection.

The three candidate types, and what each one reveals

ICE gathers a list of candidates, each a possible way to reach your machine:

• host candidates are addresses on your own network interfaces, typically private ranges like 192.168.x.x or 10.x.x.x. These reveal local network topology and can hint at how many devices sit behind the same router.
• srflx candidates (server reflexive) come from a STUN request: your browser asks a public STUN server, commonly something like stun.l.google.com:19302, what address the request appears to come from. That UDP packet leaves the machine directly rather than through the configured proxy, so the answer is your real public IP, not the proxy's.
• relay candidates come from a TURN server acting as a relay. TURN is built for real-time apps where a direct path is impossible, not for browsing, so it is rarely part of a general proxy setup.

The srflx candidate is the one that defeats an otherwise correct proxy. It requires no server cooperation, no comparison against a fingerprint database, just a UDP round trip the proxy never touches.

How to test it yourself

Open devtools console on any page and run:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] })
pc.createDataChannel('')
pc.onicecandidate = e => e.candidate && console.log(e.candidate.candidate)
pc.createOffer().then(o => pc.setLocalDescription(o))

The logged candidate lines include a type (host, srflx, or relay) and an address. If the srflx line shows an IP different from your proxy's exit IP, the leak is confirmed. Public tools like browserleaks.com/webrtc run the same check without the console.

Why disabling WebRTC is not a clean fix

The common fix is a browser extension that blocks WebRTC entirely, or a flag that disables the API. Either removes the leak, and either also removes a real capability that the overwhelming majority of genuine Chrome installs have. A browser that answers zero ICE candidates on every site, forever, is not a normal browser. It is a machine-like tell in its own right, and on some detection systems a completely absent WebRTC surface is more unusual than a correctly leaking one, since real users occasionally use video calls or voice chat built on the same API. This is the same coherence problem covered in our fingerprint consistency work: removing a signal does not close a gap, it moves it, and often makes it more visible.

What correct handling looks like

The sound fix routes WebRTC's UDP path through the same exit as everything else, so the srflx candidate resolves to the same IP as the HTTP traffic, rather than removing the candidate. That generally means forcing ICE gathering through a TURN relay bound to the same proxy exit, or restricting candidate gathering to the interface the proxy tunnel actually uses. The browser keeps a working WebRTC surface, and every candidate it reports agrees with the declared IP, instead of trading a leak for an anomaly.

Where a free approach is the right call

To confirm whether your current setup leaks, browserleaks.com/webrtc and ipleak.net are free and sufficient. No paid tool is needed to diagnose this. If you are browsing manually rather than automating anything, and do not care about looking like an automated profile, Firefox's media.peerconnection.enabled flag in about:config is a reasonable free fix for a single personal session. The tradeoff only matters once coherence across a fleet of automated profiles is what gets scored, a different problem than one person wanting privacy on one machine.

Being honest about what we have actually measured

In a detection run we published, STUN resolution failed outright through one proxy type rather than silently leaking or silently succeeding. No srflx candidate appeared for that session at all. That is a different failure mode than a leak, worth understanding on its own terms rather than presented as a clean pass, since a missing candidate is itself a signal some systems can key on. The dated results are in our detection run from August 2026.

Verify rather than assume

Run the console snippet above against your own setup before trusting any claim about WebRTC handling, ours included. Compare the srflx address against the exit IP your HTTP traffic actually uses, and treat a mismatch as a proxy-binding problem, not a JavaScript one.

For the layer above this one, see how anti-bot systems work, and for the proxy side of identity coherence, see residential vs datacenter proxies.