某一跳变慢，我认定影响站点

追踪结果里，从第 7 跳开始延迟抬高，后面一直是高的。我判断用户访问慢就是这个原因，写进了报告。

后来用网页测速一测，TTFB 正常，下载也正常。追踪里的高延迟，没传到终点。那次报告被打回来了，说我证据不足。

先看终点有没有变

路由追踪是逐跳的，每一跳的数字都带自己的处理开销。

真正决定体验的是端到端：HTTP 请求多久拿到首字节，页面多久加载完。用户感知的是页面，不是某一跳。

所以第一步不是分析路径，而是先测一次终点，顺序别弄反。

网站测速：多站点分段耗时与状态码

网站测速：多站点分段耗时与状态码

对照着看

用宝塔拨测的网站测速跑同一目标，看五段。两个工具测的时间点要尽量接近，不然对不上。

DNS 和 TCP 正常、TTFB 正常，说明请求在预期时间内到了后端。

如果 TTFB 也明显偏高，且追踪里抬高的位置和地区吻合，那才值得往下查。

再看节点分布。某个入口的追踪和测速同时变差，另一个入口都正常，说明是这条路径的问题。换入口对比时，尽量选同运营商不同地区，这样能分开「地区」和「运营商」两个变量。

追踪里的高延迟什么时候可信

抬高出现在某一跳之后，并且后面所有跳都保持高位，一直到目标。

端到端也同步变差，两个工具指向同一个方向。

换时间、换入口还能复现，而不是一次性的。

这三条同时满足，才算真的影响到终点，缺一条都只能当线索看。追踪每一跳的延迟里，都有回程路径的贡献，单看绝对值意义有限，要看它和前后跳、和端到端的相对关系。

什么时候可以忽略

只有中间一跳高，后面又降下来。

端到端一切正常。

换个入口或者换个时间就消失。

这类多半是设备回包慢或者瞬间抖动，在运营商网络里很常见，只要端到端正常，就不影响业务。

复测和表述

连跑几次追踪，同时跑测速，把两组数据放在同一时间轴上，这一点很关键。如果端到端也慢，再看慢在哪一段：DNS 和 TCP 慢跟路径关系更大，TTFB 慢反而可能是后端，别把路径问题套到所有慢上。

结论里写清楚：哪个入口、哪一跳之后抬高、端到端是否同步变化，以及能不能复现。

别说「第 7 跳有问题，导致网站慢」，除非端到端真的能证明，否则就是猜。

控制变量是老习惯，但确实很有用，多花十分钟，少走一天弯路。追踪给线索，端到端给结论，这句话值得记一下，能少走很多弯路，也能避免很多误判。