Home → Learn → WebRTC leaks

WebRTC leaks

A WebRTC leak is the reason a proxy can be working perfectly and still lose you the account. Every HTTP request goes out through the proxy exactly as configured, and meanwhile a few lines of JavaScript ask the browser for its network candidates and get back the real address the proxy was supposed to hide. The usual advice is to turn WebRTC off. That advice is worse than the problem.

Why the leak exists at all

WebRTC is how browsers do video calls and peer-to-peer connections without a plugin. To connect two people directly it has to work out how each of them is reachable, so it gathers ICE candidates — a list of addresses the browser might be contacted on.

That list is not a secret. Any page can create an RTCPeerConnection, read the candidates and the session description, and pull addresses straight out of them. It needs no permission and shows no prompt, because from WebRTC's point of view nothing unusual is happening — this is the feature working.

The second row is the leak people mean. The page now holds two addresses for one visitor: the proxy's, from your HTTP requests, and yours, from WebRTC. That is not an unusual fingerprint — it is a direct contradiction, in the same family as an IP and a clock that disagree.

Why "just disable WebRTC" is the wrong fix

Every guide says it, most extensions do it, and several antidetect browsers ship "Disabled" as the default. It does stop the leak. It also does something else.

Real Chrome always has RTCPeerConnection. A browser that claims to be Chrome 141 on Windows and has no WebRTC at all is not a private browser — it is a browser that has had something done to it. Checking takes one line:

typeof RTCPeerConnection === 'undefined'

You have swapped a leak for a signature. Worse, it is a rarer signature than the one you started with: plenty of ordinary users are behind a VPN with a visible reflexive candidate, and almost none are running a Chrome with the API deleted.

What coherence looks like instead

The goal is not silence, it is agreement. WebRTC should answer — and its answer should match everything else the page already knows about you.

• Strip the private host addresses. Your LAN layout is nobody's business and contributes nothing but identifying detail.
• Keep the mDNS .local candidates. This is the part most setups get wrong. Modern Chrome emits these by default, so removing them is itself anomalous — you want to look like Chrome, and Chrome has them.
• Rewrite the public reflexive address to the proxy's exit IP. Then WebRTC and the HTTP layer tell the same story, which is what a genuine user behind that proxy would actually produce.
• Close the hole at the network layer too. A JavaScript filter can be bypassed by anything that reaches the network stack directly, so Chromium's own WebRTC IP-handling policy should be set to forbid non-proxied UDP whenever a proxy is in use.

How Parallel handles it

Each profile filters ICE candidates as they are generated: private and link-local addresses are removed, the mDNS .local candidates modern Chrome emits are kept, and any public reflexive address is rewritten to the proxy's exit IP so WebRTC stays consistent with the proxy.

That JavaScript filtering is backed at the network layer rather than trusted on its own. When a profile uses a proxy, Chromium is launched with its WebRTC IP-handling policy set to disallow UDP that would bypass the proxy; without one, it is bound to the default route only, so a machine with several interfaces or a VPN does not expose the others. Belt and braces, because a page that reaches the network stack directly never sees the JavaScript filter.

Both other options exist for people who want them. Disabled removes RTCPeerConnection entirely — the most conservative setting, matching what other tools do by default, and conspicuous for the reason above. Real leaves WebRTC completely untouched, leaks included, for when you are testing something and want the genuine behaviour. Neither is the default, and the default is the coherent one.

Check yours

Open our fingerprint test through whatever proxy setup you use now and compare the WebRTC addresses against your proxy's exit IP. If a public address appears that is not your proxy, that is the leak. If RTCPeerConnection is missing entirely, that is the other problem.

Related reading

• Proxy timezone mismatch — the same contradiction, different signal.
• Residential vs datacenter proxies — which to use per profile.
• Browser fingerprinting, explained — why coherence beats hiding, across every signal.