You have a VPN on, you check your IP, and it shows the proxy's address. Everything looks fine. Yet a website may still know your real IP — through a browser feature called WebRTC.
This is not a theoretical risk. Many people assume that connecting to a proxy settles the matter, and miss that the browser leaks their real address through a separate channel. This article explains how it happens and how to check for it.
What WebRTC is and why it leaks
WebRTC (Web Real-Time Communication) is a set of features built into browsers that lets web pages do audio and video calls, screen sharing and peer-to-peer file transfer without any plugin. The browser-based video meetings and voice chats you have used are mostly built on it.
The problem lies in how it works.
To establish a direct connection between two browsers, WebRTC needs to know the network addresses of both — not just the public IP, but local network addresses too. To find them it uses a mechanism called STUN, actively querying an external server to ask "what is my real address?", then handing the result to the other side.
Here is the crux: that query bypasses ordinary proxy settings. Many VPNs and proxies only handle the browser's HTTP traffic, while WebRTC's address discovery takes a different path. The result is that a page sees your proxy address over HTTP but obtains your real address through WebRTC.
To the website, that is two addresses at once. And the contradiction itself is a strong risk signal.
Why this is worse than using no proxy
Intuitively, leaking your real IP seems to mean at most that "the proxy was pointless". The reality is subtler.
If you use no proxy at all, the website sees a single real address, everything is consistent, and nothing looks unusual.
When a WebRTC leak happens, the website sees this: a proxy address from location A, alongside an exposed real address from location B. That state — one person with two addresses in two different places — is exactly what risk systems flag, because it strongly implies the user is deliberately hiding their location.
In other words, a leaking proxy can draw more attention than no proxy at all.
What information leaks
Specifically, WebRTC can expose:
Your public IP address — your real outward address, even while a proxy runs. This is the most damaging item.
Local network addresses — addresses like 192.168.x.x or 10.x.x.x. Harmless-looking in isolation, but they reveal your network structure and can form part of a device fingerprint.
IPv6 addresses — if your network supports IPv6 while your proxy only handles IPv4, your real IPv6 address may be exposed directly. This is a very common oversight.
How to check
Open the environment check and the page lists the addresses WebRTC detected. The test is simple:
Compare the public address WebRTC exposes against the IP shown at the top of the page.
- They match: no leak, or you were not using a proxy anyway
- They differ: there is a leak — the address WebRTC exposed is your real one
If you are not using any proxy, a match is normal and nothing to worry about. The value of this check is mainly in verifying, when you do use a proxy, that it has genuinely taken over every channel.
How to fix it
In descending order of effectiveness:
Option 1: use a leak-protected proxy tool. Better proxy clients handle WebRTC leaks actively, usually with a setting for it. This is the least troublesome route — if your tool supports it, prefer it.
Option 2: disable WebRTC at the browser level.
- Firefox: enter
about:configin the address bar and setmedia.peerconnection.enabledtofalse - Chrome / Edge: no built-in switch; you need an extension (such as one of the WebRTC leak-prevention add-ons) to control it
Option 3: control it granularly with an extension. Some privacy extensions let you keep WebRTC working while blocking it from exposing your real IP, balancing usability.
Know the cost: fully disabling WebRTC breaks sites that depend on it — browser-based video meetings, voice calls and some online collaboration tools may stop working. If you use these often, option 1 or 3 fits better.
Common questions
Does it leak on mobile too? Yes. Mobile browsers support WebRTC on the same principle. But the WebView embedded in mobile apps may behave differently and needs separate testing.
Do I still need to worry with Tor? The Tor Browser restricts WebRTC strictly by default, so leak risk is low. But if you manually configure a Tor proxy inside an ordinary browser, you still need to check.
Do I need to check every time? It is worth re-testing after updating your browser, switching proxy tools or changing network configuration. If your setup is stable, there is no need to check repeatedly.
Does disabling WebRTC make me completely safe? No. WebRTC is only one channel that leaks your real address. A timezone mismatch, DNS leaks, browser fingerprinting and other signals expose you just as well and deserve attention too.
More than WebRTC
WebRTC leaks are worth covering on their own because they are stealthy — your IP check looks fine while you are exposed on another channel. But it is only one part of an environment check.
A complete self-check should also cover: whether timezone agrees with IP, whether browser language matches the location, and whether any virtual-machine or automation traces are present. If any one of these signals fails to line up, a "correct proxy address" loses its meaning.
The environment check runs all of these in one pass, entirely in your browser, uploading nothing. If you want to understand the type and risk score of the IP itself first, see this article.
Summary
WebRTC is a useful feature, but its mechanism of actively discovering your real address to establish peer-to-peer connections causes leaks when you use a proxy. The test is a single line: compare the address WebRTC exposes against the address you believe you have.
A leaking proxy draws more attention than no proxy, because "two addresses in two places" is itself an anomaly. Check periodically, especially after changing tools or networks.