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. It means the test cannot enumerate your private addresses, which is the correct outcome rather than 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.