如何检查 TUN是否真正接管了目标应用流量？

为什么累计流量和一次成功请求不够

客户端累计流量可能一直被后台同步、探测、DNS、TLS 握手和其他应用改变。单个网页响应还可能太小，无法从取整后的数字中分辨；首次与重复请求也会受 DNS 缓存、TLS 会话复用、HTTP 缓存和内容缓存影响。

curl 或浏览器返回成功只说明请求完成。它可能使用应用显式代理、系统代理、TUN、其他 VPN 或直连。要判断哪条路径生效，必须让一次请求在同一时间窗内具有可归因的逐连接证据。

一次可复查验证的七个步骤

1. 1
   固定应用、主机和协议

   说明要验证的是浏览器、curl、Git、Docker 的哪一条具体路径，并选择公开、只读且不产生资金或写操作的目标。

2. 2
   记录入口层与出站层

   记录版本、系统代理、TUN、智能路由 / 全局模式；一次只改变一个变量，不把入口和出站混为一层。

3. 3
   移除显式代理影响

   对测试进程移除常见代理环境变量或应用代理；只记录是否存在及来源，不复制地址、凭据或 Token。

4. 4
   确认 TUN 与系统路由迹象

   开关和配置只表示意图，还要检查与当前会话相符的虚拟接口或分段路由迹象；不要仅凭某个接口名称下结论。

5. 5
   发起唯一时间窗的只读请求

   记录开始、结束、成功与否和大致耗时。可用唯一查询参数减少缓存影响，但不要无限下载、并发压测或浪费节点带宽。

6. 6
   匹配逐连接记录

   在“连接”页核对目标进程、主机、上传 / 下载字节、DIRECT 或代理链路，以及请求发生时间。

7. 7
   交叉核对脱敏出口

   只记录出口与测试预期匹配或不匹配，不公开完整家庭公网 IP、节点 IP 或可识别网络位置，并把结论限制到本次请求。

四种结果分别说明什么

fake-IP 是迹象，不是完整 DNS 审计

在当前 fake-IP 模式下，测试域名返回配置范围内的 fake-IP，说明这次本机解析符合该模式的预期迹象。它不能单独证明所有 DNS 查询都走同一路径，也不能替代对 UDP、DoH、浏览器安全 DNS、其他应用或不同网络的专项检查。

本轮脱敏实测说明了什么

测试时版本：arm64 Mac · macOS 26.5.2 · Verstro 1.4.13+20000 · 2026-08-21（之后已升级，不以本页版本号下载）

本轮固定为系统代理关闭、TUN 开启、全局模式；DNS 启用 fake-IP 增强模式并存在 DNS hijack 配置。测试进程移除常见显式代理变量后，一次公开 HTTPS 出口检查成功完成，约 804 ms，出口与本次测试预期的 Verstro 出口集合匹配。

系统同时观察到 TUN 分段路由和 fake-IP 路由迹象；测试域名的一次 DNS 结果落入配置范围。原始出口、原始 DNS 应答、家庭地址、网关、内部节点、账号和完整日志均未保存或发布。

证据缺口：本轮没有为这一次新请求独立保存逐连接页中的进程、主机、字节和链路，因此不能把当前结果写成完整单请求闭环。既有实验曾对同版本、同类设置下的另一条 curl 请求取得逐连接记录，只能说明方法可执行，不能替代本轮新请求。

结论必须限制在实际证据范围内

• 配置中的 tun=true 只表示期望状态，不是请求路径证明；
• 出口变化可能由显式代理、系统代理、其他 VPN 或应用配置造成；
• “连接”页没有记录时，先排除筛选、观察时间、缓存、连接复用与协议差异；
• 一次 curl 结果不能替代 Git、Docker 或其他应用自身的验证；
• 单次 fake-IP 应答不能写成“DNS 无泄漏”。

更完整的入口和出站分层说明见《TUN 模式是什么？》；跨应用差异可按四层排查顺序逐项验证。