Checking for a WebRTC leak means comparing every address your browser's real-time connection machinery reveals against the address you're actually browsing from — then deciding whether any of them shouldn't be visible.

What the test is actually doing

A WebRTC leak test opens a connection to one or more STUN servers and collects every ICE candidate address the browser gathers during that process. Separately, it measures your public IP over ordinary HTTP — ideally both the IPv4 and IPv6 versions, since a VPN can protect one and not the other. It then checks whether any WebRTC-discovered address falls outside that known set.

Running it

  1. Connect your VPN or proxy. Testing without one only shows your unprotected baseline.
  2. Open the test. NetRiskScan's WebRTC Leak Test runs this automatically and shows both your HTTP exit addresses and every WebRTC candidate side by side.
  3. Compare candidate by candidate. Each address the test collects is compared against your measured exit IPs and marked as matching, unexpected, or local/private.
  4. Repeat on each browser you use. Chrome, Firefox, Edge and Safari implement candidate gathering differently, and a browser extension that's active in one profile may not be in another.

Reading the outcomes

  • No Leak — every public candidate matched an already-known exit address.
  • Leak Detected — at least one public candidate didn't match either exit address. That's very likely your real network identity, escaping the tunnel through WebRTC specifically.
  • STUN Timeout / All STUN Servers Failed — the browser couldn't complete address gathering, often because a firewall blocks the UDP traffic STUN needs. This means the test couldn't run, not that you're protected — it's worth trying from a different network if this happens repeatedly.
  • No Candidates Gathered — the browser returned nothing at all, most often because WebRTC is disabled or an extension is blocking it. In that case there's no discovery mechanism to leak through.

What to do with a positive result

Check whether your VPN client has a dedicated WebRTC-leak-protection toggle — many now do. If it doesn't, a browser-level WebRTC-blocking extension, or a browser with a built-in control (some ship one under privacy settings), is the next option. Re-run the test after any change to confirm the previously-leaking address is gone.

FAQ

Why did my result change between two runs on the same VPN server?

STUN candidate gathering can vary slightly run to run, and some VPN clients only tunnel WebRTC traffic inconsistently depending on how the connection was established. If you get a mixed history, treat any "Leak Detected" result as real and investigate, even if a later run comes back clean.

Do local/private candidates matter?

They're collected for completeness but aren't a leak on their own — addresses like 192.168.x.x or 10.x.x.x only mean something on your own local network and aren't reachable from the public internet.