WebRTC and UDP egress checks
Compare STUN candidates with HTTP egress without requesting a camera or microphone. Missing candidates can reflect browser restrictions or blocked traffic; they do not prove that no leak exists.
Check HTTP egress and UDP candidates separately
Inspect STUN sources, candidate types and address families, then compare them with HTTP egress from the same run. The tool does not require camera or microphone access and interprets only candidates exposed by the browser.
When using a proxy, establish whether its intended routing includes UDP and IPv6. HTTP, UDP and IPv6 may have different configuration scopes. Retest the same sources after switching and keep A/B records.
Candidates, exits and device addresses
A public STUN candidate reflects the address visible to that WebRTC probe. Private or mDNS candidates are not public exits. Candidates appearing, disappearing or differing from HTTP need protocol and routing context.
Teaching example: HTTP changes while UDP does not
Suppose HTTP changes after switching nodes while UDP candidates in the same address family remain unchanged. Check client UDP routing and retest. If a verified direct IP matches the UDP candidate, a disconnect drill can add evidence. This is not an observation of a user network.
Does no candidate mean protection?
No. Browser policies, blocked STUN, timeouts and unsupported protocols can all prevent candidates. Preserve the unavailable state and check supported sources and client configuration. Browser checks cannot prove identical routing for every application.
Related tools and guides
Live measurements run in your browser after JavaScript loads. This introduction contains no visitor detection results.