IP、DNS、WebRTC 泄露怎么测：结果判读指南

先明确你希望保护哪些流量

系统代理可能只覆盖遵循它的应用；TUN 通常接管范围更广，但仍受排除规则、IPv6、UDP 和应用行为影响。开始前写清目标：只让浏览器走代理，还是让整机指定流量走代理。没有这个前提，就无法判断一条直连到底是有意分流还是意外绕行。

测试服务会看到你访问它时的网络地址，这是检测的必要条件。使用你信任的服务或自有服务器，不要提交订阅链接、账号、证书或代理密码。若不接受向第三方暴露测试地址，可以只用自己控制的接收端日志完成相同对照。

第一步：在同一网络中记录基线

1. 关闭自己的代理与 VPN，确认没有其他 TUN、路由器代理或浏览器扩展接管；记录当前接入的是哪张网络。
2. 在待测浏览器中分别打开 https://api.ipify.org 和 https://api6.ipify.org，记录 IPv4 和 IPv6。第二个打不开只说明这次 IPv6 查询未成功，可能本来就无 IPv6；不能据此宣称“绝无泄露”。
3. 开启要测试的代理，保持同一网络与同一浏览器，重新加载两个地址，比较结果。再核对客户端连接记录中的出口规则。

记录完整地址只需留在本地。发给他人时遮盖部分地址，不要把自己的家庭 IP 当成教程截图公开。IP 地理数据库可能过时，不能仅凭显示国家和节点名字不一致，就断定发生绕行。

第二步：IPv4 与 IPv6 要分开看

若你使用的是系统代理，在终端运行 curl 不一定走同一条路径。不要把“浏览器走代理、终端直连”误认为浏览器本身泄露。使用 TUN 做整机验证时，也要确认测试目标没有被排除。避免为了让测试页面好看，直接对全系统永久关闭 IPv6；应优先按客户端文档配置接管或明确的阻断策略。

第三步：DNS 测试不是一张国旗判断好坏

DNS 检测通常让浏览器访问随机子域名，再由检测方观察哪个递归解析器来查询。结果可能显示公共 DNS、转发器或任播节点，其地理标签不等于你实际出口的位置。看到本地国家或熟悉的提供商不能单独证明请求未经加密或绕过隧道。

如果要做 DNS 检测，使用可信工具或自建权威 DNS 的随机子域名测试，同时观察内核日志、浏览器安全 DNS 和系统私人 DNS 的设置。关键问题是：受保护域名的解析是否符合你定义的路由策略，而不是页面是否显示“全绿”。

Mihomo fake-ip 是合成地址映射，并不是目标真实 IP；用它做公网地址归属判断会出错。DoH/DoT 保护的是相应 DNS 传输，并不自动改变应用的网页出口，也不保证所有应用都使用那一个解析器。

第四步：用 WebRTC 示例观察 ICE 候选

1. 打开下方参考资料中的 WebRTC Trickle ICE 示例。它会按页面所配置的 STUN/TURN 服务发起检测流量，先确认你接受这些服务。
2. 分别在断开与开启代理时点击页面的 Gather candidates，记录候选类型与地址，不需要输入订阅凭据。
3. 关注可公开路由的地址是否仍与直连基线一致，并结合你要覆盖的 UDP/WebRTC 范围判断。host、srflx、relay 是不同来源的候选，不要把列表中的每个地址都当作实际选中的传输路径。

host 候选可能是本地地址或经过浏览器隐私处理的标识；私有网段地址本身不等于公网出口。srflx 与 relay 提供不同的路径线索，最终建立的连接还会从候选中选路。测试页面未收集到候选，也可能只是权限、浏览器策略或 STUN 不可达，不能证明所有实时通信都绝无绕行。

最后：对症修复，再测真实应用

若发现不符合预期的 IPv6 或 UDP 路径，先检查客户端接管、排除规则和官方支持范围，再选择覆盖该流量的配置。改完回到真实视频通话、浏览器和日常网络复测。Safari 启用 iCloud 专用代理时，出口表现也可能不同，需单独记录。

这些测试不会抹掉登录账号、Cookie、浏览器指纹或应用权限，也不能证明服务商不记日志，更不能证明“绝对匿名”。它们最有价值的用途，是发现你的实际网络路径与自己想要的路径不一致，并据此做最小范围修正。