WebRTC Leaks and Proxies

What is a WebRTC leak?

WebRTC is the browser technology behind video calls, voice chat and peer-to-peer data in web apps. To connect peers directly, WebRTC discovers your network addresses using STUN servers, often over UDP. Because HTTP proxies don't carry UDP, and because WebRTC can gather addresses outside the proxy, a website's JavaScript can sometimes learn your real public IP (and local network addresses) even though your web traffic goes through a proxy.

That's a WebRTC leak. It undermines the main purpose of a proxy and creates an obvious inconsistency: page requests come from the proxy IP, while WebRTC reveals a different IP.

Why it matters

• Privacy: your real IP is exposed.
• Account safety: platforms can link accounts that share the same real IP behind different proxies.
• Detection: mismatch between proxy IP and WebRTC IP is a strong signal that a proxy is in use. See browser fingerprinting and proxies.

How to test

Visit a WebRTC leak-test page in the browser configured with your proxy. If it shows your real public IP, you have a leak. Also check local IP exposure.

How to prevent WebRTC leaks

Chrome and Chromium-based browsers

• Use an extension that restricts WebRTC's IP handling policy (several privacy extensions do this).
• In automation, launch with a policy flag such as:

--force-webrtc-ip-handling-policy=disable_non_proxied_udp

This prevents WebRTC from using non-proxied UDP, so it can't reveal your real IP via that route.

Firefox

• In about:config, set media.peerconnection.enabled to false to disable WebRTC entirely (breaks video calling sites), or
• Use settings such as media.peerconnection.ice.default_address_only and media.peerconnection.ice.proxy_only to restrict which addresses are exposed.

Antidetect browsers

Most antidetect browsers have a WebRTC setting per profile: disable, replace with the proxy IP, or "altered" modes. Choose the option that shows the proxy's IP. See antidetect browser proxies.

Puppeteer and Playwright

Add the Chromium flag above in launch args, and verify with a leak-test page through the proxy. See Puppeteer stealth and proxies.

Trade-offs

Disabling WebRTC entirely can itself be a fingerprinting signal, since most real browsers have it enabled. Restricting it to proxied routes, or replacing exposed addresses with the proxy IP, is often a better balance.

Understanding what WebRTC exposes

WebRTC gathers "ICE candidates", addresses that a peer could use to connect to you:

• Host candidates: local network addresses (for example 192.168.x.x). Modern browsers often obfuscate these with mDNS names.
• Server-reflexive candidates: your public IP as seen by a STUN server, discovered over UDP.
• Relay candidates: addresses on TURN servers.

The leak risk comes mainly from server-reflexive candidates gathered outside the proxy.

WebRTC policies in Chromium

Set via launch flags in automation, enterprise policies for managed browsers, or extensions for personal browsers.

Testing in automation

const browser = await puppeteer.launch({
  args: ['--proxy-server=http://gate.example.com:7777', '--force-webrtc-ip-handling-policy=disable_non_proxied_udp'],
});
const page = await browser.newPage();
await page.authenticate({ username: 'USER', password: 'PASS' });
await page.goto('https://example-webrtc-leak-test.invalid'); // use a real leak test page

Inspect the page or capture a screenshot to confirm only the proxy IP appears. See Puppeteer stealth and proxies.

WebRTC and account linking

Platforms can use WebRTC-exposed addresses as one more signal to link accounts. If several "separate" profiles reveal the same real public IP through WebRTC, they're effectively linked regardless of proxies. Protect every profile. See antidetect browser proxies.

WebRTC leak quick-fix table

After any fix, re-run a leak test through the proxy to confirm. See how to check if a proxy works.

WebRTC on phones and in native apps

Most WebRTC advice is about desktop browsers, but phones are where many account setups actually run, and the picture there is different:

• Wi-Fi proxy settings don't cover WebRTC media. Voice and video calls use UDP, which an HTTP proxy configured in Wi-Fi settings doesn't carry. Calls can connect directly and reveal the phone's real network.
• Native apps with calling or live features often use their own networking stacks and don't consult the proxy setting at all.
• Mobile browsers offer fewer WebRTC controls than desktop ones, and extensions are limited or unavailable.

What works better on mobile:

1. Put the whole device on the target network, for example a phone that genuinely uses the mobile carrier or a dedicated mobile proxy at the network level, rather than a Wi-Fi proxy setting.
2. Use a VPN-style proxy app that captures all traffic, if you must proxy from a phone, and check it handles UDP or blocks it.
3. Test from the device itself with a WebRTC leak page, and in the apps you rely on, rather than assuming.

For background on how browsers expose addresses, see the policies and candidate types above, and the IETF's guidance on WebRTC IP address handling (RFC 8828). For setting up proxies on phones, see proxy setup on iPhone and Android; for carrier-based IPs, mobile proxies.

Key takeaways

• WebRTC can reveal your real public IP through STUN requests that bypass HTTP proxies.
• Leaks undermine privacy, link accounts and signal proxy use.
• In Chromium automation, --force-webrtc-ip-handling-policy=disable_non_proxied_udp is the standard fix.
• Firefox preferences and antidetect browser settings offer similar protection.
• Disabling WebRTC entirely can itself be a fingerprint; restricting it to proxied routes is often better. See browser fingerprinting and proxies.

FAQ

Do VPNs prevent WebRTC leaks?

A full-device VPN usually does, because all traffic, including WebRTC, goes through the tunnel. Per-app proxies often don't.

Does SOCKS5 prevent WebRTC leaks?

Not by itself. Browser WebRTC behaviour still needs to be restricted.