WebRTC Leak Check

The WebRTC Leak Check page gathers WebRTC candidates only inside the browser and compares public candidates with the address visible to the page. It does not send candidate addresses to the application.

Run A WebRTC Leak Check

1. Open WebRTC Leak Check.
2. Select Start WebRTC Check.
3. Allow the check to finish gathering candidates from the configured STUN or STUNS servers.
4. Read the assessment and, if present, review the locally shown candidate table.

Candidate Types

Private addresses and mDNS hostnames describe local network behavior and are not treated as a public leak. A public server-reflexive candidate can be compared with the address visible to this page. The candidate type column describes the address class, not a security verdict.

Understand Results

• Matched means a public candidate equals the address visible to the page.
• Potential leak means a public candidate differs. This can occur with VPN routing, dual-stack networks, proxies, or browser policy and should be investigated in context.
• Inconclusive means no comparable public candidate was gathered. It is common with browser mDNS masking and does not prove that every network path is hidden.

Privacy And Browser Behavior

The page uses only administrator-configured STUN or STUNS endpoints. Candidates stay in the browser and optional activity logging records only the final assessment, never addresses. Browser settings, extensions, VPNs, NAT, IPv6, firewall behavior, and STUN availability can change the output.

Troubleshooting

• WebRTC unsupported: use a current browser with WebRTC enabled.
• No safe STUN server: the administrator must configure a public STUN or STUNS endpoint in DNS And WebRTC Leak Config.
• No usable candidate: the result remains inconclusive; do not treat an empty table as proof of privacy.
• Different privacy question: use DNS Leak Check for resolver exposure instead of ICE candidates.

Icon Reference