在线 -
搜索 AIGC编程网
← 返回题目列表

traceroute 和 mtr 如何定位网络路径问题？它们的结果怎么看？

高频 中等 第 16 / 26 题 更新于 2026/07/31
traceroutemtr路由网络排查

简化版

traceroute 用 TTL 递增探测从本机到目标的路径，能看到经过哪些路由节点以及每跳延迟。mtr 是 traceroute + ping 的持续版，可以观察每跳的延迟、抖动和丢包。排查时要关注“从哪一跳开始异常持续出现”，不要被中间某一跳不回 ICMP 误导。

详细版

traceroute 的原理是发送 TTL=1、2、3… 的探测包。TTL 到 0 时，中间路由器返回 ICMP Time Exceeded，于是客户端知道这一跳是谁。到达目标后，探测结束。

看结果时要注意：

  • 某一跳 * * * 不一定代表网络断了，可能是该路由器不回 ICMP；
  • 如果某一跳丢包高，但后续跳正常，通常只是该节点限速 ICMP；
  • 如果从某一跳开始，后续所有跳延迟都升高或丢包，才更像真实路径问题；
  • mtr 要跑一段时间，观察平均值、最差值、抖动和持续丢包。

完整版教学

一、TTL 为什么能探路

IP 包里有 TTL 字段，每经过一个三层路由节点，TTL 减 1。TTL 变成 0 时，路由器丢弃这个包，并通常返回 ICMP Time Exceeded。

TTL=1 -> 第一跳 TTL 归零 -> 返回 ICMP
TTL=2 -> 第二跳 TTL 归零 -> 返回 ICMP
TTL=3 -> 第三跳 TTL 归零 -> 返回 ICMP

traceroute 就是利用这个机制，把 TTL 从 1 逐步增加，拼出到目标的路径。它不是让路由器主动汇报路径，而是用一组探测包“逼”每一跳露面。

二、traceroute 的输出怎么看

典型输出每行是一跳，后面是该跳的几个探测 RTT。比如某一跳显示 3 个时间，是因为默认发了 3 个探测包。

 1  192.168.1.1     1.2 ms   1.0 ms   1.1 ms
 2  10.1.0.1        5.5 ms   5.4 ms   5.6 ms
 3  * * *
 4  203.0.113.10   30.1 ms  31.0 ms  29.8 ms

第三跳不返回，不代表第三跳后面一定断了。因为第四跳仍然出现，说明探测包可以继续往后走，只是第三跳不愿或来不及回 ICMP。

三、mtr 比 traceroute 多什么

mtr 会持续对每一跳发探测，统计丢包率、平均延迟、最差延迟和抖动。它更适合观察不稳定问题。

工具特点适合场景
traceroute一次性路径快照快速看路径
mtr持续统计排查间歇性丢包/抖动
ping只看目标判断目标整体连通和延迟

如果问题是“偶尔卡 5 秒”，一次 traceroute 可能刚好没抓到，mtr 跑 3 到 5 分钟更有价值。

四、如何判断真实丢包

中间路由器可能对 ICMP 回复限速，所以某一跳显示 80% 丢包，但后续跳和目标不丢包，这通常不是业务流量真实丢包。

hop 5: 80% loss
hop 6: 0% loss
target: 0% loss

真正要关注的是“从某一跳开始，后续所有跳都持续丢包”。如果 hop 8 开始丢 20%，hop 9、hop 10、目标也都丢 20%，问题更可能在 hop 8 附近或其后链路。

五、延迟升高也要看是否持续

某一跳延迟很高，但后续跳又恢复正常，也可能只是该路由器处理 ICMP 慢，并不表示转发慢。路由器转发数据包走硬件快路径，回复 ICMP 可能走慢路径。

hop 6: 200ms
hop 7: 30ms
target: 31ms

这种情况不能直接判定 hop 6 是瓶颈。只有从某一跳开始后续延迟都升高，才更值得怀疑路径拥塞或跨地域绕路。

六、不同协议的 traceroute

Linux traceroute 默认可能用 UDP，Windows tracert 常用 ICMP，有些工具可用 TCP traceroute。不同网络设备和防火墙对 ICMP、UDP、TCP 的处理不同，所以结果可能不一样。

ICMP blocked, TCP 443 allowed
traceroute may fail
tcptraceroute 443 may show path

排查 Web 服务时，TCP 443 探测有时比 ICMP 更贴近真实业务流量。

七、跨运营商和云网络排查

公网路径可能经过多个运营商、IXP、云厂商骨干网和 CDN 节点。看到某个公网 IP 不代表一定知道它属于哪一方，需要结合 whois、云监控、运营商信息和双向探测。

client -> ISP A -> backbone -> cloud edge -> target
target -> cloud edge -> ISP B -> client

网络路径可能不对称，去程正常不代表回程正常。严重问题要从客户端和服务端两端分别跑 mtr。

记忆钩子：看 mtr 不看“单跳吓人”，要看异常是否从某一跳开始向后持续传染。

八、常见误区与追问

  • 误区：某一跳星号就说明这里断了。 后续跳能到达时，星号多半是该跳不回探测包。
  • 误区：中间一跳丢包高就一定是故障点。 如果后续跳不丢包，常见原因是 ICMP 限速。
  • 误区：traceroute 路径就是业务 TCP 路径。 探测协议、负载均衡和策略路由可能让路径不同。
  • 追问：为什么要双向 mtr？ 网络路径可能不对称，回程问题在单向探测里看不出来。
  • 追问：mtr 要跑多久？ 间歇性问题至少跑几分钟，覆盖故障发生窗口。
  • 追问：延迟从某跳突然升高怎么看？ 看后续跳是否持续升高，持续才更像真实瓶颈。
  • 追问：Web 访问慢用哪种探测更贴近业务？ TCP 80/443 探测通常比纯 ICMP 更贴近。

九、加强记忆

traceroute 和 mtr 的核心是用 TTL 递增观察路径。真正会看结果的人，不会被单跳星号、单跳高延迟、单跳高丢包吓住，而是看异常是否在后续跳持续出现。排公网问题时再加上 TCP 探测、双向 mtr 和业务端口验证，才能把“路由器不回包”和“链路真的有问题”分开。