What is a WebRTC leak?

A WebRTC leak occurs when the WebRTC API, a browser technology for real-time communication, reveals a device's true local and public IP addresses even when a VPN or proxy is configured to hide them. The leak happens because WebRTC uses STUN/TURN protocols to establish peer-to-peer connections, and these protocols request the device's actual network interfaces directly, bypassing the proxy or VPN tunnel.

How does a WebRTC leak link multiple accounts?

If multiple accounts are operated from the same machine behind different proxies, a WebRTC leak reveals that all accounts share the same underlying public IP address. The platform sees Account A connecting through Proxy A and Account B connecting through Proxy B, but WebRTC reveals that both originate from the same real IP. The platform links the accounts despite the proxy isolation.

Can I prevent WebRTC leaks?

Yes, by disabling WebRTC in the browser settings or using browser extensions that block WebRTC. However, disabling WebRTC is itself a detectable signal. Real users do not disable WebRTC, so blocking it flags the browser as privacy-configured, which is a soft detection signal. Anti-detect browsers typically disable WebRTC by default, but the absence of WebRTC is one more signal that contributes to the overall anomaly profile.

How Do WebRTC Leaks Expose Multi-Account Operations?

WebRTC leaks expose multi-account operations by revealing a device's real public IP address through the WebRTC API, bypassing proxy and VPN configurations and linking accounts that were intended to appear as if they originated from different network locations. A WebRTC leak is one of the most common and damaging isolation failures in multi-account setups because it reveals the single most identifying network signal — the true IP address — across all accounts sharing the same machine.

What Is WebRTC And Why Does It Leak?

WebRTC (Web Real-Time Communication) is a browser API that enables peer-to-peer audio, video, and data communication without plugins. It is used by Google Meet, Discord web, Zoom web, and many other real-time communication applications. To establish peer-to-peer connections, WebRTC uses STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers to discover the device's network interfaces.

The STUN protocol asks the device: "What are your IP addresses?" The device responds with its local IP addresses (e.g., 192.168.x.x) and its public IP address as seen by the STUN server. This query operates at the network layer and does not route through the browser's configured proxy or VPN. A browser configured to use Proxy A for HTTP traffic still responds to WebRTC STUN queries with the device's real public IP address.

The EFF Cover Your Tracks project does not directly test WebRTC, but the broader browser fingerprinting research community recognizes WebRTC as a critical IP leak vector that undermines proxy-based identity separation.

How Does The Leak Link Accounts?

Consider a multi-account setup running five TikTok accounts through a single machine. Each account is configured with a different residential proxy — Account A connects through 203.0.113.1, Account B through 203.0.113.2, and so on. The proxy separation should make the accounts appear to originate from different locations.

When TikTok's web interface loads, it runs a WebRTC check. Each of the five browser profiles uses WebRTC to discover its network interfaces. All five report the same real public IP address because they all share the same underlying internet connection. TikTok sees five accounts connecting from five different proxy IPs but all reporting the same WebRTC-leaked real IP. The link is instant and unambiguous.

GeeTest's device fingerprinting research includes network-level signals as part of the standard fingerprinting surface. IP addresses, proxy detection, routing characteristics, and ASN analysis are all standard components. WebRTC operates at exactly the network layer that fingerprinting systems inspect.

Can WebRTC Leaks Be Prevented?

Yes, by disabling WebRTC. Most modern anti-detect browsers disable WebRTC by default or offer configuration options to block it. Browser extensions like uBlock Origin can also block WebRTC. Firefox has a media.peerconnection.enabled setting that can be set to false in about:config.

But disabling WebRTC creates a different problem: it is a detectable signal. Real browsers have WebRTC enabled because real users use video calling, voice chat, and other real-time communication features. A browser with WebRTC disabled is statistically anomalous. The platform may not know why WebRTC is disabled, but it knows that legitimate users do not disable it.

The anomaly contributes to the overall risk score. One anomalous signal — disabled WebRTC — may not trigger enforcement. Ten anomalous signals across the fingerprint profile — disabled WebRTC, spoofed canvas, manufactured WebGL, missing hardware sensors — collectively trigger it. WebRTC prevention solves the IP leak but creates a fingerprint anomaly that contributes to detection through a different vector.

How Does This Affect Multi-Account Operations?

WebRTC leaks expose a fundamental tension in proxy-based multi-account setups: the infrastructure shares a single network connection. Proxy separation at the browser layer is effective only if the browser never reveals the underlying connection. WebRTC is one of several mechanisms that do exactly that. Even when WebRTC is blocked, the underlying network connection is still shared, and other leak vectors — DNS leaks, IPv6 leaks, network timing analysis — can expose it.

The only reliable way to achieve genuine network isolation is to give each account its own network connection. This is what real device infrastructure provides: each device has its own cellular connection or dedicated Wi-Fi, so there is no shared underlying connection to leak.

How Conbersa Prevents WebRTC Leaks

We built Conbersa on real devices with individual cellular connections per device. WebRTC on Device A reports Device A's cellular IP. WebRTC on Device B reports Device B's cellular IP. There is no shared underlying connection to leak and no proxy to bypass. Network isolation is genuine rather than spoofed, so WebRTC leaks are not a vulnerability because the information WebRTC reveals is already the correct, distinct network identity for each account.