Traceroute 展示探测响应，不能完整代表转发健康
Traceroute 发送 TTL 逐步增大的探测包，观察数据包在哪里到期，以及哪些系统报告了到期。IPv4 路由器转发时递减 TTL；到期后，通常由 ICMP Time Exceeded 响应标识一个作出回复的跳点。传统 UDP 跟踪在目标报告端口未使用时结束。输出是一系列关于探测和回复的观察，不保证列出全部转发设备，也不直接等同于应用经过的唯一稳定路径。 坏掉的样子 星号表示某个探测没有在等待时间内获得预期响应。路由器可能仍正常转发普通流量，却过滤、抑制或限制自己生成的 ICMP 回复。回复的返回路径也可能出问题。因此，中间某跳沉默，本身不能证明应用数据包在那里停止；后续跳点仍然回复，甚至会直接反驳这种判断。需要区分转发动作和产生诊断响应这两种行为。 探测协议同样重要。传统高端口 UDP 流量可能遇到与允许服务端口上的 TCP 不同的策略。TCP traceroute 可以让探测更接近被允许的传输方式，但仍没有执行完整应用交互。收到 SYN 响应或重置，可以帮助判断目的地可达，却不能证明 HTTP、认证或某项业务操作成功。协议层面的终点响应必须与应用结果分别解释。 每跳时间是从观察者出发的往返时间，包含响应生成和返回路径。把相邻数值相减，不能可靠测量两台路由器之间的单向链路延迟。负载均衡、返回路径不对称、调度与 ICMP 处理都会影响观察。比较跟踪时，应保留探测方式和测量条件，不能把一次打印序列当作永久拓扑，也不能把后续更短的往返值解释成负延迟。 快速验证 将脚本保存为 check-traceroute.py，准备 Docker 后运行 python3 check-traceroute.py。一次性环境使用 traceroute 2.1.2、nftables 1.0.6 与 Python 3.11.16。NET_ADMIN 和 SYS_ADMIN 支持嵌套命名空间及临时 proc 挂载。客户端、路由器和目标通过新建 veth 相连，全部选路与过滤变更都留在实验内部，不触碰宿主正在使用的网络配置： ...