ProxyNestHow to fix a WebRTC leak in Chrome when using a proxy
WebRTC powers video calls and peer-to-peer features in the browser. To connect peers directly, it asks a STUN server “what is my public address?” over UDP. HTTP proxies do not carry UDP, so that question goes out over your normal connection — and any website can run it in JavaScript and read your real IP, even though its pages loaded through the proxy.
Test for a leak
A proper leak test compares three things: your real IP, the IP websites see for normal requests, and the addresses WebRTC exposes. If WebRTC shows an address that is not the proxy’s, you are leaking. ProxyNest’s leak test runs all three in one click; the WebRTC part runs in a normal web page because Chrome’s WebRTC policy does not apply to extension pages.
Fix it: Chrome’s WebRTC IP handling policy
Chrome has a built-in setting that extensions can change (chrome.privacy.network.webRTCIPHandlingPolicy):
| Policy | Effect |
|---|---|
default | WebRTC may use any network path — leaks with a proxy. |
default_public_interface_only | Hides local network addresses, but the public IP can still leak. |
disable_non_proxied_udp | WebRTC only connects through the proxy (TCP). No leak. Some video calls may fall back to slower relays or fail. |
In ProxyNest choose Protect under Leak test & WebRTC; run the test again to confirm “WebRTC does not reveal another public IP”.
ProxyNest pastes any proxy list, logs in automatically and checks every proxy’s IP, location and speed — free for up to 3 proxies.
Add ProxyNest to Chrome
Other things that can give you away
- DNS: with HTTP and SOCKS5 proxies Chrome lets the proxy resolve host names, so DNS normally goes through the proxy too.
- Time zone and language: they don’t reveal your IP, but they can contradict it. See proxy time zone mismatch.
- A dead proxy: some tools silently fall back to a direct connection. ProxyNest does not — pages just stop loading.