WebRTC leaks: why your real address can show even behind a proxy
WebRTC exists so browsers can talk to each other directly for calls and screen sharing. To do that they need to discover the addresses they can be reached on, and the discovery process is what a "WebRTC leak" refers to.
ICE candidates in one paragraph
When a page creates an RTCPeerConnection and starts an offer, the browser gathers candidates: ways another peer could reach it. A host candidate is a local interface address. A server-reflexive (srflx) candidate is the public address a STUN server saw the request arrive from. A relay candidate is a TURN server's address. Each candidate is handed to the page in a text line that contains the address, which is how a script can read it, without any call ever being made.
Where the leak is
The srflx candidate is the one that matters. To get it, the browser sends a small UDP packet to a STUN server, which replies with the address it saw. If your HTTP traffic goes through a proxy but your UDP traffic does not, the STUN server sees your real connection, and the page now has an address that disagrees with the one the web server saw. That disagreement is the classic leak. A diagnostic page can show it by comparing the two.
Note what is and is not happening. No media is captured. No microphone or camera permission is involved. The packet goes to whichever STUN server the page named, so that server, like any server you contact, sees your address.
What browsers changed
Host candidates used to expose private LAN addresses such as 192.168.1.23, which were useful for fingerprinting a home network. Modern browsers replace them with randomly generated mDNS names ending in .local, so a page sees an opaque name rather than an address. A diagnostic that reports "masked by the browser" is describing those. Firefox and Brave also offer settings that stop candidate gathering outside the proxy, and some extensions block WebRTC entirely.
Proxy-safe configurations
Three approaches work, with different costs. Disabling WebRTC prevents the leak and breaks every site that needs it. Forcing WebRTC to use only the proxy's route (the "proxy-safe" mode in some browsers) keeps calls working when the proxy supports UDP or TURN, and otherwise yields no public candidate at all. Letting WebRTC behave normally is correct only when the proxy carries all traffic, as a system-level VPN usually does.
Which one is right depends on the job. For an isolated browser profile that must appear to be in one place, the rule is simple: the address WebRTC exposes must be the same address the web server sees, or none at all. Anything else is a contradiction a site can notice without any special tooling.
Reading the result
A diagnostic shows the candidates it observed within a few seconds and compares any public one with the address the page was reached from. "None exposed" with some masked candidates is a normal, healthy result for a browser that keeps WebRTC inside the proxy. A public address that differs from the page's address is the thing to fix.