You've connected your proxy. Your IP checker shows the right location. Everything looks clean. Then a website runs a WebRTC check, and your real IP address appears: the one your ISP assigned, the one tied to your physical location, the one you thought you'd hidden.
WebRTC is a browser technology built for speed, not privacy. It establishes direct peer-to-peer connections for things like video calls and voice chat, and to do that, it needs your real IP address. The problem is that it often collects and shares that IP before your proxy or VPN has any say in the matter. The result is a leak that bypasses every other privacy measure you've put in place, silently and by design.
This article explains exactly how that happens, how to test whether it's happening to you, and how to stop it.
What Is WebRTC?
WebRTC (Web Real-Time Communication) is an open-source framework that lets browsers communicate directly with each other, without going through a central server.
It's what powers video calls in Google Meet, voice chat in Discord, and peer-to-peer file sharing in the browser. The technology is fast, widely supported, and built into Chrome, Firefox, Safari, and Edge by default.
To set up a direct connection between two browsers, WebRTC needs to figure out their IP addresses. It does this by contacting STUN servers (Session Traversal Utilities for NAT), which respond with the public IP address the request originated from. That exchange takes place at the browser level, before any data is actually sent between participants. And here's the problem: that STUN request doesn't always go through your VPN tunnel or proxy. It takes the shortest path available, which is often your real connection.
The result is that a website running a WebRTC check can see your actual IP address, even if everything else about your session looks clean.
Why Your Proxy or VPN Doesn't Automatically Stop It
This is where a lot of people get caught out. It's a reasonable assumption that connecting to a proxy means your IP is hidden, full stop. But VPNs and proxies work by rerouting your HTTP and HTTPS traffic. WebRTC often uses UDP, a different protocol, and in many browsers, the network stack handles UDP separately from your proxy settings.
The browser is not lying to you. It's doing exactly what it was designed to do: find the most efficient path for real-time communication. The problem is that efficiency and privacy point in opposite directions here.
For most regular users, a WebRTC leak means advertisers or trackers can see where they're actually browsing from. For people managing multiple accounts, it's more serious. If you're running different profiles through different proxies but your underlying IP leaks through WebRTC on every one of them, platforms can link those accounts back to a single physical location. A consistently leaked IP is one of the most reliable signals that detection systems use.
WebRTC leaks also compound your browser fingerprint. A website doesn't need to rely on your IP alone to identify you. It can cross-reference the IP your proxy is showing against the IP WebRTC is leaking, and if those two don't match, that mismatch is itself a strong signal that something is being hidden.
How to Test for a WebRTC Leak
Testing is straightforward and free. Before changing any settings, it's worth checking where you currently stand.
BrowserLeaks is one of the most thorough options. Navigate to browserleaks.com/webrtc with your proxy or VPN active. The page will immediately display any IP addresses your browser is exposing through WebRTC, both your local network addresses and your public IP. If you see your real public IP in the results rather than your proxy IP, you have a leak.
You can also use BrowserScan or Pixelscan for broader fingerprint audits that include WebRTC checks alongside your other browser signals. Both are worth running to see the full picture, not just the IP.
A clean test result shows only your proxy IP in the public address field, or no IPs at all if WebRTC is disabled. Any result showing your real ISP-assigned IP is a failure, and you'll need to address it before continuing any sensitive work in that browser or profile.
How to Fix WebRTC leak
There isn't one universal fix, because the right approach depends on how you're working. Here are the main options.
Disable WebRTC
Depending on the kind of browser you use, you either have direct control through the browser's configurations/settings or do not. Firefox and Safari are examples of browsers that give you direct control,
Here is how to disable WebRTC in Firefox:
- Type about:config in the address bar, accept the warning, then search for media.peerconnection.enabled and set it to false. That disables WebRTC entirely.
- If you want a lighter touch, setting media.peerconnection.ice.proxy_only_if_behind_proxy to true tells the browser to only use ICE candidates that go through your proxy, though this doesn't work reliably with all proxy types.
This is how to do it in Safari:
- Enable the Develop menu through Safari's Advanced preferences,
- then go to Develop > WebRTC > Disable WebRTC.
Use an extension in Chrome-based browsers.
Chrome doesn't offer a native toggle for WebRTC. Extensions like WebRTC Network Limiter (published by Google) or uBlock Origin's advanced settings give you control over how WebRTC handles IP addresses. The more conservative setting forces WebRTC to use only the IP your VPN or proxy provides. Be selective about which extensions you install for this — stick to well-reviewed, actively maintained ones.
These browser-level fixes work if you're operating a single identity from a single browser. But they have limits. Browser updates can silently change behaviour, extensions can conflict with each other, and none of these methods gives you per-profile control. If you're working with multiple accounts or personas, you need something more precise.
The Better Solution for Multi-Account Work
If you're managing multiple browser profiles, fixing WebRTC at the browser level isn't enough. You need per-profile control because a single setting applied across all profiles doesn't help when the leak vector is at the profile level.
This is part of what Incogniton is built to solve. When you configure a proxy in a browser profile, Incogniton's systems automatically align the profile's timezone, geolocation, and WebRTC public IP with the proxy's IP. Instead of leaving WebRTC running freely against your real connection, it rewrites the IP that WebRTC reports to match the proxy. From the outside, everything is consistent: the proxy IP, the WebRTC IP, and the geolocation all point to the same place.
If automatic alignment isn't working, for example, with certain proxy types, you can set the WebRTC public IP manually in the profile's WebRTC settings or switch the profile to Disabled mode, which blocks WebRTC entirely for that profile. The choice is yours for each profile independently.
This matters because a leaked IP in one profile doesn't just expose that profile. If you're running ten accounts and nine of them have clean WebRTC but one leaks, that one can be enough for a platform to draw connections. Consistent, per-profile WebRTC control is the only way to manage this at scale.
Conclusion
WebRTC is a useful technology that happens to create a meaningful privacy problem when left unconfigured. It works at the browser level, below where most privacy tools operate, and it will happily expose your real IP address to any site that asks for it, even when your proxy or VPN is active.
The fix isn't complicated, but it does need to be deliberate. Disable WebRTC if you don't need it. Use browser settings or extensions to control it if you do. And if you're operating multiple accounts or personas, use tools that give you per-profile control over every layer of your browser identity, including WebRTC. A single consistent leak across profiles is enough to connect accounts that are supposed to be separate.
Test before you work. Fix what's leaking. Then test again.
