WebRTC IP leakage is a network privacy vulnerability where the WebRTC protocol — designed for peer-to-peer voice, video, and data communication in browsers — bypasses VPN tunnels and proxy configurations to expose the device's real, ISP-assigned public IP address through STUN server queries, allowing social media platforms to unmask the true network location of multi-account operations even when every account appears to connect from different proxy IP addresses. Unlike cookie-based tracking or browser fingerprinting, WebRTC leakage operates at the network transport layer and cannot be controlled through browser privacy settings or standard proxy configurations, making it one of the most persistent identity signals in a multi-account operator's traffic profile.
How Does WebRTC STUN Protocol Expose the Real IP Address?
WebRTC relies on the Session Traversal Utilities for NAT (STUN) protocol to discover a device's public IP address and establish peer-to-peer connections. When a browser or app initiates a WebRTC session, it sends a STUN binding request to a STUN server — by default, Google's public STUN servers are among the most commonly used. The STUN server responds with the public IP address and port that it observed from the incoming request, which is the device's real public IP address as seen by the internet.
The critical vulnerability is that this STUN request travels using the device's local network interface and UDP transport, which often bypasses VPN and proxy routing rules. Most VPN configurations route TCP traffic through the encrypted tunnel but leave UDP traffic — including STUN requests — on the local network stack. Similarly, SOCKS5 and HTTP proxies are designed for TCP traffic and do not intercept UDP packets. The result is that while the website sees the proxy or VPN IP address, the STUN server sees the device's real IP address — and the platform can collect both.
The IETF RFC 8825, which defines WebRTC's IP address handling, describes the privacy risk explicitly. According to Fingerprint's analysis of WebRTC fingerprinting, WebRTC data contributes meaningful entropy to device fingerprints because the local and public IP address information exposed through WebRTC APIs is stable, hardware-tied, and difficult to fully spoof at the browser level.
How Do Platforms Use WebRTC Leakage to Link Accounts?
Platforms embed WebRTC-based detection scripts in their web applications that execute STUN queries during every session. The script collects two IP addresses: the HTTP-visible IP address (the proxy or VPN endpoint) and the STUN-visible IP address (the device's real ISP IP). When these two IP addresses differ — and they frequently do in multi-account operations — the platform records both.
The detection logic then identifies two account-linking scenarios. First, multiple accounts that connect through different proxy IP addresses but report the same real IP address via WebRTC are linked as operating from a single physical network connection. Second, an account whose real IP address through WebRTC is a datacenter IP address (from a cloud server or VPS) is flagged as automated infrastructure rather than a consumer internet connection — because legitimate mobile users connect through residential ISPs, not cloud providers.
The EFF's research on browser uniqueness found that network-level identifiers including WebRTC-exposed IP addresses contribute to the overall identifiability of browsing sessions, and combining WebRTC data with other fingerprinting signals creates a composite identity that is extremely difficult to fully anonymize (source).
How Do Native Mobile Apps Handle the WebRTC Leak Equivalent?
While WebRTC is primarily a browser technology, native mobile apps present an equivalent — and often more powerful — network identity leak vector. Mobile apps access networking through the operating system's native sockets and can query every network interface on the device simultaneously. An app like TikTok or Instagram can enumerate the device's Wi-Fi IP address, mobile data IP address, and any VPN tunnel IP address — all from a single session.
More importantly, mobile apps can access the Wi-Fi network's BSSID (the MAC address of the Wi-Fi access point), the carrier network's MCC/MNC codes, and cellular tower identifiers. These values are not privacy-locked on Android (without specific permission flags) and are accessible through system APIs that the app uses legitimately for features like location services and connection quality monitoring. A device connecting through a proxy for its API traffic but broadcasting the same Wi-Fi BSSID and carrier tower IDs across multiple accounts creates a linking signal that no proxy configuration can mask.
GeeTest's device fingerprinting research highlights that mobile platforms increasingly use network interface enumeration as a core anti-fraud signal because attackers have difficulty controlling every network identifier simultaneously across multiple accounts (source).
How Conbersa Prevents Network Identity Leakage
Conbersa runs every account on a dedicated physical smartphone with its own carrier SIM card and independent mobile network connection. Each device connects through its own cellular data interface with a unique IP address assigned by the carrier, and there is no shared network infrastructure, no shared Wi-Fi BSSID, and no shared public IP address across accounts. The network identity of Account A on Device 1 is genuinely independent from the network identity of Account B on Device 2 because the two devices are on entirely separate physical network connections.
When platforms perform WebRTC STUN lookups or enumerate network interfaces on Conbersa-managed devices, every device reports a unique, carrier-assigned residential IP address from its own SIM — not a datacenter or proxy IP. There is no VPN tunnel to leak through because every device connects directly to the internet through its own cellular radio. The real-device, real-network architecture eliminates WebRTC leakage, network interface enumeration, and every other network-layer identification vector by making each account's network identity genuinely distinct at the physical infrastructure level.