You set up a proxy, open a leak test, and the HTTP address looks right. Then the WebRTC line shows something else: your home IP, an IPv6 address you have never seen, or a name ending in .local. Before you change anything, it helps to know that these three results mean three different things, and only one of them is a leak.
What a WebRTC leak test actually measures
A website normally learns your address from the connection that fetched the page. That is the HTTP IP, and it is the address a proxy or VPN is designed to change.
WebRTC works differently. To set up a peer-to-peer call, the browser gathers ICE candidates: every address it could be reached on. It asks the operating system for local interfaces, and it asks a STUN server on the internet "what address do you see me coming from?". A leak test simply creates a hidden peer connection, collects those candidates and prints them next to the HTTP IP.
| Candidate type | Where it comes from | What you see |
|---|---|---|
| Host | Your network interfaces | A private LAN address, or in Chrome an mDNS name such as 3f1e….local |
| Server-reflexive (srflx) | A STUN server's view of you | Your public IP as seen from outside, over UDP |
| Relay | A TURN server | The relay's address, only when the site provides one |
The comparison that matters is HTTP IP versus the server-reflexive candidate. Both are public addresses, both are what a website can log, and they should agree.
Three reasons the WebRTC IP differs from your HTTP IP
1. Your proxy carries TCP, WebRTC uses UDP
HTTP and HTTPS proxies only handle TCP connections. STUN requests go out over UDP, so they never enter the proxy. They leave through your real connection, and the STUN server faithfully reports your real public address. This is the classic WebRTC leak: the site sees the proxy's IP in its logs and your ISP's IP in the WebRTC candidate, and it now has two addresses to link together.
2. IPv6 goes one way, IPv4 goes another
Many home and office networks have both IPv4 and IPv6. If your proxy or VPN only routes IPv4, the browser still gathers a candidate over IPv6, and that candidate is your unmasked address. The tell: the HTTP IP is a dotted IPv4 address and the WebRTC IP is a long hexadecimal one.
3. The test is showing a local candidate, not a public one
An address like 192.168.1.24 or a name ending in .local is a host candidate. Chrome has hidden real local addresses behind mDNS names since 2019, so a .local entry tells the site nothing about where you are. Some test pages still flag it in red. It is not a leak, and there is nothing to fix.
A different address means the two paths left your machine differently. Which fix applies depends on which of the three cases you are looking at, so identify the case first.
How to check it properly
- Run the test once with the proxy off. Note the HTTP IP and the srflx candidate; they should be identical. That is your baseline.
- Turn the proxy on and run the same test again, in the same browser. Compare only the public candidates.
- If the WebRTC address is IPv6 and the HTTP address is IPv4, you are in case 2. If it is a private address or
.local, case 3. Anything else is case 1. - Repeat on the network you actually work from. Coffee-shop Wi-Fi, a phone hotspot and the office LAN behave differently.
Check your own WebRTC result
The Lab shows your HTTP IP and WebRTC candidates side by side and explains any mismatch. Nothing leaves your browser.
How to fix each case
Case 1: stop unproxied UDP
Chrome has a built-in switch for this, the WebRTC IP handling policy. Set to "disable non-proxied UDP", the browser only uses candidates that go through the proxy, which for most sites means the leak disappears and WebRTC quietly stops working. You can set it with an extension or an enterprise policy. A SOCKS5 proxy that supports UDP is the other route, but the browser will not use it for STUN on its own.
Case 2: give IPv6 the same treatment as IPv4
Either disable IPv6 on the machine while you work through the proxy, or use a proxy that carries IPv6 too. Check the result again afterwards: an IPv6 candidate that disappears is the confirmation you want.
Case 3: nothing
A .local name is the browser doing its job. Leave it alone.
Why "just turn WebRTC off" is not the full answer
Disabling WebRTC entirely closes the leak, but it also makes your browser unusual. RTCPeerConnection is present in every stock Chrome, so a page that finds it missing has learned something about you, and any site that uses WebRTC for calls or screen sharing will break. The cleaner target is a WebRTC that works and reports the same public address as HTTP.
What this means when you run more than one account
A leak is annoying for one account and dangerous for several. If five profiles each sit behind their own proxy but all leak the same home IP over WebRTC, a platform's risk system sees five accounts, five countries and one shared address. That is a stronger link than any cookie, and it survives everything you clear.
So the check is not "did the proxy work" but "does every path out of this profile agree". The public WebRTC candidate, the HTTP IP, the timezone and the language should all describe the same place.
How Mango Browser handles WebRTC
Every profile in Mango has its own WebRTC setting, with five modes: off, auto, manual, real, and disable UDP. Auto is the default. It replaces the public candidate with the exit IP of the proxy bound to that profile, so WebRTC keeps working and agrees with the HTTP address without any extension or policy work.
The proxy itself is bound per profile (HTTP, SOCKS5 or residential), and timezone, language and geolocation can follow the exit IP automatically. Run the Lab check inside a Mango profile and the WebRTC row and the IP row show the same address, which is the result every other test will see too.