Home/Blog/WebRTC Leaks

Proxy Technology

WebRTC Leaks and Mobile Proxies Explained

WebRTC can hand a web page your real IP even when every HTTP request is routed through a proxy. Here's how STUN and ICE gather that address, why a leaked IP that doesn't match your exit is an instant flag, and the browser modes that keep the two aligned.

9 min read·Last updated: July 2026

Quick Answer

A WebRTC leak happens when the browser's real-time API gathers ICE candidates - including your public IP from a STUN server over UDP - outside the proxied path, exposing your real address. If that leaked IP differs from your proxy exit, the mismatch is a detection signal by itself. The fix is to run a WebRTC mode that reports the proxy IP, then verify it at a leak checker.

→WebRTC gathers host (local) and server-reflexive (public) candidates; the public one can be your real IP
→A WebRTC IP that differs from the exit IP is a direct contradiction, not something a fingerprint hides
→Best practice: set WebRTC to report the proxy IP, then confirm with a leak test before working

This is a neutral, technical explainer. Most antidetect guides mention WebRTC leaks in passing; this page focuses on the mechanism - how the candidate-gathering process works, what a mismatch actually reveals, and the concrete browser controls that address it. If you want the wider detection picture first, see how websites detect proxies and what an antidetect browser is.

How WebRTC gathers candidates (STUN and ICE)

WebRTC is the browser API behind real-time audio and video. To connect two peers directly, it has to work out which network paths are reachable. That negotiation is defined by ICE (Interactive Connectivity Establishment, RFC 8445), which gathers a list of candidates - possible address/port pairs the peer could be reached on.

Two candidate types matter for leaks:

Host candidates

The addresses bound to your device's local network interfaces - for example a private LAN address like 192.168.x.x. These come straight from the operating system.

Server-reflexive candidates

Your public address as seen from outside. The browser sends a STUN Binding request over UDP; the STUN server reflects back the source address it observed (the XOR-MAPPED-ADDRESS), which is your public IP.

The leak problem is where this traffic goes. Because ICE can reach a STUN server over UDP, that probe may travel outside the HTTP path your proxy controls, with no permission prompt. So a page can learn a real public IP even while the visible page traffic is fully proxied. A relayed path through a TURN server is also possible, but the server-reflexive candidate is the one that typically exposes the real address.

Why a leaked IP that differs from the exit is a flag

A page already knows the IP your connection exits from - it is the source address of the request. If WebRTC then reports a different public IP, the page is holding two addresses that should be the same and aren't. That contradiction is a signal in its own right, independent of every other fingerprint value.

This is the same principle that governs the rest of the profile: detection systems don't just read individual values, they check whether the values agree with each other. A spoofed canvas hash, a matched timezone, and a clean User-Agent do nothing if WebRTC quietly announces a real address from another network. For the broader version of this idea, see the multi-account management guide.

The reverse is also worth stating plainly: if the WebRTC public candidate matches the proxy exit, there is no contradiction to find. Consistency, not concealment, is the goal.

Browser and antidetect WebRTC modes

Chrome exposes a policy called WebRtcIPHandling (the webRTCIPHandlingPolicy in the extension API). It governs which interfaces WebRTC is allowed to use:

default

WebRTC may use any interface; can expose both local and public addresses.

default_public_and_private_interfaces

Uses the default route but can still expose a local (private) address.

default_public_interface_only

Restricts WebRTC to the public interface on the default route, hiding local addresses.

disable_non_proxied_udp

Forces WebRTC through the proxy; UDP must be proxied or WebRTC falls back, so non-proxied UDP can no longer leak.

Antidetect browsers wrap similar behaviour into named per-profile modes. The practical set is:

•Real - WebRTC reports your actual IP. Fine with no proxy; a leak the moment you add one.
•Replaced / based on the proxy IP - the WebRTC public (and often local) address is set to match the proxy on profile launch. Multilogin documents this as Altered; Octo Browser and GoLogin call it Based on IP, and set it by default.
•Manual - you type the public IP WebRTC should report. Useful for edge cases; Octo Browser notes this mode is not offered there.
•Disabled - WebRTC is turned off entirely, so nothing is gathered. Removes the leak, but the absence of a normal feature can itself be noticeable.

For a proxied workflow, the replaced/Based-on-IP mode is usually the right default: it keeps the feature present and makes the reported address match the exit. The same reasoning appears in our antidetect browser overview, where WebRTC is one of several signals a profile has to keep internally consistent.

How to test, and how to read the result

Connect through your proxy, then open a WebRTC leak checker. A real, widely used one is BrowserLeaks WebRTC, which opens an RTCPeerConnection, probes a STUN server, and lists every candidate it finds. Read the results by candidate class:

