Only private, link-local, mDNS-masked, relay, or exact visible-route candidates are observed after completed gathering.
No unexpected public route was demonstrated in this run; this is not an anonymity guarantee.
Focused diagnostic guide
WebRTC Leak Test: read ICE candidates without guessing
A public WebRTC address is evidence about a browser network path. It becomes a verified leak only when it matches a saved direct baseline or is independently shown to be outside the intended route.
Quick answer
What this result can establish
A WebRTC leak test creates an RTCPeerConnection, waits for ICE gathering, classifies candidates, and compares public candidate addresses with the browser-visible route and a known direct baseline. Private addresses and mDNS hostnames are not public identity leaks. A timeout or empty candidate set is Unavailable, not a pass.
Evidence boundaries
Signals checked—and what they do not prove
A trustworthy leak verdict separates observable browser evidence from assumptions about identity, ownership, or route intent.
| Signal | Evidence available | What it does not prove |
|---|---|---|
| ICE completion | Whether candidate gathering completed, timed out, was blocked, or produced malformed evidence. | A timeout does not prove that WebRTC is disabled or safe. |
| Candidate type | Host, server-reflexive, peer-reflexive, and relay candidates described by the WebRTC and ICE standards. | Candidate type alone does not identify the address owner or intended route. |
| Public route comparison | Exact address, address family, and independently verified network relationship to visible IPv4/IPv6 routes. | A different address on the same multi-egress network is not automatically a leak. |
| Direct baseline match | Whether a public candidate exactly matches an address the user saved while directly connected. | A user-saved baseline is asserted by the user; the tool cannot verify how that run was routed. |
Methodology
A baseline-first workflow
- 1
Record the direct route
Run the complete test without the route you want to evaluate and save that run as the direct baseline. Record both address families because IPv4 and IPv6 can take different paths.
- 2
Change one routing variable
Enable only the browser proxy, WARP profile, or full-device VPN being evaluated. Keeping the browser profile and other network settings stable makes the comparison interpretable.
- 3
Gather completed ICE evidence
The test creates a data-only RTCPeerConnection. It does not request camera or microphone access. It waits for a completed candidate set before classifying public addresses.
- 4
Compare, then qualify
An exact direct-baseline match is a strong bypass indicator. Another independently verified public network can also be a leak. Ambiguous same-network or incomplete evidence remains Review or Unavailable.
Interpretation
How evidence maps to a qualified status
No Indicator is narrower than “safe,” Review is not a leak verdict, and Unavailable is never converted into a pass.
A different same-family public address appears on the same independently verified network, or ownership cannot be resolved confidently.
Multi-egress routing may be legitimate. Compare with a saved baseline and the provider's expected network.
A public candidate matches the saved direct baseline or belongs to a verified network outside the intended browser route.
The browser exposed a public path outside the intended route.
ICE gathering times out, is blocked, returns no usable candidates, or produces malformed evidence.
The test did not obtain enough evidence. Retry and inspect browser or extension policy before drawing a conclusion.
Troubleshooting
Diagnose the path before changing settings
HTTP traffic uses the proxy, but WebRTC exposes the direct baseline.
- Likely explanation
- The browser proxy covers configured HTTP traffic while ICE/STUN uses another socket or UDP path.
- Next check
- Use a full-device tunnel, a browser policy that constrains non-proxied UDP, or disable WebRTC if the application does not need it; then rerun against the same baseline.
WebRTC shows another address on the same provider network.
- Likely explanation
- The provider may use separate egress addresses for HTTP and WebRTC traffic.
- Next check
- Confirm the network owner and expected egress behavior before treating the address difference as a leak.
The test repeatedly times out.
- Likely explanation
- Browser policy, an extension, firewall rules, STUN reachability, or an incomplete ICE event sequence may be blocking evidence.
- Next check
- Retry in a clean profile and another browser. Treat the result as Unavailable until gathering completes.
Limits
What this guide and test cannot guarantee
- The page observes only the candidates this browser exposes during this run; browser versions and enterprise policies can change that behavior.
- A WebRTC result does not test every application, protocol, TURN server, or future peer connection on the device.
- Network ownership and geolocation data can be stale or ambiguous, so exact baseline matches carry more weight than geography alone.
- Disabling WebRTC can break calls, conferencing, streaming, and peer-to-peer features.
Continue testing
Related evidence and route guides
Use one saved baseline across the related checks so differences remain attributable.
Run the complete IP Leak Test
Compare browser-visible IPv4, IPv6, WebRTC, and DNS evidence against a saved direct baseline.
Open resourceRead the route case series
Review anonymized direct, WARP, and browser-proxy observations from one recorded test session.
Open resourceCompare proxy, VPN, and WARP routing
See why application proxies and device tunnels can expose different WebRTC paths.
Open resource