WebRTC leaks explained: how your real IP can slip past a VPN

What WebRTC is doing behind your back

WebRTC powers voice, video, and file sharing directly in the browser, with no plugins. To connect two devices, it gathers ICE candidates: the set of network paths your device could use, including local IP addresses, public IPv6 addresses, and reflexive addresses learned from a STUN server.

That gathering step is the leak. Any website can ask your browser to collect ICE candidates using plain JavaScript — no permission prompt, no visible indicator. If your VPN client does not block or route that traffic, the page learns network details your VPN was supposed to hide.

What can actually leak

What a page learns depends on your browser and network. Modern browsers increasingly mask local addresses with mDNS hostnames, which is good — but public IPv6 addresses and STUN-derived addresses can still reveal your ISP and rough location.

The honest way to think about it is in tiers: mDNS-only results mean you are protected at the browser layer, while visible public addresses mean something in your setup needs attention.

• mDNS hostnames only — protected: the browser is masking local addresses.
• Local IPv4/IPv6 addresses visible — mixed: your LAN layout is exposed to every site you visit.
• Public or STUN-derived addresses outside your VPN range — at risk: your real location may be visible.

How to check in 30 seconds

Run the WebRTC leak test on this site, first with your VPN off and then with it on. Save both results and compare: the candidate lists should be identical, and any public address should belong to your VPN provider.

If the addresses differ between runs, your VPN is not covering WebRTC traffic. The fix is usually a VPN client setting (often called WebRTC blocking or leak protection) or a browser extension that disables non-proxied WebRTC — followed by a re-test to confirm.