Public candidate

This should equal your proxy exit IP. If it shows your real public address, WebRTC is leaking and the mode needs changing.

Local candidate

A private address such as 192.168.x.x. These are reused by millions of routers, so on their own they are far less identifying than a leaked public IP - but many workflows still prefer to suppress them.

The single most useful check is simple: does the public candidate match the exit? If yes, there is no mismatch to detect. Re-test whenever you rotate the IP or change profiles, because a stale WebRTC value can lag a fresh exit.

Mobile contexts: match the carrier exit

WebRTC leaks are not only a desktop-browser problem. Native mobile apps that use real-time media or peer-to-peer features run the same ICE machinery and can surface a public address. In a mobile context, the address WebRTC reports should be consistent with a plausible mobile session - which means it should match the carrier exit you are actually using.

This is where the exit type does real work. A mobile proxy gives you a genuine 4G/5G carrier IP whose geolocation you can align to the profile's declared region, so the WebRTC-reported address, the timezone, and the exit all point to the same place. Carrier IPs also sit behind Carrier-Grade NAT and are shared among many real subscribers, which is a separate reason they behave differently under bot-mitigation - covered in CGNAT and mobile proxies.

The takeaway: WebRTC handling and the exit IP are one problem, not two. Set the mode to report the proxy, choose an exit whose geography matches the profile, and confirm both with a test.

A short pre-flight checklist

•Set the WebRTC mode to report the proxy IP (Altered / Based on IP), not your real one.
•Pick an exit whose geolocation matches the profile's timezone and locale.
•Open a leak checker and confirm the public candidate equals the exit IP.
•Decide whether to suppress local candidates for your use case.
•Re-test after every IP rotation or profile change.

None of this is a way to break a platform's rules; it is basic hygiene so that legitimate, proxied traffic does not contradict itself. Operate within each service's terms and applicable law.

Frequently asked questions

What is a WebRTC leak?

A WebRTC leak is when a web page reads your real IP address through the browser's WebRTC API even though your page traffic is routed through a proxy or VPN. WebRTC gathers ICE candidates, including host candidates (your local interface addresses) and server-reflexive candidates (your public IP, learned from a STUN server over UDP). Because that UDP path can operate outside the proxied HTTP connection, the address it reports can be your real one rather than the proxy exit.

Why does a WebRTC IP that differs from my proxy matter?

Detection systems can compare the IP a connection exits from against the IP that WebRTC reports. If the page loads through a proxy in one country but WebRTC reports a different, real address, that contradiction is a direct signal on its own. No amount of canvas or timezone spoofing hides it, because the two IPs simply do not agree.

Which WebRTC mode should I use with a proxy?

For a proxy workflow, the mode that replaces the WebRTC public IP with the proxy IP is usually the safest. Multilogin calls this Altered, Octo Browser and GoLogin call it Based on IP. It keeps the WebRTC-reported address consistent with the exit. Disabling WebRTC entirely also stops the leak, but a browser with no WebRTC at all can itself look unusual on sites that expect the feature, so matching is generally preferred over removing.

How do I test for a WebRTC leak?

Open a WebRTC leak checker such as BrowserLeaks (browserleaks.com/webrtc) while connected through your proxy. Look at the candidates it lists: the public candidate should match your proxy exit IP, and no candidate should reveal your real public address. Local (private) candidates like 192.168.x.x are shared by millions of routers and are far less identifying than a leaked public IP.

Does disabling WebRTC fix leaks?

Disabling WebRTC prevents the API from gathering candidates, so there is nothing to leak. The trade-off is that WebRTC is a normal browser feature used by video calls and many real sites, so its complete absence can be a fingerprinting signal in its own right. Replacing the reported IP with the proxy IP keeps the feature present while removing the mismatch.

Do WebRTC leaks matter inside mobile apps?

They can. Native apps that use real-time audio, video, or peer-to-peer features also gather ICE candidates and can surface a public address. In a mobile context, matching the carrier exit keeps the network the app sees consistent with a plausible mobile session, which is why a real 4G/5G exit and a matched WebRTC address are worth checking together.

Sources

Related Guides

Technical

How Websites Detect Proxies

The full fingerprinting and anti-bot stack

Multi-Accounting

What Is an Antidetect Browser?

Fingerprint isolation and IP consistency

Technical

CGNAT & Mobile Proxies

Why carrier IPs behave differently

Related partners & tools

Preventing a WebRTC leak is a browser setting; matching the exit is a proxy choice. These are the antidetect browsers we partner with - pair any of them with our mobile IPs.