IPv6 is absent when the intended route is IPv4-only, or the visible IPv6 is verified as part of the intended tunnel route.
This run showed no unexpected IPv6 path. Absence of IPv6 does not test future connectivity changes.
Focused diagnostic guide
IPv6 Leak Test: compare both address families before calling a leak
Different public IPv4 and IPv6 addresses are normal. IPv6 becomes a leak indicator when it matches a direct baseline or is independently verified outside the route that should carry it.
Quick answer
What this result can establish
An IPv6 leak test uses an IPv6-only request to determine whether the browser has public IPv6 connectivity, then compares that address with the intended route and a saved direct baseline. An IPv4-only proxy can carry IPv4 browser requests while IPv6 continues directly. No IPv6 result means the family was unavailable or its request failed—it is not a universal security 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 |
|---|---|---|
| IPv6 connectivity | Whether an IPv6-only endpoint can observe a public IPv6 address from this browser session. | No response cannot distinguish disabled IPv6 from endpoint, policy, or network failure without more evidence. |
| Address-family coverage | Whether IPv4 and IPv6 are both present and which public networks they use. | Different addresses or providers are not automatically unexpected on a dual-stack connection. |
| Direct baseline match | Whether the routed run exposes the same public IPv6 address recorded before the route changed. | The baseline is user-asserted and can become stale when an ISP rotates prefixes. |
| Route intent | Whether the selected product and client claim to carry IPv6 traffic at all. | The tool cannot infer the purchased product or client policy without user context. |
Methodology
A baseline-first workflow
- 1
Capture both families directly
Run without the route under test and save any observed IPv4 and IPv6 addresses. A baseline with only IPv4 cannot later identify a rotating or newly enabled direct IPv6 address by exact match.
- 2
Enable the intended route
Change only the proxy, WARP, or VPN route. Confirm whether that product and client are expected to support IPv6 rather than assuming IPv4 support covers both families.
- 3
Use family-specific endpoints
The combined tool requests IPv4-only and IPv6-only services separately so one family cannot silently substitute for the other.
- 4
Classify against intent and baseline
An exact direct IPv6 baseline match after routing is strong evidence of bypass. A new or ambiguous IPv6 route needs network verification before a leak verdict.
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 public IPv6 route appears but its relationship to the intended route or direct baseline cannot be verified.
Check product support, client routing, network owner, and repeated baseline results.
IPv6 exactly matches the direct baseline or is independently verified outside a route that should carry IPv6.
The IPv6 family bypassed the intended route in this run.
The IPv6-only request fails, is blocked, or returns no usable public address.
IPv6 connectivity was not measured. State the family as unavailable rather than safe or leaked.
Troubleshooting
Diagnose the path before changing settings
The proxy changes IPv4 but the direct IPv6 remains visible.
- Likely explanation
- The selected proxy/client carries configured IPv4 application traffic but does not carry or disable IPv6.
- Next check
- Use an IPv6-capable route, disable IPv6 only if appropriate for the environment, or use a full-device tunnel with verified IPv6 coverage.
Only IPv6 is visible through a proxy route.
- Likely explanation
- The proxy exit or detection endpoints may have family-specific reachability; the IPv4 request may also have failed independently.
- Next check
- Review each family status separately and do not infer a leak solely from the missing IPv4 result.
The IPv6 prefix changes between runs.
- Likely explanation
- ISPs, privacy extensions, tunnels, and rotating services can assign or expose changing IPv6 addresses or prefixes.
- Next check
- Use exact saved addresses for strong matches and verify network ownership for weaker prefix-level comparisons.
Limits
What this guide and test cannot guarantee
- The test samples browser fetch connectivity, not every socket, application, or operating-system route.
- IPv6 privacy addressing and prefix rotation reduce the value of string or prefix similarity without independent network evidence.
- A missing IPv4 or IPv6 result can be caused by service reachability rather than the local network stack.
- Disabling an address family may break local services or applications and should not replace correct route configuration.
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
Compare typical family coverage across application and device routing layers.
Open resource