所有测得的公网通道要么使用了预期路由，要么没有暴露意外的基线地址。
本次运行中，测得的通道结果一致；未测试的应用和未来的路由变化不在范围之内。
路由覆盖指南
代理、VPN 与 WARP 对比：实际覆盖了哪些浏览器网络路径？
路由类产品工作在不同的层级。浏览器代理可以改变网站 HTTP 流量的路由，而 WebRTC、DNS 或另一个地址族仍可能沿用操作系统的路由。
快速解答
这一结果能说明什么
HTTP 代理通常只承载明确配置为使用它的应用流量。SOCKS5 可以承载更多协议，也可能支持远程域名解析，但哪些流量经过代理取决于客户端的行为。全设备 VPN 或 WARP 流量模式工作在设备路由层，但分离隧道、排除规则、DNS 模式和浏览器策略仍可能产生不同的可观测路径。每次只改变一条路由，并在改变前后测试每个信号。
证据边界
检查的信号——以及它们不能证明什么
可信的泄露判定会把可观测的浏览器证据，与关于身份、归属或路由意图的假设区分开。
| 信号 | 可获得的证据 | 不能证明什么 |
|---|---|---|
| HTTP/HTTPS 浏览器流量 | 普通页面请求和特定地址族检测端点所看到的公网路由。 | 网站出口改变并不能证明 UDP、DNS、WebRTC 或其他应用也使用同一路由。 |
| WebRTC/ICE 路径 | 浏览器对等连接协议栈暴露的公网候选地址。 | 浏览器代理设置并不能自动说明 ICE 套接字是如何路由的。 |
| DNS 路径 | 通过令牌化权威回调观测到的递归解析器。 | 仅凭解析器的地理位置，无法看出是哪个本地组件选择了它。 |
| 分离路由行为 | 启用代理、WARP 配置文件或 VPN 后，哪些信号仍停留在已保存的直连基线上。 | 本工具无法读取专有的路由规则、排除规则或所购产品的设置。 |
方法
以基线为先的工作流程
- 1
从不使用待评估路由开始
在同一浏览器配置文件中记录直连时的 IPv4、IPv6、WebRTC 和解析器证据，并将其保存为用户声明的基线。
- 2
只启用一个路由层
分别测试 HTTP 代理、SOCKS5 客户端、WARP 配置文件或全设备 VPN。叠加多条路由会让人难以判断是哪一层暴露了信号。
- 3
比较每个通道
检查普通页面请求、两个 IP 地址族、完整的 WebRTC 证据以及权威 DNS 观测结果。缺失的证据仍归为“不可用”。
- 4
修复之前先检查配置
借助客户端和服务商的文档，确认远程 DNS、IPv6 支持、流量模式、分离隧道排除规则以及浏览器的 WebRTC 策略。
解读
证据如何对应到有限定的状态
“无泄露迹象”的含义比“安全”更窄，“需复核”不是泄露判定，而“不可用”绝不会被转换为通过。
HTTP 路由改变了，但 DNS/网络归属含糊，或者有某个通道无法可靠地与预期路由关联起来。
请核实客户端模式和服务商行为，而不要把地理位置不匹配当作证据。
浏览器可见路由使用代理或隧道时，WebRTC、IPv4 或 IPv6 暴露了与直连基线完全相同的地址。
至少有一个测得的通道绕过了预期路由。
某个地址族、DNS 回调或 ICE 候选收集过程未能产生可用的证据。
该通道上的路由既无法判定为通过，也无法判定为失败。请重试并检查策略或服务可达性。
故障排查
更改设置之前，先诊断路径
浏览器代理的出口正确，但 WebRTC 与直连基线相同。
- 可能的原因
- 代理只作用于应用层面，而 ICE 使用了浏览器或操作系统的另一条套接字路径。
- 下一步检查
- 限制 WebRTC、使用全设备路由，或在适当时禁用 WebRTC；然后再次与同一基线进行比较。
WARP 或 VPN 改变了大多数信号，但有一条路由仍然直连。
- 可能的原因
- 分离隧道排除规则、本地域名回退、流量模式、地址族覆盖缺口或客户端兼容性规则。
- 下一步检查
- 检查官方的路由和 DNS 配置。Cloudflare 的文档说明，被排除的流量会绕过其客户端，而 DNS 有单独的控制项。
SOCKS5 对主机名有效，但 DNS 看起来是直连的。
- 可能的原因
- 应用可能在建立 SOCKS 连接之前先在本地解析，而不是使用远程域名解析。
- 下一步检查
- 如果客户端支持，请选择其远程 DNS 模式，并通过重复的令牌化 DNS 测试加以核实。
局限
本指南和测试无法保证的内容
- 该表描述的是常见的路由范围，并不对每个产品、操作系统、浏览器、扩展程序或企业策略作出保证。
- WARP 是 Cloudflare 的产品名称；其模式和分离隧道行为必须对照当前安装的客户端和官方文档进行核实。
- 标准网页无法检查完整的操作系统路由表或专有客户端配置。
- 叠加的代理、隧道、容器、虚拟机和远程浏览器可能产生两条以上的正常公网路径。