WebRTC is the browser technology behind in-tab video calls and screen sharing — and one of its ordinary jobs, discovering your own public IP address, can expose that address to a page even while a VPN hides it everywhere else.
Why WebRTC needs to know your IP at all
To set up a direct peer-to-peer connection — the kind that makes a video call low-latency instead of routing through a server — your browser needs to tell the other side which addresses it can be reached at. Before that handshake happens, the browser typically contacts a STUN server, a lightweight service whose only job is to tell a client "here's the public address I can see you connecting from." That address then becomes a candidate the browser can offer for the connection.
Where the leak comes in
That discovery step happens inside the browser's own networking stack, independent of whatever proxy or VPN your regular traffic is using. Historically, some VPN configurations only redirected standard web traffic and left WebRTC's STUN requests to go out over the normal network path — meaning a page could learn your real public IP through WebRTC even though every other request from that same tab appeared to come from the VPN's exit address.
What counts as a leak — and what doesn't
Not every address WebRTC surfaces is a problem. Modern browsers gather several address types:
- Host candidates — your local network address (like
192.168.1.x). Not public, not a leak. - Server-reflexive candidates — the public address a STUN server observed. This is the one that matters: if it matches an address your VPN doesn't route through, it's your real IP escaping the tunnel.
- Relay candidates — an address on a TURN relay server, used as a fallback. Not your own address.
Many current browsers also mask host candidates behind a randomized .local hostname (mDNS) specifically so a page can't read your local network layout directly — that's a privacy improvement, not something to worry about.
Why it matters in practice
The risk isn't WebRTC itself misbehaving — it's the assumption that "my VPN is on" means every avenue for a site to learn your IP is closed. A page doesn't need your cooperation to run this discovery step; it happens automatically whenever WebRTC is available, which is by default in most browsers.
Test your own setup with the WebRTC Leak Test — see How to Run a WebRTC Leak Test for the walkthrough and how to interpret each candidate type.
FAQ
Does this mean I should disable WebRTC?
Not automatically — it powers real features like browser-based calling. Test first; many current VPN clients and browsers already route or block this correctly. Disabling it is a reasonable fallback if a test confirms a leak your VPN doesn't fix.
Is this a browser bug?
No — WebRTC is working as designed. The mismatch is between what the browser does (discover and offer connection addresses) and what a user might assume a VPN silently handles on its behalf.
Does incognito or private browsing prevent this?
No. Private browsing mode changes what's stored locally after the session ends; it doesn't change what a page can observe about your network during the session.