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 with your proxy on, such as our proxy checker or BrowserLeaks' WebRTC test. If a public IP of the same version as the proxy's appears and it is not the proxy's, you have a leak. An address of the other IP version is usually your connection's second address, normal on a dual-stack line that has both IPv4 and IPv6. It gives you away only if your proxy carries one version and the other bypasses it.

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.