我逐跳相减，算出一个「瓶颈」

一份路由追踪，第 6 跳突然比第 5 跳高了很多。我一减，认定这一段有问题，把截图发给运营商。

对方让我再跑一次，两次结果不一样。那段「瓶颈」时有时无，更像是那台路由器回复探测包时慢，而不是转发慢。那次我被教育了一顿，但也学到了方法。

为什么不能相减

每一跳的时间，是「包到达这台设备、它回一个超时消息、消息回到你这里」的总时间。

这个回包由设备的控制面处理，优先级通常比转发低。设备忙的时候，回包就慢，但你的数据照样过得去。

去程和回程往往不是同一条路，相减得到的差值里混了另一个方向的延迟。

还有负载均衡，同一个 TTL 的包可能走了不同路径，多次测量结果本来就不一样。多测几次取平均也解决不了，因为每条包的路径可能不同。

宝塔拨测控制台：定时拨测任务、节点与告警配置

宝塔拨测控制台：定时拨测任务、节点与告警配置

星号同理

某跳显示星号，多数是设备不回复探测包，或者对 ICMP 限速。

后面的跳正常，说明流量过得去。只有从某一跳开始，后面全部超时，才值得怀疑。很多运营商内部设备会限制 ICMP 速率，这是默认策略，别把策略当成攻击或者故障。用宝塔拨测的控制台的多入口追踪，能看出后面是不是真的全断了。

正确的读法

看趋势，不看单点。

从第几跳开始，后面所有跳的延迟都整体抬高？如果是，说明问题在那一段之后。

只有一跳高、后面又降回去，基本可以忽略，是那台设备自己的回包慢。抬高的那一段，可能是长途链路，也可能是拥塞节点，未必是故障。

多跑几次，看这个抬高点是否稳定复现。稳定才值得追。

用端到端数据校验

路由追踪是现象，不是结论。

用 ping 或 TCP 探测测端到端，看实际延迟和丢包。端到端正常，路由里那些高跳就不用管。端到端正常，中间再好看也和你无关。

从多个入口跑，对比路径在哪分叉，比盯着某一跳有用。

复测和表述

隔时间再跑，换几个入口，把结果放一起看。路由会变，今天的路径明天未必还在，所以复测比单次分析重要。怀疑某一段，可以换 TCP 追踪再试，不同协议的路径可能不一样。

和别人沟通时说「从某入口到目标，整体延迟在第几跳之后抬高，端到端表现为多少」，比说「第 6 跳有问题」准确得多。

路由追踪帮你找方向，端到端指标才能定性质，别把中间一跳当成结论。记录里写清入口、时间和路径，结论里加上时间范围才严谨，别用一张图定案。