How to read a WebRTC leak test result
You open a WebRTC leak test with a proxy running and get a page of addresses: a remote IP, a local IP that looks like a random string ending in .local, a public IP, and a block of SDP text. Some of it is alarming at first sight and harmless, and the field that actually matters is easy to skim past.
This post is about reading the result. Why the leak exists in the first place, and the ways to close it, are covered in WebRTC leak prevention.
The layout of a typical test
Using browserleaks.com/webrtc as the example (labels as they appeared on 2026-10-22), the page has these blocks:
- Your Remote IP: the IPv4 and IPv6 addresses the test server saw on the HTTP request. With a proxy, this should be the proxy's exit.
- WebRTC Support Detection: whether
RTCPeerConnectionandRTCDataChannelexist. - Your WebRTC IP: a Local IP Address and a Public IP Address, both read from ICE candidates.
- Session Description: the raw SDP Log.
- Media Devices: whether camera and microphone APIs exist and what permission state they are in.
The one comparison that decides it
Compare Public IP Address under WebRTC with Remote IP at the top of the page.
- Same address: WebRTC's path to the STUN server came out of the same exit as your web traffic. No public IP leak.
- Different address, and it is yours: the STUN request left your machine outside the proxy and the server saw your real IP. This is the leak people mean.
- Empty: no server reflexive candidate came back. Either UDP to the STUN server was blocked or the browser was configured not to gather it. Your real IP is not exposed, but a browser that never produces a public candidate is unusual in its own way, which the prevention post discusses.
The local IP: usually not what it looks like
A Local IP Address like 3f2a9c1e-7b4d-4e0a-9a51-2c6d8e1f0b37.local is not your address. Chromium-based browsers replace host candidates with a random mDNS name when the page has no camera or microphone permission, so a page cannot read your LAN address for free.
A private address such as 192.168.1.23 or 10.0.0.5 in that field means the obfuscation is off, or the page was granted media permission. It does not reveal who you are on the internet, but it adds entropy, and the next section shows how it links profiles.
A public address in the local field happens when the machine has a public IP directly on an interface, common on servers. That is a leak of the host's address even if the public candidate is clean.
The IPv6 case
Look at both halves of Remote IP. A proxy that only carries IPv4 leaves the IPv6 field empty or showing something else, while WebRTC can gather an IPv6 candidate from your ISP. A result where the IPv4 matches the proxy and an IPv6 address from your provider appears anywhere in the WebRTC section is a leak, even though the headline public IP looks correct.
Reading the SDP log
The SDP log lists candidates as lines like:
a=candidate:842163049 1 udp 1677729535 203.0.113.7 54321 typ srflx raddr 0.0.0.0 rport 0
The fields that matter: the transport (udp or tcp), the address and port, and the typ. host is a local interface (or an mDNS name), srflx is what a STUN server saw, and relay is a TURN server's address. The summary fields show one address per type; the log shows all of them, so check every IP in it against your proxy exit.
Comparing results across profiles
One test answers whether one profile leaks. If you run several identities on one machine, run it in each and line the results up, because the question changes from "does it leak" to "do these look like the same person".
| Field | Should differ between profiles | Should match within one profile, run to run |
|---|---|---|
| Public IP | yes, one exit per identity | yes, unless the proxy rotates |
| Local IP (mDNS name) | yes, it is random | no, a new name per session is normal |
| Local IP (private address) | ideally hidden; if shown, it links them | yes |
| Media Devices support and permissions | not necessarily | yes |
Two patterns deserve attention. A public IP that is present in one run and empty in the next means the STUN path is unreliable through that proxy, so the profile alternates between two different-looking browsers. And a private LAN address that is identical across every profile is the same machine announcing itself under several names, even when every public IP is different.
Where a leak test answers more than you need
If you use a system-wide VPN that tunnels all traffic, UDP included, the test will usually show the VPN address everywhere and you can stop there. No antidetect browser adds anything for that case.
Run the test where it counts
Run it inside the profile you will use, with the proxy you will use, and run it twice: once on page load and once after the page has been open for a minute, since ICE gathering can return candidates late. Compare every address in the SDP log with the remote IP. Then check the rest of the identity with the consistency checklist, and see residential vs datacenter proxies for why the exit itself matters as much as whether it leaks.
Try it on the free tier.
Unlimited local profiles, no credit card. Check it against the detectors yourself.