WebRTC Leak Test

ICE candidates found

The probe starts automatically when this page loads and finishes within about 2 seconds — nothing to click, nothing to confirm.

What this page can and can't tell you today

The table shows the ICE addresses this negotiation gathered: mDNS-hidden, private/local, direct interface and, when optional STUN is reachable, server-reflexive public addresses.

The page compares all observed global HOST and STUN-derived ICE addresses with this site's fresh same-family HTTP baseline. HOST is a direct interface observation, not STUN confirmation. Missing family baselines, HTTP failures or incomplete gathering are inconclusive; a different exit is not proof of an ISP leak.

WebRTC Leak Test

A "WebRTC leak" happens when the ICE (Interactive Connectivity Establishment) negotiation behind a WebRTC connection discloses an IP address a website was not supposed to learn — typically your real public address even though you're connected through a VPN. ICE gathers three kinds of candidate addresses: host candidates (read directly from a local network interface), server-reflexive candidates (learned by asking a STUN server what public address your traffic left from), and relay candidates (a TURN server's own address, used as a last resort). The classic leak scenario is a server-reflexive candidate slipping past a VPN's tunnel and exposing your ISP-assigned public IP to any page running a few lines of JavaScript — no permission prompt required, unlike camera or microphone access.

Whether a VPN protects you depends entirely on how it's configured, not on WebRTC itself. Most modern VPN clients route all UDP/STUN traffic through the tunnel, so a server-reflexive candidate — if one is gathered at all — reflects the VPN's own exit IP, not your ISP's. Older or misconfigured setups, and certain split-tunnel modes, can still let the browser's network stack reach a STUN server directly outside the tunnel, reproducing the classic leak. A host candidate alone, without any server-reflexive candidate to compare it against, tells you very little either way — it's usually just your machine's private LAN address, present with or without a VPN, and not itself a sign of anything wrong.

Chrome, Firefox and Safari have all shipped mDNS obfuscation for host candidates by default for several years: instead of disclosing your actual private address (like 192.168.1.42), the browser generates a random UUID hostname ending in ".local" and resolves it only on your own local network. That's a real privacy improvement over the old behavior, but it's easy to misread: a ".local" hostname means the browser deliberately hid the address from the page — not that no address exists, and not that there is "no leak". mDNS obfuscation and "nothing to see here" are two different claims, and this page's candidate table always labels them separately.

Matching addresses describe only this completed observation, not proof that your VPN is safe. Different exits may reflect routing or VPN configuration, not necessarily an ISP leak. An address without a same-family HTTP baseline, an HTTP error or incomplete ICE gathering leaves the comparison inconclusive.

How to use this test

1. Load this page

   The probe starts automatically. When STUN is configured, your browser contacts ip2.xakki.pro.

2. Wait for ICE gathering to finish

   Gathering typically completes within 2 seconds; the page shows a "Running…" status until it does.

3. Read the candidate table

   Each row is an address the negotiation reported. Public (STUN-confirmed) indicates a server-reflexive candidate, not a final leak verdict.

4. Understand the boundary

   Read the baseline and each address comparison. A different address is an observed exit difference, not an automatic ISP-leak verdict; no public observation, missing family coverage or incomplete gathering is inconclusive.

5. Reduce exposure if you want to

   Use the browser- or VPN-specific steps below to disable or restrict WebRTC ICE gathering entirely.

How to reduce WebRTC exposure

If you'd rather not have a browser gather any ICE candidates at all, here are the settings that actually exist today:

Chrome / Edge / Brave

Install a WebRTC-blocking extension — Chrome has no built-in toggle to disable WebRTC entirely. Brave also has a "WebRTC IP handling policy" setting under Settings → Privacy and security.

Firefox

Open about:config, search for media.peerconnection.enabled, and set it to false — this disables WebRTC entirely, including its ICE negotiation.

Safari

WebRTC can't be disabled from Settings; use a content-blocking extension that specifically blocks RTCPeerConnection, or a VPN client with its own WebRTC-leak protection.

VPN clients

Most reputable VPN clients include their own "WebRTC leak protection" or "block local network access" toggle — usually simpler and more reliable than a browser-level change, since it works regardless of which browser you use.

Glossary

ICE candidate

A network address WebRTC discovers while trying to establish a peer-to-peer connection — can be a host, server-reflexive, or relay candidate; see the definitions below.

Host candidate

An ICE candidate address read directly from a local network interface, with no external server involved — the only kind this page's probe can gather without a STUN server.

Server-reflexive candidate

An ICE candidate learned by asking a STUN server what public IP address and port your traffic appeared to come from. This page can gather one when optional STUN is enabled and reachable, but does not turn it into a leak verdict.

mDNS obfuscation

A privacy feature in modern browsers that replaces a host candidate's real private address with a random, single-use hostname ending in ".local", resolvable only on your own local network.

STUN server

A lightweight server whose only job is to tell a client what public IP address and port its traffic left from — the mechanism that produces server-reflexive candidates.

WebRTC

A browser API for real-time peer-to-peer audio, video and data connections, standardized by the W3C/IETF — ICE is the part responsible for finding a usable network path between two peers.

API equivalent

Each run automatically fetches a fresh HTTP IP baseline from this site's /api/v1/ip API. That response covers one address family; other-family observations remain inconclusive. Optional STUN contacts ip2.xakki.pro, but the candidate list is compared locally and is not uploaded. You can also inspect the baseline API:

curl "https://ip.xakki.pro/api/v1/ip"

Example response (trimmed):

{
  "schemaVersion": 15,
  "status": "ok",
  "ip": "203.0.113.42",
  "version": 4
}

Read the full API docs

Related tools

• All free tools
• Full Browser Fingerprint Report
• Bulk IP List Classifier
• HTTP Header Inspector
• IP Reputation Check

Frequently asked questions

What is a WebRTC leak?

A WebRTC leak is when the ICE negotiation behind a WebRTC connection discloses an IP address a website shouldn't have learned — most commonly your real public IP even though you're using a VPN, via a server-reflexive candidate obtained through a STUN server.

Does a VPN protect me from this?

It depends on the VPN client's configuration, not on WebRTC itself. Most modern VPN clients route STUN/UDP traffic through the tunnel so any server-reflexive candidate reflects the VPN's own exit IP; older clients or certain split-tunnel modes can still let it leak outside the tunnel.

Why doesn't this page tell me if I have a leak?

The page now compares every observed global ICE address, including HOST and STUN-derived candidates, with a fresh HTTP baseline of the same family. A match is not proof of VPN safety, and a different exit is not automatically an ISP leak. Missing family coverage, failed HTTP requests or incomplete gathering are inconclusive.

What does a ".local" address in the results mean?

It means your browser's built-in mDNS obfuscation replaced the real address with a random, single-use hostname before disclosing it — a genuine privacy feature. That's a different state from "no address was found", and different again from "a real private address was disclosed" — this page always labels which one you're looking at.

How do I disable WebRTC in my browser?

In Firefox, set media.peerconnection.enabled to false in about:config. Chrome, Edge and Brave have no built-in full disable — use a WebRTC-blocking extension, or Brave's own WebRTC IP handling policy setting. Safari needs a content-blocking extension. Most VPN clients also offer their own WebRTC leak-protection toggle.

Is this the same as a DNS leak test?

No — a DNS leak test checks which DNS resolver actually handled your lookups, and that's not something browser JavaScript can observe: there's no API that tells a page which resolver served a given request, so a genuine DNS leak test needs a server-side component. That's a separate tool, not this one.