WebRTC Leak Test

Server assisted New Internet Security & Privacy

The test runs in your browser. It prepares a WebRTC connection the way a video-call page would — once with Cloudflare's public STUN server (stun:stun.cloudflare.com:3478) and once with none — and lists every address the browser offers. It compares the public address learned through STUN with the one your web traffic uses, as the Mutqan server sees it, and says whether a local address or a different public address is exposed. No TURN relay is used and the candidates are not sent anywhere.

Privacy: Your IP address and connection details are read from the request your own browser makes to the Mutqan server and shown back to you. They are not stored; a one-way hash of your address is used only for per-minute request limits.

How can WebRTC reveal your IP address?

WebRTC lets a web page open direct connections, and for that the browser gathers ICE candidates — its local addresses and, through a STUN server, its public address — which any page can read without asking. A leak is when those candidates reveal what a VPN should hide: a public address other than the VPN's, or a raw local address. RFC 8828 sets what browsers expose by default, and current browsers replace local addresses with random .local (mDNS) names.

How to use WebRTC Leak Test

  1. Connect your VPN if you want to test it, then press Run the WebRTC test.
  2. Wait a few seconds while the browser gathers its candidates in two runs.
  3. Read the findings first, then the table: rows marked "Your public address (via STUN)" are what any page can learn about your connection.
  4. If a leak is reported, turn on your VPN app's leak protection or limit WebRTC in the browser (see "How to stop a WebRTC leak"), then run the test again.

WebRTC Leak Test features

  • Runs in your browser with the standard RTCPeerConnection API, the same way a video-call page would
  • Two runs — with Cloudflare's public STUN server (stun:stun.cloudflare.com:3478) and with no STUN server — to separate public and local addresses
  • Classifies every candidate: local address, hidden .local (mDNS) name, public address learned through STUN, link-local or relay
  • Compares the public address learned through STUN with the address your web traffic uses, as the Mutqan server sees it, including IPv4 against IPv6
  • Says plainly when WebRTC is unavailable or blocked, and when the STUN server could not be reached
  • Never uses a TURN relay and never sends the candidates anywhere

Inputs and outputs

Inputs

  • Nothing to type: press Run the WebRTC test. Your browser contacts stun:stun.cloudflare.com:3478 once and the Mutqan server once.
  • Your browser's WebRTC settings, extensions and VPN state — the test reads them as they are at that moment.

Outputs

  • Summary — candidates gathered, public addresses seen through WebRTC, local addresses exposed, and your public IP as the server sees it.
  • Candidates — each one with the run it came from, its type, address, protocol and what it reveals.
  • Findings — whether a local address or a different public address is exposed, and why.
  • How to stop a WebRTC leak — the browser and VPN settings to change.

WebRTC Leak Test example

A VPN that WebRTC goes around

Input:

VPN on — public IP seen by the Mutqan server: 203.0.113.45

Output:

Candidates gathered: 3 · Public addresses seen through WebRTC: 1 · Local addresses exposed: 0
With STUN — srflx — 198.51.100.20 — udp — Your public address (via STUN)
With STUN — host — 4f1c….local — udp — Hidden local address (random .local name)
Without STUN — host — 4f1c….local — udp — Hidden local address (random .local name)
Finding: WebRTC reveals a public address that differs from the one your web traffic uses. With a VPN or proxy on, this is a WebRTC leak: pages can learn the address of your real connection.

How to read the WebRTC Leak Test results

A public address through STUN that equals your public IP is no extra exposure: every website already sees it.

A public address that differs from your public IP while a VPN or proxy is on is a WebRTC leak: pages can learn the address of your real connection.

A raw local address (192.168.x.x, 10.x.x.x, fd00::/8) is a smaller leak that helps fingerprinting; a .local name in its place means the browser hides it.

An IPv6 address through WebRTC while your web traffic uses IPv4, or the reverse, means the other IP version is exposed — a leak if your VPN tunnels only one version.

