WebRTC Leak Test

// What is tested

• A WebRTC peer connection is opened in your browser against a public STUN server, and the ICE candidates it produces are collected.
• Each candidate address is classified as private or public, and as IPv4 or IPv6.
• Public candidates are compared against the address this site already sees for your connection — separately for IPv4 and IPv6, because a dual-stack connection legitimately presents a different address in each family.
• A leak is reported only when a public candidate in a family differs from the known address in that same family.
• Whether the browser is returning mDNS-masked candidates (.local hostnames) instead of real addresses.

// Data sources

Your browser's WebRTC stack

The candidates are produced locally by RTCPeerConnection. No candidate address is sent to any Vuther server.

Google public STUN server

stun.l.google.com:19302, used to discover the public address your connection presents. This is a standard STUN query, the same mechanism any video-calling site uses.

// Limits

• Most current browsers mask local candidates behind randomised .local hostnames by default. That is the protection working, and it means the test cannot enumerate your private addresses — which is the correct outcome, not a failure.
• A browser with WebRTC disabled, or an extension that blocks it, produces no candidates. That is reported as unsupported rather than as a pass.
• The comparison is only as good as the address this site sees for you. Behind certain proxy configurations that address is itself indirect, and the comparison becomes meaningless.
• This tests WebRTC specifically. DNS leaks, IPv6 leaks outside WebRTC and traffic-analysis exposure are different problems and are not covered.