刚做完断网应急处理，一跑验证脚本就报错：「网络恢复验证不通过」——这事儿在运维值班时太常见了。不是设备没通电，也不是光纤断了，但偏偏验证就是过不去。问题往往藏在几个容易被忽略的环节里。
1. 验证目标地址本身不可达
很多团队习惯用 ping 网关或 DNS 服务器（比如 114.114.114.114）做验证，但实际业务走的是另一套路径。曾有个案例：核心交换机到防火墙的策略放行了 ICMP，但业务服务器的 443 端口被 ACL 拦住，验证脚本却只测 ping，结果「通了」但业务完全打不开。建议验证目标必须是真实业务链路中的关键节点，比如下游 API 网关的健康检查端点。
2. 源端出口策略未同步更新
网络恢复后，常忘了回滚临时策略。比如故障期间手动加了一条静态路由指向备用线路，恢复后没删掉，导致验证流量被错误牵引；或者 ACL 里留着一条「deny any」调试规则没清理。这类问题在多厂商设备混搭环境中尤其高发。
ip route 0.0.0.0 0.0.0.0 192.168.10.1 # 故障期加的默认路由，忘了删3. DNS 缓存未刷新
本地 DNS 缓存、容器内 resolv.conf、甚至手机热点的 DNS 设置都可能卡着旧解析记录。某次 CDN 切换后，验证脚本调用的域名仍解析到下线 IP，ping 通了，curl 却超时。快速验证方法：
nslookup api.example.com 8.8.8.8 # 绕过本地缓存直连公共 DNS4. 源端主机网络栈异常
服务器本身没问题，但验证发起端出状况。比如 Linux 主机上执行了 sysctl -w net.ipv4.conf.all.forwarding=0 关闭转发后，本机的 TCP 连接建立失败；或者 Windows 主机启用了「智能多宿主名称解析」，在双网卡环境下随机选错出口网卡发包。
5. 时间窗口错配
有些验证逻辑依赖时间戳比对（如证书有效期、token 过期时间），若恢复后未校准 NTP，源端和目标端系统时间差超过 5 分钟，HTTPS 握手直接失败，验证自然不过。别急着查链路，先看 ntpq -p 或 w32tm /query /status。
6. 中间设备会话表残留
防火墙、负载均衡器等有状态设备，在链路中断时可能未及时老化会话。恢复后新连接尝试复用旧会话 ID，被直接丢弃。典型表现是：第一次请求失败，重试一次却成功。此时需登录设备清空对应会话：
reset firewall session table destination 10.20.30.40