Is Your Real Address Visible Behind the Proxy
A proxy changes the address your browser uses to reach sites. WebRTC is a separate channel for calls and video, and it can connect directly, bypassing the proxy. When it does, the site gets your real address from JavaScript, in a second and without asking.
Open this page in the profile you're checking and click the button.
This one needs a third-party server, and we say so plainly. On the fingerprint check, everything was computed in your browser. Here that's not possible: the browser only learns its own external address from a STUN server — that's exactly the leak being tested. The request goes to stun.cloudflare.com and stun.l.google.com; they see exactly what any site with calling features would see. We don't save the result.
Results
What the Browser Found
| What It Is | Address |
|---|
How to Read the Result
There's only one check here, but it's the one that matters: the address the STUN server sees you from, against the address the rest of your traffic exits from.
They match — WebRTC takes the same path as everything else and gives away nothing new. They differ — the proxy is bypassed: the site learns your real address no matter how you've configured the proxy in the profile.
We show your local network addresses on a separate line. By default Chrome hides them behind random names like ….local — that's its own built-in protection, and it works. On their own these addresses don't give you away: 192.168.1.5 belongs to millions of machines. But they tell the site how your network is built, and that's one more line in the fingerprint set than you need.
Why a Command-Line Flag Doesn't Fix This
It's easy to waste time here, so let's say it plainly: only setting the WebRTC policy in the browser itself fixes the leak. A command-line flag at Chrome launch does not close it — for this part, Chrome simply doesn't listen to it. We've verified this on live profiles.
The setting exists and is built in, but reaching it by hand in every profile is work nobody is going to repeat a hundred times in a row.
That's why in Morfiade it turns on by itself once a profile has a proxy set: if there's a proxy, the address is meant to be hidden, and leaving WebRTC free to go around it would defeat the point. There's no separate checkbox to hunt for.
What to Do If the Check Shows a Leak
- A profile without a proxy. Then everything's fine: there's nothing to hide, the address is yours anyway. This only becomes a leak once a proxy is involved.
- There's a proxy, but the addresses don't match. That means the WebRTC policy isn't set for this profile. In Morfiade, it's enough to give the profile a proxy — the rest happens on its own.
- A WebRTC-blocking extension. It closes the leak, but bluntly: some sites with calls and video stop working, and the fact that "WebRTC is switched off entirely" is itself a signal — and a fairly rare one.
What This Check Doesn't Show
DNS leaks. That's a different channel: name lookups can go around the proxy even when the traffic itself goes through it. We don't measure that here, and we won't pretend we do.
Whether the country matches the time zone and language. That's covered on the fingerprint check — the same page has the three checks that most often trigger a captcha.
One more time: on this page, "no leak" means exactly one thing — WebRTC didn't report an address different from your exit address. It isn't an overall anonymity score, and we don't draw up percentages.
Browser fingerprint check · What this program is · Open the bot