What Are WebRTC Leaks and How to Prevent Them

WebRTC (Web Real-Time Communication) is a set of browser APIs and network protocols that let two browsers exchange audio, video, and arbitrary data directly, peer to peer, without a plugin or a download. It is a W3C Recommendation (WebRTC 1.0, January 2021) paired with an IETF protocol suite (RFC 8825 gives the overview). Every video call in Google Meet, every voice channel in Discord, and WhatsApp Web all ride on it.

The useful part and the leaky part are the same mechanism. For two peers to talk directly, each one has to advertise the network addresses where the other can reach it. Your home router, corporate NAT, and mobile carrier all sit between your device and the open internet, so the browser has to do some detective work to figure out which of your addresses are actually reachable. That discovery step is where a real IP escapes.

A WebRTC leak, also called a WebRTC IP leak, happens when that address-discovery process hands your real IP to the page instead of, or alongside, your proxy IP. The page reads the addresses from JavaScript through the RTCPeerConnection object. No dialog appears, no camera or microphone is involved, and the values are available the moment the page loads.

This is a different problem from a DNS leak or a header leak. Your IP address is the network identity you are usually trying to hide when you put a proxy in front of your traffic, and WebRTC exposes it below the layer the proxy controls. A proxy or an anonymous proxy rewrites what the HTTP request carries. WebRTC does not send an HTTP request at all for its connectivity checks, so there is nothing for the proxy to rewrite.

To connect two peers, WebRTC runs ICE (Interactive Connectivity Establishment, RFC 8445). ICE collects a list of candidate addresses, tests them, and picks a pair that works. There are three candidate types, and each reveals something different:

• host candidates: addresses read straight off your network interfaces, including private LAN addresses like 192.168.1.20. These expose your local network topology.
• srflx (server-reflexive) candidates: your public IP as seen from outside. The browser sends a STUN binding request to a STUN server (Session Traversal Utilities for NAT, RFC 8489, default UDP port 3478). The STUN server replies with the source IP and port it observed. That observed address is your real public IP if the STUN packet left on your normal interface.
• relay candidates: an address on a TURN relay server (RFC 8656). Traffic here is routed through infrastructure rather than sent peer to peer, so it does not expose your origin.

A single candidate arrives as a text line. A server-reflexive line looks like this:

candidate:1853887674 1 udp 2122260223 203.0.113.42 51234 typ srflx raddr 0.0.0.0 rport 0

The 203.0.113.42 is the public IP, and typ srflx tells you it came back from a STUN server. If that address is your real one instead of your proxy exit, you have a leak.

One point trips people up. Since Chrome 76 (2019), Chromium browsers replace host candidates with random mDNS hostnames that end in .local, so a modern Chrome no longer hands out your private LAN IP to an untrusted page. That fixed the local-IP leak, and a lot of "WebRTC is safe now" advice stops there. It says nothing about the srflx candidate, which still carries your public IP. For a proxy user, the public IP is the whole ballgame.

Here is the structural reason a WebRTC proxy leak is so common. An HTTP or HTTPS proxy speaks TCP. Your browser opens a CONNECT tunnel to the proxy, and the proxy relays HTTP traffic. STUN connectivity checks and the WebRTC media path run over UDP, which the HTTP proxy has no mechanism to carry. So the browser sends the STUN packet over your default network route, the packet reaches the STUN server from your real IP, and the server reports it back. Your carefully configured proxy never touches it.

SOCKS5 can technically relay UDP through UDP ASSOCIATE, but browsers do not route WebRTC media through the browser's configured SOCKS proxy by default, so that path does not save you either. VPNs fix the leak more often, because a VPN captures traffic at the OS level and WebRTC packets usually follow the tunnel. They still leak when routing is split, when the VPN client leaves a second interface reachable, or when the app binds WebRTC to a physical adapter. This is one of the ways a proxy can quietly get you blocked or deanonymized: the site sees a proxy IP in the headers and a different, real IP in the WebRTC candidates, and that mismatch is a strong bot and evasion signal.

