About Browser IP, WebRTC & DNS Leak Check
Browser IP, WebRTC & DNS Leak Check runs four probes from this browser at once: an IPv4 request, an IPv6 request, a WebRTC candidate gathering pass, and fifty one-time DNS lookups. It then compares them, so you can see whether the address a website observes, the address WebRTC would offer a peer, and the resolver answering your queries are the ones you expected.
A tunnel is only as private as its narrowest bypass. WebRTC gathers candidate addresses through the operating system's network stack rather than the browser's HTTP path, so a peer connection can advertise an interface the tunnel was meant to hide. DNS is worse, because resolution happens before any connection exists: a query sent to the resolver your ISP handed out tells that resolver every hostname you visit, whichever exit the traffic later takes. Neither shows up as an error, which is why they have to be probed deliberately.
How to use this developer tool
- Press Start and let all four checks run in parallel; the counter shows how many of the four have finished.
- Read the IPv4 and IPv6 cards first — those are the addresses an ordinary website sees, and the baseline everything else is compared against.
- Expand the WebRTC candidate list and look at the type and scope of each candidate, not just the count.
- Watch the DNS card count up to fifty, then read the resolver list: those are the resolvers that actually queried the probe domains, with the network each belongs to.
- Change one thing — VPN on or off, a WebRTC setting, a different resolver — and run it again. The comparison between two runs is more informative than either run alone.
Worked example: a VPN with a WebRTC bypass
HTTP traffic is going through the tunnel, but the WebRTC pass has picked up a candidate from the physical interface. This is the pattern the summary looks for.
Press Start — four checks run in parallelConclusion: leak detected 4/4 complete
IPv4 available 203.0.113.45
IPv6 unavailable no public address returned
WebRTC candidates 6 · public 1 · local 1 · mDNS-masked yes
198.51.100.77 IPv4 · srflx · public
192.168.1.24 IPv4 · host · private
3f2a1c9e-...-.local IPv6 · host · masked
DNS 50/50 probes · 2 resolvers · 1840 ms
198.51.100.10 IPv4 DE · Frankfurt · Example Resolver GmbH
198.51.100.11 IPv4 DE · Frankfurt · Example Resolver GmbHTwo separate findings. The srflx candidate does not match the address HTTP presented, so WebRTC would offer a peer a different exit than your web traffic uses. Separately, 192.168.1.24 is a private LAN address — harmless to a website on its own, but it confirms WebRTC is reading interfaces directly rather than being filtered.
ICE candidate types and what each reveals
Every candidate carries a type. The type, plus whether the address is public or private, determines whether it is interesting.
| Type | What it is | What it reveals |
|---|---|---|
| host | An address bound to a local network interface | The machine's own address. Private (192.168.x.x, 10.x.x.x, fe80::) exposes your LAN layout; public is your real address regardless of any HTTP-level tunnel. |
| srflx | Server-reflexive: the public address a STUN server observed | The exit WebRTC traffic would leave from. Compare it with the HTTP address — a difference means two different paths. |
| prflx | Peer-reflexive: learned from an incoming peer check | Only appears during a live connection with a real peer. Seeing none in a standalone check is expected. |
| relay | An address on a TURN server that forwards traffic | The relay's address, not yours. Appears only when a TURN server is configured and authenticated. |
| mDNS (.local) | A random hostname substituted for a private host candidate | Nothing about your network. Browsers mask host candidates this way by default; it is a protection working, not a failure. |
Troubleshooting
Every host candidate is a .local hostname instead of an address.
Why it happens Browsers replace private host candidates with a randomised mDNS hostname by default, precisely so a page cannot read your LAN address.
Fix Nothing to fix — this is the protected state, and the card reports it as masked. Real peer connections still work because the two peers resolve those names between themselves.
WebRTC reports blocked or returns no candidates at all.
Why it happens A privacy extension or browser setting has disabled WebRTC or the peer-connection constructor, or the page is not in a secure context.
Fix Treat it as a pass — that is stronger than any comparison this tool could make. To verify WebRTC for an application you are building, use the WebRTC Support, ICE Candidate, STUN & TURN Checker.
The DNS card finishes with zero resolvers found.
Why it happens An extension, a filtering resolver, or a corporate policy blocked the probe hostnames, or the twelve-second timeout cut the requests short.
Fix Re-run without content-blocking extensions. A zero result means the probe could not complete, which is not evidence about your resolver in either direction.
The listed resolvers are in a different country from the VPN exit.
Why it happens Large public resolvers run anycast farms and forward queries between sites, so the address reaching an authoritative server is often not the one you configured. Browser-level DNS-over-HTTPS bypasses the system resolver entirely.
Fix Compare the resolver's ASN organisation against the resolver you intended to use, not its location. Matching operator with an unexpected city is normal; a different operator is the finding.
A public WebRTC candidate matches your ISP address while HTTP shows the VPN.
Why it happens The tunnel is applied at browser or application level while WebRTC reaches the physical interface, or a split-tunnelling rule excludes UDP.
Fix This is a genuine bypass. Enable the VPN client's WebRTC or full-tunnel protection, or disable WebRTC for that browser profile, then re-run and confirm the candidate is gone.
When this tool is the right choice
- Checking whether a VPN or proxy is bypassed by WebRTC before joining a call from that connection.
- Finding out which resolver actually answers for you, rather than which one you configured.
- Comparing a browser profile with WebRTC protections against one without, to confirm an extension works.
- Capturing a before-and-after snapshot when you change tunnel, DNS, or browser privacy settings.
When to use something else
- Proving that you are anonymous. This examines four paths at one moment; fingerprinting, cookies, logins, and traffic analysis identify people far more reliably than an IP address.
- Auditing an application's WebRTC setup or testing your own STUN and TURN servers — the WebRTC Support, ICE Candidate, STUN & TURN Checker is built for that.
- Testing a proxy you administer. Proxy Checker connects through it from our servers and reports where it actually fails, which a browser cannot do.
Privacy and data handling
This tool runs entirely in your browser and sends none of its results to this site's server. The IPv4 and IPv6 requests go directly from the browser to the configured detection endpoints. The WebRTC pass creates a local peer connection, gathers candidates, and closes it; no peer is contacted and no media is captured. The DNS check requests fifty hostnames built from random single-use labels under controlled probe domains, so the authoritative DNS service for those domains can report which resolvers asked — the labels are freshly generated, never reused, and carry nothing about you. Equally important: it cannot read your operating system's proxy configuration, cannot see your VPN client, and never handles credentials.
Related developer tools
Frequently asked questions
Can a web page read my system proxy settings?
No. A page has no API for the operating system's proxy configuration. Everything here is inference from comparing paths: what the HTTP request presented, what WebRTC gathered, and which resolver asked for the probe names.
What makes the DNS probes one-time?
Each of the fifty hostnames uses a freshly generated random label, so nothing has it cached and every query must reach the authoritative service for the probe domain. That service then reports which resolvers asked. Reusing a name would return a cached answer and reveal nothing.
Why are multiple resolvers listed?
Resolver operators run pools, and a recursive resolver may forward a query to a sibling before it reaches the authoritative server. Fifty probes are sent precisely to make that spread visible; a single query would imply more certainty than exists.
Is a private address in the WebRTC list dangerous?
On its own, mildly — it tells a page your LAN addressing, which helps scanning and fingerprinting but is not your public identity. The more serious case is a public candidate that differs from your HTTP address, because that is a second exit you did not know about.
Does the check send my results anywhere?
No. The comparison happens in your browser and nothing is transmitted to this site's server. The detection endpoints see your HTTP requests, the STUN server sees a gathering request, and the authoritative DNS service sees which resolvers asked — each learns only its own part.
It says no obvious leak. Am I safe?
It means these four checks agreed at this moment on this network. It is not a security audit: fingerprinting, logged-in sessions, third-party trackers, and timing analysis all operate outside anything a page can test.
Why does the check need a STUN server?
A server-reflexive candidate exists only because a STUN server observed and reported your public mapping. Without one the browser gathers host candidates only, and the comparison against your HTTP address becomes impossible.