All measured public channels either use the intended route or expose no unexpected baseline address.
The measured channels were consistent in this run; untested applications and future route changes remain outside scope.
Route coverage guide
Proxy vs VPN vs WARP: which browser network paths are actually covered?
Routing products operate at different layers. A browser proxy can change website HTTP traffic while WebRTC, DNS, or another address family still follows the operating system route.
Quick answer
What this result can establish
An HTTP proxy normally carries only application traffic explicitly configured to use it. SOCKS5 can carry more protocols and may support remote name resolution, but client behavior decides what is proxied. A full-device VPN or WARP traffic mode operates at the device route layer, yet split tunnels, exclusions, DNS modes, and browser policies can still create different observable paths. Test each signal before and after changing one route.
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 |
|---|---|---|
| HTTP/HTTPS browser traffic | The public route seen by normal page requests and family-specific detection endpoints. | A changed website exit does not prove that UDP, DNS, WebRTC, or other applications use the same route. |
| WebRTC/ICE path | Public candidates exposed by the browser's peer-connection stack. | A browser proxy setting does not automatically describe how ICE sockets are routed. |
| DNS path | Recursive resolvers observed through tokenized authoritative callbacks. | Resolver geography alone does not reveal which local component selected it. |
| Split-route behavior | Which signals stay on the saved direct baseline after a proxy, WARP profile, or VPN is enabled. | The tool cannot read proprietary route rules, exclusions, or purchased product settings. |
Methodology
A baseline-first workflow
- 1
Start with no evaluation route
Record the direct IPv4, IPv6, WebRTC, and resolver evidence in the same browser profile. Save it as a user-asserted baseline.
- 2
Enable exactly one routing layer
Test the HTTP proxy, SOCKS5 client, WARP profile, or full-device VPN separately. Stacking routes makes it difficult to identify which layer exposed a signal.
- 3
Compare every channel
Check normal page requests, both IP families, completed WebRTC evidence, and authoritative DNS observations. Missing evidence remains Unavailable.
- 4
Inspect configuration before fixing
Use the client and provider documentation to confirm remote DNS, IPv6 support, traffic mode, split-tunnel exclusions, and browser WebRTC policy.
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.
The HTTP route changes but DNS/network ownership is ambiguous, or one channel cannot be related confidently to the intended route.
Verify the client mode and provider behavior instead of treating a geography mismatch as proof.
WebRTC, IPv4, or IPv6 exposes an exact direct-baseline address while the browser-visible route uses the proxy or tunnel.
At least one measured channel bypassed the intended route.
A family, DNS callback, or ICE gathering process fails to produce usable evidence.
The route cannot be cleared or failed on that channel. Retry and inspect policy or service reachability.
Troubleshooting
Diagnose the path before changing settings
Browser proxy exit is correct, but WebRTC matches the direct baseline.
- Likely explanation
- The proxy is application-scoped while ICE uses another browser or operating-system socket path.
- Next check
- Constrain WebRTC, use a full-device route, or disable WebRTC where appropriate; then compare the same baseline again.
WARP or VPN changes most signals, but one route stays direct.
- Likely explanation
- A split-tunnel exclusion, local-domain fallback, traffic mode, address-family gap, or client compatibility rule.
- Next check
- Inspect the official route and DNS configuration. Cloudflare documents that excluded traffic bypasses its client and that DNS has separate controls.
SOCKS5 works for a hostname but DNS appears direct.
- Likely explanation
- The application may resolve locally before opening the SOCKS connection rather than using remote name resolution.
- Next check
- Choose the client's remote-DNS mode if supported and verify it with repeated tokenized DNS tests.
Limits
What this guide and test cannot guarantee
- The table describes common routing scopes, not a guarantee for every product, operating system, browser, extension, or enterprise policy.
- WARP is a Cloudflare product name; modes and split-tunnel behavior must be verified against the currently installed client and official documentation.
- A standard web page cannot inspect the full operating-system route table or proprietary client configuration.
- Stacked proxies, tunnels, containers, virtual machines, and remote browsers can create more than two legitimate public paths.
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 resourceRead the WebRTC guide
Understand why peer-connection candidates can differ from the browser's HTTP exit.
Open resourceRead the DNS guide
Understand local versus remote resolution, public resolvers, and anycast ambiguity.
Open resourceRead the IPv6 guide
Check whether an IPv4-only route leaves another public address family visible.
Open resource