What we've found: the mismatch is worse than the exposure. A page that reads a residential-looking proxy IP from your request headers and a datacenter or home IP from your srflx candidate does not just learn your real address. It learns you are hiding one, which some detection systems weight more heavily than the raw IP. Aligning the WebRTC exit to the proxy exit beats naively disabling WebRTC, because a browser reporting zero ICE candidates is itself an unusual, trackable fingerprint. This is why serious multi-account setups spoof the WebRTC IP to match the proxy rather than switching WebRTC off.

The fastest check is a hosted tool. Load browserleaks.com/webrtc or ipleak.net with your proxy or VPN active and compare the IP shown in the WebRTC section against your proxy exit IP. If they differ, WebRTC is leaking.

To see the raw candidates yourself, paste this into any browser's DevTools console. It forces ICE gathering with a data channel, so it needs no camera or microphone permission:

// WebRTC leak check. Run in DevTools console with your proxy/VPN active.
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});

// A data channel triggers candidate gathering without media permissions.
pc.createDataChannel("leak-test");

pc.onicecandidate = ({ candidate }) => {
  if (!candidate) return; // null = gathering finished
  const line = candidate.candidate;
  const type = (line.match(/typ (\w+)/) || [])[1];
  const ip = (line.match(/(\d{1,3}(?:\.\d{1,3}){3})|([a-f0-9:]{7,})/i) || [])[0];
  console.log(type, ip, line);
};

pc.createOffer().then((o) => pc.setLocalDescription(o));

Read the output like this. A host line ending in .local is the harmless mDNS placeholder. A srflx line showing an IP that is not your proxy exit is the leak you care about. If the only address you see is your proxy IP (or you see just the .local host and a relay entry), the browser is not leaking your origin.

There is no single switch, because each browser handles WebRTC differently. The table below lists the reliable control for each. Whenever you can, prefer forcing WebRTC through the proxy or aligning its IP over a hard disable, since a fully disabled WebRTC stack is detectable.

For Firefox specifically, the two useful preferences look like this in about:config:

# Force WebRTC to use only the proxy path (keeps WebRTC working, no direct UDP)
media.peerconnection.ice.proxy_only = true

# Or disable WebRTC entirely (breaks video calls in this browser)
media.peerconnection.enabled = false

proxy_only is the safer default for most proxy users: WebRTC still works over TURN through the proxy, but it can no longer reach out on the raw interface. Setting enabled to false is the strongest option, at the cost of breaking any site that needs real-time calls.

If you run many accounts or scrape sites with serious detection, per-browser toggles do not scale, and the disable-versus-detect tradeoff bites. Antidetect browsers (Multilogin, GoLogin, AdsPower, Dolphin Anty, and similar) solve it by spoofing the WebRTC IP so the srflx candidate reports the same public IP as the proxy you assigned to that profile. The request headers and the WebRTC candidates then agree, which removes the mismatch signal entirely. Pair that with proxies at the right anonymity level and the browser stops betraying you at two layers instead of one.

For automated data collection, the cleanest fix is to not expose a client-side WebRTC surface at all. The SparkProxy Scraping API renders each target in a controlled headless Chromium on our infrastructure, so there is no local browser reaching a STUN server from your machine. You send a URL, we return the rendered HTML:

import requests

resp = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={"url": "https://www.sparkproxy.io", "render_js": "true"},
)
print(resp.text)

The same request with cURL:

curl -X GET "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io&render_js=true" \
  -H "X-API-Key: YOUR_API_KEY"

Because the browser lives server-side and the request is just an HTTP call from your code, there is no RTCPeerConnection on your device to leak from, and the exit IP presented to the target is the one the API assigns. WebRTC leak prevention becomes a non-issue rather than a per-profile chore.