WebRTC leak
When a browser's real-time communication feature exposes your true IP address even though your traffic runs through a proxy.
WebRTC is the browser technology behind in-page video calls, screen sharing and peer-to-peer file transfer. To connect two browsers directly it has to discover what addresses each one can actually be reached on, and it does that by asking external STUN servers to report back what they see. That discovery is the whole feature, and it is also the leak.
The problem is that a page can ask for the results. A few lines of JavaScript create a peer connection, read the candidate addresses the browser gathered, and hand them to the site. Among those candidates is your real public address, discovered by a mechanism that never went through your proxy because it was never HTTP traffic in the first place.
That is what makes it different from every other exposure here, and worse. Your proxy is functioning perfectly at the connection layer while the browser volunteers your true address through a side channel the proxy has no visibility of and no ability to intercept. Nothing is broken. Two subsystems are simply working independently.
It also exposes more than your public address. WebRTC gathers local network addresses too, so a page can learn your internal LAN address, which is a surprisingly strong fingerprinting signal because it is stable and not something anything else reveals.
The defences are all client-side, because the problem is client-side. Disable WebRTC where you do not need it, restrict it so it does not expose local candidates, or use a browser profile configured for that. Antidetect browsers generally handle this, which is one of the concrete reasons they exist rather than merely being user-agent spoofers.
And as with a DNS leak, the only way to know is to look. Checking that your exit IP shows the right country tells you nothing about what WebRTC is reporting a layer above it.
Frequently asked questions
How do I check for a WebRTC leak?
Connect through the proxy and load any WebRTC leak test page, which creates a peer connection and displays the candidate addresses your browser produced. If your real public address appears there, you are leaking regardless of what your exit IP shows. Many such tests also display any local network address the browser exposed.
Does a proxy stop WebRTC leaks?
No, and this is the point that catches people. A proxy handles the connections you route through it, and WebRTC's address discovery is a separate mechanism talking to STUN servers outside that path. The proxy is not failing; it was never in a position to see this traffic at all. The fix has to happen in the browser.
Should I just disable WebRTC entirely?
If you never need video calls or peer-to-peer features in that browser profile, yes, and it is the simplest complete answer. If you do need them, restrict it instead so it does not expose local candidates. Keeping separate profiles, one hardened for automation and one ordinary for daily use, avoids having to choose.
Can WebRTC reveal my local network address too?
Yes, and it is one of the few things that does. Candidate gathering includes internal addresses such as those in the 192.168 range, which a page can read alongside your public one. That local address is stable and is not exposed by anything else, which makes it a useful fingerprinting signal quite apart from the privacy question.
Back to the full glossary.