验证分流隧道是否生效：一个 IP 结果算不上测试

一个只显示 IP 地址的浏览器页面，几乎证明不了分流隧道的任何问题。可见的地址可能是对的，原因却可能错；被排除的流量则从不会经过它。测试之前先把预期结果写下来：哪个应用或目标应走隧道，哪个应保持直连，隧道故障时什么应当停止。没有这份计划，任何看似合理的数字都像是成功。

误区：查一次地址就等于验证覆盖范围

IP 检查只回答一个问题：某一刻从某个应用看出去，外部世界看到的是什么。它对内部前缀、第二个浏览器配置文件，或一个本应私下解析的名字一无所知。它对故障同样一无所知，而故障正是分流隧道设计在生产环境里崩掉的那一半。

地址页面也显示不出路由、解析器或故障策略。把它当作一次观察，而不是结论。

分别测试被纳入和被排除的流量

从应被纳入的应用发出一次无害请求，或发往你预期走隧道的前缀，并记录源、目标、地址族和观测到的路径。对应当保持直连的流量做同样的记录。被排除的一侧恰恰是大家会跳过的部分，而它是唯一能证明分流出于有意而非偶然的证据。辅助进程可能带有独立的策略身份，因此要在持有套接字的进程里测试。

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

这就是为什么在错误的应用里测试，可能得到与设计意图相反的结果。得出结论之前，把四个字段对两侧都写下来。

补上 DNS 与故障场景

查询系统解析器和应用所用的解析器，再把这些答案与站点报告的出口地址对比。两层按设计就可能不一致，而一次浏览器查询并不会验证操作系统的策略。用命令行能让对比可重复：故意切断隧道，然后发出一个浏览器没有缓存的请求；缓存里返回的页面说明不了回退走了哪条路。记录实际发生了什么，而不是设计预测了什么。

curl -s https://ifconfig.me
nslookup intranet.example

故障关闭的分流隧道与故障开放的分流隧道，在故意切断隧道之前看起来一模一样。记录你观察到的行为，而不是你预期的行为。

状态变化后重新测试

重新连接、切换网络以及相关应用更新之后，重复同样的观察。已保存的排除项可能仍指向一条不再存在的路径或一个不再存在的应用身份，设计与文档便悄悄对不上了。这三个事件正是分流隧道发生漂移的地方，每一个都值得低成本地重测。只在部署时跑一次的测试，描述的是一个已经不存在的配置。

如果结果不同，先找出规则的所有者和处理阶段，而不是一次改动多项设置。改五处只看一个结果不叫诊断，那叫换了一套配置。

结果应当证明什么

把观察结果与你实际测试的策略和客户端版本绑定。目标是证明这次部署符合它所声称的覆盖范围，而不是保证未来每个应用都走私有通道。这是更窄的断言，也是你真正能用证据支撑的断言。把断言、版本和四字段结果写进变更记录。

这样下一位审查者就能判断是设计变了还是测试变了。当两侧、解析器分流和故障行为都与最初写下的内容一致时，分流隧道才算验证通过。一个 IP 结果一项都证明不了。