WebRTC lets browsers make direct audio, video and data connections. To find a path between two peers, the browser gathers candidate addresses, including asking a STUN server over UDP "what is my public address?". A page can start that process with a few lines of JavaScript and read the candidates. Because the STUN request goes over UDP, and an HTTP proxy only carries your web traffic, it can go straight out of your real connection and reveal your real IP.

Why it matters

For a proxy user in a browser, this is the leak that matters most. A site sees your proxy's IP on the page request and your home or office IP in the WebRTC candidates, and now knows both, and that they belong to the same visitor. For account work in several browser profiles, it links every profile to one connection. Modern browsers hide local network addresses behind mDNS names, but that does not cover the public address.

How to test

Open a WebRTC leak test page, such as BrowserLeaks' WebRTC test, with your proxy on. If any public IP other than the proxy's appears, you have a leak.

How to fix it

  • Firefox: set media.peerconnection.enabled to false in about:config, if you do not need WebRTC.
  • Chrome and Edge: the WebRtcIPHandling policy set to disable_non_proxied_udp stops WebRTC from using UDP outside the proxy. Extensions that set the same option exist.
  • Antidetect browsers: most have a per-profile WebRTC mode that disables it or substitutes the proxy's IP; check it is on, as the AdsPower guide does.

Common confusion

WebRTC leaks affect browsers only. A script using Python requests or curl has no WebRTC stack and cannot leak this way. A DNS leak is a different problem with a different fix.