No candidates after a completed gathering means WebRTC is off or restricted: nothing can leak through it. If the test reports that it could not gather candidates, that is not the same result — it proves nothing either way.

When to use WebRTC Leak Test

  • Checking a VPN or proxy for WebRTC leaks before relying on it.
  • Verifying that a browser extension or an enterprise policy that limits WebRTC really works.
  • Showing a colleague what a video-call page can learn about their network without asking.

Troubleshooting

  • "The STUN server did not answer" — a firewall or the network blocks outgoing UDP on port 3478, so no public address could be learned through WebRTC; pages cannot learn one that way either.
  • "WebRTC is not available in this browser" — WebRTC is switched off or removed by an extension; that is a safe result.
  • "The test could not gather any WebRTC candidates" — the connection setup failed or did not finish in time, so the test saw nothing either way; this is not proof that nothing leaks. Run it again, and if it keeps failing, something in the browser is interfering with WebRTC.
  • "Your public IP could not be loaded" — the comparison is skipped but the candidates are still listed; press the button again later.
  • The result changes from one run to the next — after a network change the browser may pick another interface; reconnect the VPN and run the test again.

Frequently asked questions about WebRTC Leak Test

What is a WebRTC leak?

WebRTC lets web pages set up direct audio, video and data connections. To do that the browser gathers its network addresses ("ICE candidates"), and a page can read them without asking. With a VPN on, a leak is when those candidates include your real public address, or a local address the VPN was meant to hide.

Which server does my browser contact during the test?

Cloudflare's public STUN server, stun:stun.cloudflare.com:3478, once; it answers with the public address it sees your browser coming from. The Mutqan server is asked separately for the address your web traffic uses, to compare the two. Nothing else is contacted, and no TURN relay is used.

What does a ".local" address mean?

It is a random name (mDNS) the browser shows instead of your real local address, so that pages cannot learn it. Seeing only .local names for the local candidates means that protection is working.

The STUN address differs from my public IP. Is that always a leak?

With a VPN or proxy on, yes: the STUN answer shows the route WebRTC traffic takes, and it bypasses the tunnel. Without one there can be ordinary reasons — a dual-stack connection that uses IPv6 for one and IPv4 for the other, or a proxy set only in the browser.

Why does the test find no candidates at all?

When the browser completes gathering and offers nothing, WebRTC is switched off or restricted by a setting, an extension or a policy, and it cannot reveal any address — a valid and safe result. When the test says it could not gather candidates, the connection setup failed or did not finish in time: that proves nothing either way, so run it again.

Technical notes

Candidates are gathered with RTCPeerConnection (W3C WebRTC) through Interactive Connectivity Establishment (ICE, RFC 8445). Host candidates are the device's own addresses; server-reflexive (srflx) candidates are the public address a STUN server (RFC 8489) saw the request come from.

Browsers limit what WebRTC exposes as RFC 8828 describes: by default, candidates only for the network interface of the default route. Separately, a page without camera or microphone permission normally receives random mDNS names ending in .local instead of local addresses — a measure written up in an IETF draft that expired in 2022 without becoming an RFC, but which current browsers ship.

A STUN request travels over UDP and is not governed by the page's Content Security Policy (connect-src), which is why this page names the STUN server it uses. Gathering stops when the browser reports it complete or after a few seconds.

Limitations and methodology

The test sees what this page sees. A page with camera or microphone permission may receive raw local addresses even when this test shows .local names.

It uses one STUN server over UDP; a leak that appears only over TCP, through another STUN or TURN server, or only during a real call is not reproduced.

Whether a different public address is a leak depends on your setup: without a VPN, a dual-stack IPv4/IPv6 connection or a browser-only proxy can explain it.

Security and privacy

The WebRTC part runs only in your browser. Your browser contacts Cloudflare's public STUN server, stun:stun.cloudflare.com:3478, once; that server sees your public address as any website would. The page also asks the Mutqan server for the address of your web traffic, to compare. The gathered candidates are shown only to you and never sent to the Mutqan server or anywhere else; nothing is stored.

References