The Browser Feature That Leaks Your Real Address
imagine a hotel guest asking the front desk to forward every letter, so nobody outside learns which room is theirs. then imagine the guest making a video call and, to improve the connection, handing the caller a list of every door and window that might lead to the room. the forwarding service still works.
that is the shape of a WebRTC leak. a VPN or proxy may carry ordinary web traffic through a different address, while a browser feature built for live calls goes looking for more direct network paths. the feature is not malicious and the VPN is not necessarily broken. two systems are doing exactly what they were designed to do, and privacy falls into the space between them.
the call that wants the shortest path
WebRTC is the machinery browsers use for real-time voice, video, and data. the name means web real-time communication, but the important word is real-time. a normal page can tolerate a request taking a winding route through a server. a conversation cannot hide delay so easily. even a small pause makes people speak over one another and turns a call into an awkward relay.
so WebRTC tries to connect two browsers as directly as the networks allow. instead of sending every word and frame through the website’s own machine, the two ends may exchange data peer to peer. that saves server capacity and often cuts delay. it also creates a hard problem: each browser has to learn how the other browser can actually be reached.
why an address is difficult to know
the address a device sees inside a home is usually not the address the wider internet sees. a laptop may know itself as something like 192.168.1.20, a private address meaningful only behind the local router. the router presents a public address to the outside world and translates connections for every phone, television, and computer behind it. this translation is called NAT.
that arrangement is useful because many devices can share one public address. it is troublesome for a direct call because a browser cannot simply announce its private address to a stranger across the internet. that route ends at the walls of the local network. nor can it always trust that it knows the public address, because the router owns that address and performs the translation.
a peer-to-peer system therefore needs to collect possibilities. it needs the local door, the public entrance, and sometimes a relay that can carry the call when neither direct route works. WebRTC calls those possibilities ICE candidates. ICE, or interactive connectivity establishment, is the process of gathering possible paths and testing which pair can pass traffic.
the mirror on the public internet
one way a browser discovers its public-facing address is by asking a STUN server. STUN is best pictured as a mirror placed outside the building. the browser sends it a small request, and the server replies with the address and port from which that request appeared to arrive. the browser now knows what the outside world sees.
this is legitimate plumbing. without that mirror, two devices behind routers would often have no useful directions to exchange. candidate gathering may also find addresses assigned to local network interfaces, plus relay addresses supplied by TURN servers when a direct connection cannot be established. together they give the call several routes to try rather than one fragile guess.
the privacy problem is that addresses are not incidental debris here. discovering them is the feature. WebRTC was designed to learn network topology and describe reachable paths to another peer. before browsers tightened the rules, that description could include a local address and a public address that ordinary browsing had carefully kept out of view.
a call does not have to happen
the unsettling part is how little ceremony candidate gathering once required. a page could create the browser object used to prepare a peer connection, ask it to begin negotiation, and listen as candidates appeared. no camera image needed to be captured. no microphone needed to switch on. no second person needed to answer, and no visible call needed to exist.
from the user’s side, the page could look still. underneath, the browser was solving the networking problem it had been handed. as it learned possible routes, page code could read the resulting candidates and send those observations back like any other browser data. permission prompts for camera and microphone did not necessarily protect this stage because learning how to route a connection is separate from capturing sound or video.
that distinction explains why the leak felt like a trick. people reasonably associated WebRTC with granting access to a camera. the revealing action happened earlier, in connection setup, where the browser was only inspecting its own network interfaces and consulting an outside mirror. nothing was being recorded, yet something identifying could still be exposed.
how the tunnel gets sidestepped
a VPN usually creates a virtual network interface and arranges for traffic to leave through an encrypted tunnel. websites then see the VPN server’s public address rather than the address assigned by the visitor’s internet provider. a browser proxy can be narrower still, handling supported web requests without controlling every kind of network traffic the browser can originate.
WebRTC complicates both arrangements because candidate gathering asks the operating system about available interfaces and may send STUN requests using routes chosen outside the ordinary HTTP proxy path. depending on the browser, operating system, VPN design, and routing rules, a candidate may reveal an address belonging to the underlying connection. the page sees the tunnel’s address during normal requests and a different address inside WebRTC’s candidate machinery.
this does not mean every WebRTC session defeats every VPN. a well-integrated VPN can route the relevant UDP traffic through its tunnel, suppress access to physical interfaces, or provide only the tunnel’s address to the browser. some networks also block the direct paths WebRTC prefers. the honest description is conditional: the side route exists, and whether it exposes anything depends on which layer actually controls it.
why websites cared
for privacy, the mismatch is a hole. for a platform defending itself, the same mismatch is evidence. if a visitor arrives through one address while the browser quietly reports a candidate associated with another network, the two stories do not agree. fraud and abuse systems can treat that disagreement as one signal that a proxy, VPN, unusual network stack, or misconfigured device sits in the middle.
the signal was attractive because it came from a different layer than the visible web request. changing the address on that request did not always change what peer-connection setup could observe. a site did not need to place a call; it could compare the network facts made available during candidate gathering with the facts at its server.
what browsers changed
browsers did not leave the original exposure untouched. one major change was mDNS candidate obfuscation. instead of giving page code a raw private address such as the one assigned by a home router, the browser can place a temporary name in the candidate. mDNS, or multicast DNS, lets a nearby peer resolve that name on the local network without handing the page the underlying number directly.
this closes an especially invasive view into the local network. a raw private address could reveal network structure and provide a stable-looking detail across visits, even though it was not usually reachable from the public internet. an obfuscated name preserves enough local discovery for compatible peers while making the address less useful to scripts collecting identity signals.
browsers have also narrowed candidate exposure and tied some information more closely to permission or active media use. permission is not a complete answer, because a real call still needs a route after access is granted. browser policy cannot repair routing below the browser either, so no single toggle permanently settles every application and VPN combination.
where leaks still survive
the clearest remaining risk appears when direct UDP traffic is allowed to leave outside the intended tunnel. a STUN server then sees the underlying public address and the browser may expose a corresponding candidate during an allowed connection flow. split-tunnel VPN configurations make this possible by design: some traffic is protected, while selected traffic uses the ordinary network.
relay-only communication can avoid offering a direct path, because both peers talk through a TURN relay rather than to each other. the trade-off is the very thing WebRTC was built to reduce: extra distance, extra delay, and a server that must carry all the traffic. privacy and performance are pulling on opposite ends of the same cable.
the sibling leak, not the same leak
WebRTC leaks are sometimes folded together with DNS leaks because both can reveal something outside a VPN tunnel. they are siblings, not twins. a DNS leak exposes the names a device is looking up through the wrong resolver or route. a WebRTC leak exposes candidate network addresses while preparing possible peer-to-peer paths.
the address behind the address
the feature at the center of this story was never built to unmask people. it was built to make a browser call feel immediate, to find a path through routers that were designed to resist unsolicited incoming connections. STUN tells a browser how it appears from outside. ICE collects that answer alongside other possible paths. peer-to-peer communication then chooses the route most likely to work.
modern browsers have made that silent request less revealing, especially by masking local addresses and limiting when candidate details appear. VPNs have become better at capturing the traffic too. but the underlying tension has not disappeared. direct communication requires exchanging directions, and every direction disclosed is another fact about the road a device is standing on.
that is the honest version of the WebRTC leak. it is neither proof that VPNs are useless nor an ancient bug that no longer matters. it is a boundary failure between routing layers, partly repaired, still dependent on browser policy, permissions, application design, and the tunnel underneath. the forwarding desk can hide the room only while every message uses the desk. the moment a feature starts searching for a shorter path, privacy depends on which doors the browser is still willing to name.