WebRTC Leak: The Bug That Exposes Your Real IP Even With a Proxy On

Why a good proxy does not stop a WebRTC leak

A proxy configured in a browser has a narrow job: take the HTTP and HTTPS requests the browser makes and send them somewhere else first. It does that job well. The misunderstanding is assuming that job covers everything the browser does on a network, and it does not.

WebRTC is the standard that lets two browsers exchange audio, video and data directly, without a server in the middle relaying every packet. Video calls that run in a tab, live support widgets, browser-based conferencing — all of it is WebRTC. Direct connection is the entire point of the technology, and a direct connection requires each side to know where it can actually be reached. So before any call starts, WebRTC goes looking for the addresses that describe where you are on the network.

That discovery process does not ask the browser proxy setting for permission, and typically it runs over UDP, which most HTTP proxies do not carry at all. The result is two parallel realities in one browser: your page traffic arrives at the site from the proxy, while WebRTC has independently worked out and published the address of the machine actually running the browser. Both are true at the same time, and a site that reads both sees the contradiction immediately.

What is WebRTC and why does it expose your real IP?

Two computers behind home routers cannot simply address each other. Each one sees a private address on its own network and has no idea what the world sees. WebRTC solves this with a procedure called ICE, which collects every plausible way of reaching you and offers the list to the other side, so both can pick a path that works.

The list has three kinds of entry. Host candidates are the addresses of your own network interfaces, seen from inside. Server reflexive candidates are what a STUN server on the internet reports back after you contact it — effectively the browser asking a stranger "what address did my packet arrive from?" and being told its public IP. Relay candidates are addresses on a TURN server that agrees to forward traffic on your behalf.

The second kind is where the leak lives. A STUN query is a small UDP exchange with a public server, and it answers with the address the world sees for the connection the browser actually used — the real one, not the proxy. That answer then goes into the candidate list, and the candidate list is readable from JavaScript. No exploit is involved. The page simply reads a value the browser has already worked out and made available.

The two IPs at stake, and the one that is already solved

Most leak tests report two things, and they deserve very different levels of concern.

The local IP is your address on the home or office network, the private range address. This used to leak freely and was genuinely useful for tracking, because it told a site something about the shape of your network. Chrome closed it in version 76 by replacing private addresses with a randomly generated mDNS hostname — a string of hex characters ending in .local. Seeing that hostname in a test today is not a leak. It is the mitigation working.

The public IP is the one that matters, and it is the one still exposed by the STUN step above. If a leak test shows a public IP that is not your proxy, that is the finding. Everything else on the page is secondary.

How the browser reaches the network around the proxy

It is worth being concrete, because the mechanism explains every mitigation that follows. When ICE gathering starts, the browser enumerates its network interfaces and tries to contact the configured STUN servers. Those attempts are UDP datagrams. An HTTP proxy speaks HTTP; it has no mechanism to carry a raw UDP datagram, so the browser does not even try to send it there. A SOCKS5 proxy can carry UDP in principle, but that capability is often not enabled by the provider and not used by the browser in this path.

So the datagram leaves through the default route — your actual connection. The STUN server answers honestly. The browser records the answer as a valid candidate, because from its point of view it just discovered a working path to the internet, which is exactly what it was asked to find.

Chrome exposes a policy for this that is worth knowing by name, because it is the vocabulary every tool borrows: WebRtcIPHandling. Its values run from default, which uses every interface available, through default_public_interface_only, which stops private interfaces from being offered, to disable_non_proxied_udp, which forces WebRTC to use UDP through a SOCKS proxy or fall back to TCP. That last value is the strongest option when you are deliberately forcing traffic through a proxy — and it is the ancestor of the fifth mode in the next section.

The five ways to handle WebRTC, and what each one really does

Anti-detect tools tend to present the same five options with slightly different names. Here is what sits behind each, described by mechanism rather than by label.

The distinction people miss is between block and replace. Blocking removes the capability; replacing keeps the capability and sanitises what it reports. From a detection point of view these are opposite decisions. A profile that claims to be Chrome and cannot construct an RTCPeerConnection has contradicted itself, and that contradiction is as cheap to detect as reading the user agent — which is the same class of problem we describe in the piece on canvas and WebGL noise: the defence that removes a signal often creates a louder one.

Which mode to use in each situation

• Work account on a marketplace, an ad platform or a social network. Replace. The site will never need a peer connection, and the profile keeps a complete, ordinary-looking browser API surface.
• A profile that has to make or receive calls. Forward, with a TURN server you control or subscribe to. This is the only mode where media both works and stays behind your relay.
• A hardened profile where no site will ever use media. Block is defensible, as long as you accept that absence of the API is itself a signal.
• A profile with no proxy at all, on your own connection. Real. If there is nothing to hide, hiding it creates an anomaly for no benefit.
• SOCKS5 in place and you want the strictest posture. Disable UDP, so nothing attempts a direct datagram path around the proxy.

It also helps to be honest about what a leak actually costs, because the niche tends to describe it as instant catastrophe and it usually is not. A leaked public IP does not by itself get an account closed. What it does is far quieter: it hands the platform a durable link between accounts that were supposed to be unrelated. Three profiles on three different proxies that all reported the same home address once are three accounts the platform can group, and that grouping does not expire when you fix the setting. The damage is retroactive and permanent, which is exactly why this is worth testing before an operation scales rather than after something goes wrong.

Test it now and read your own result

This takes under a minute and needs nothing installed. Open the WebRTC leak test in the browser or profile you actually use for work, with the proxy on, and compare four lines.

• Public IP reported by the page request. This should be your proxy. If it is not, the problem is upstream of WebRTC and you should fix that first with the IP and proxy check.
• Public IP discovered by WebRTC. This is the finding. Same as the line above means no leak. Different, and specifically your home or office address, means a leak.
• Local address. A hex string ending in .local is the expected, healthy result on current Chrome. A private range address means the mDNS mitigation is not in play.
• Whether RTCPeerConnection exists at all. If the test reports the API missing while your profile claims to be Chrome, you are not leaking — you are announcing that something is modifying the browser.

Run it twice: once in your normal browser with the proxy on, once in the profile you plan to use. The comparison is more instructive than either result alone, because it separates two questions people usually merge: whether your proxy is routing traffic at all, and whether your browser is leaking around it. A normal browser with a proxy configured typically passes the first and fails the second, and seeing both results next to each other makes the distinction concrete in a way no explanation does. For a full sweep of every other signal in the same sitting, our sixty-second leak test walkthrough covers the rest of the layers.

How AlterAntiX handles WebRTC per profile

WebRTC policy in AlterAntiX is a field on the profile, chosen from the five modes above and applied when the profile launches, so two profiles open at the same time can be under different policies. New profiles are created in replace mode, which is the default because it is the right answer for the majority of work accounts, not because it is the strictest.

Replace mode does two things together. It empties the ICE server list, so the browser never asks a STUN server what your public address is. And it intercepts the session description and the candidate stream, rewriting any real address it finds to 0.0.0.0 before the page can read it — with loopback and the unspecified address left alone, since rewriting those would itself be an anomaly. Forward mode instead filters the server list down to TURN entries only, and disable-UDP mode forces the connection into relay-only transport.

It is worth being clear about the boundary. Handling WebRTC correctly closes one specific hole. It does nothing for the browser fingerprint, and nothing for the TLS handshake that goes out before any of this — a profile can pass a WebRTC test perfectly and still be identified by a JA3 or JA4 that contradicts its user agent. The layers are independent, which is why we treat them as one job rather than one setting. AlterAntiX is a free desktop download for Windows and Linux; there is no macOS build yet.