Updated：2026-09

Why Does WebRTC Expose Your IP?

WebRTC is a built-in browser technology for real-time communication: video calls, screen sharing, and peer-to-peer data transfer. To connect two devices, it must first learn where each of them is — and the process of collecting addresses exposes your network information to web pages, regardless of your HTTP proxy settings. Understanding this is the basis for judging a "WebRTC leak".

ICE candidates are exchanged before the connection

Before establishing a connection, WebRTC collects candidate addresses through the ICE (Interactive Connectivity Establishment) mechanism and exchanges them with the remote peer. Candidates usually fall into three types:

• Host candidates: addresses from your local network interfaces, including private addresses such as 192.168.x.x, specific to a single device;
• Server reflexive candidates: public addresses discovered through a STUN server, that is, the exit IP seen after NAT;
• Relay candidates: addresses forwarded through a TURN relay server, normally used only when a direct connection fails.

The key point: web scripts can read these candidates before a connection is actually established. So merely opening a page in your browser can let a site — with the help of a detection script — learn your private or public addresses.

Why browsers expose these addresses

Exposure is part of the mechanism, not a bug:

• ICE collection requires enumerating local interfaces and contacting a STUN server; it is a necessary step for connection setup, and the browser cannot decide for you;
• WebRTC traffic does not go through the HTTP proxy, so proxy settings such as PAC or a system proxy barely affect it;
• Even when a VPN changes your public exit, private addresses on local interfaces (and in some cases the real public address) can still be collected.

Blurring, disabling, and real exposure

Protection methods differ greatly in effect:

• mDNS blurring: some browsers display host candidates as random .local names, hiding private addresses — but the public address obtained through server reflexive candidates may still be exposed;
• Disabling WebRTC entirely: this blocks candidate collection but also breaks real-time audio, video, and peer-to-peer features; it is a downgrade, not a fix;
• Extensions and VPN clients: some extensions only hide addresses in the UI, or intercept before candidates are exchanged; effectiveness depends on the implementation and should be verified by testing.

Because approaches vary so much, LE59’s WebRTC Leak Test tool does one thing: shows which candidate addresses your current browser exposes through WebRTC. Candidates are used only for that check and are not stored long-term. One honest caveat: a result with no candidates, or a failed STUN negotiation, does not mean you are safe — it may be caused by environment restrictions or interception, so judge the situation with multiple signals.

When should you run the test

• You use a VPN or proxy and care about whether your real exit is exposed;
• You want to find out why another party can see your private address on the same network;
• After a browser update or a new privacy extension, you want to confirm the protection actually works;
• You need to understand your current exposure surface in privacy-sensitive scenarios.

Want to see which addresses your browser exposes? Open the WebRTC Leak Test tool — view the result for that check, no login required.