WebRTC leaks
WebRTC can show a site your own IP address while every page loads through the proxy. The gateway cannot stop it; a setting in the browser or the profile can.
Why WebRTC goes around the proxy
WebRTC is the part of the browser that runs calls, video and peer-to-peer data. Before a call it collects candidate addresses: the address of each network interface, and the public address that a STUN server reports back after the browser sends it a UDP packet. In most browsers any page can start this with a few lines of JavaScript, without a permission prompt, and read the result.
A proxy set in the browser carries its web requests, which are TCP. The STUN packets are UDP and leave through your own connection, so the public address WebRTC finds is yours, not the exit's. The IETF rules for WebRTC (RFC 8828) make routing it through the proxy an optional, stricter mode; by default browsers send it directly.
Local addresses are mostly safe now: current browsers hide them behind a random name ending in .local. The public address is the one that leaks.
What the gateway can and cannot do
Port 7000 is an HTTP proxy and carries no UDP. Port 7001 can relay UDP (SOCKS5 and UDP), but regular browsers such as Chrome, Firefox, Edge and Safari never send WebRTC through SOCKS5: their SOCKS support is TCP only. For them, changing the port, the product or the exit does not change what WebRTC shows; the fix is a setting in the browser. Some antidetect browsers can send UDP through a SOCKS5 proxy, and the UDP line of each setup guide says whether yours does.
Check for a leak
- Open the IP checker in the same browser or profile that uses the proxy.
- Find the WebRTC leak test card and compare IP sites see with WebRTC public IP.
- The same address, or none, is fine. A different public address, usually your own, is a leak, and the checker marks it as one. Local IP: Hidden (mDNS) is the normal case.
The same page runs a DNS leak test and checks IPv6, which can expose you in similar ways. Run it on every new profile before it signs in to anything.
Where to change it
Every browser keeps the setting in a different place, and some have none. The setup guides give the steps:
| Browser or tool | What it offers | Steps |
|---|---|---|
| Antidetect browsers | A WebRTC mode in each profile: one that reports the proxy's IP, or off | The app's guide, such as AdsPower or Dolphin Anty; the others are in setup guides |
| Chrome and Edge | No switch in the settings. An extension, or a policy on a managed computer, keeps WebRTC behind the proxy | Chrome, Edge, FoxyProxy |
| Brave and Opera | A WebRTC setting of their own | Brave, Opera |
| Firefox | Preferences in about:config, or an extension | Firefox, FoxyProxy |
| Safari | No WebRTC setting | Safari |
| Chromium under Playwright, Puppeteer or Selenium | The launch flag --force-webrtc-ip-handling-policy=disable_non_proxied_udp, the same policy as in managed Chrome | Proxy setup in the Playwright, Puppeteer and Selenium guides |
What each choice costs
Turning WebRTC off stops video calls, voice chat and screen sharing in that profile, and a site can see that WebRTC is missing. A mode that reports the proxy's IP keeps WebRTC present and consistent with the exit. The TCP-only policy (disable_non_proxied_udp) keeps calls working on services that offer a relay over TCP, usually with more delay than over UDP.
For calls that really run through the proxy, you need an app that sends UDP through SOCKS5 UDP ASSOCIATE on port 7001, with a sticky login so that TCP and UDP share one exit. Tunnel apps such as ProxyCap and Clash Verge can do this for the whole computer.
Our guide to browser profiles and proxies covers the other checks a profile needs before use, for your own accounts and accounts you manage with their owners' access.
Questions
No. The leak comes from the browser, not from the exit, and it is the same with any proxy product.
Not necessarily. Mobile carriers and some home networks use several public addresses, and the checker rates an address from the same network and country as low risk. An address from your own ISP is the leak.