Linux怎么查看网络路径跳数延迟追踪

traceroute输出中每行开头的数字代表跳数（Hop），其后三个毫秒值（如“1.234 ms 1.456 ms 1.678 ms”）才是该跳的往返延迟（RTT）；出现“*”表示该节点未响应ICMP超时包，可能因防火墙策略丢包而非断连。

traceroute 输出里哪一列代表跳数延迟

每一行最前面的数字，表示的就是第几跳（Hop）；后面紧跟着的三个毫秒值，才是这一跳真正需要关注的往返时延。中间出现的 IP 或主机名，很容易让人分神，但判断网络情况时，重点其实在那三组 xx.xxx ms 上——它们对应的是三次彼此独立的探测结果，也就是 RTT（Round-Trip Time）。至于某一跳里出现 *，含义也别理解错了：这通常只是该节点没有返回 ICMP 超时包，并不代表链路已经中断，更常见的情况是策略层面的丢包或限制响应。

• 第一跳延迟异常高（比如 >50ms），大概率是本地网关或家用路由器负载高，重启常能缓解
• 连续几跳延迟缓慢爬升，但增幅平缓（如 1ms → 3ms → 6ms → 12ms），属于正常 TTL 递增累积，不用紧张
• 某跳突然从 10ms 跳到 180ms，且后续跳数维持高位，问题就卡在这台设备或它的出向链路
• 最后一跳延迟高，但前面都正常，基本可排除路径问题，目标服务器本身可能响应慢或禁 ping

为什么 traceroute -n 是必须加的参数

默认 traceroute 会对每个返回的 IP 做反向 DNS 查询，这会拖慢整个过程，尤其在跨国路径或 DNS 不稳时，某跳可能卡住好几秒才继续，甚至因解析失败把整行显示成 ??? 或空字段。加 -n 后输出全是 IP，执行快、结果干净、时间戳可靠。

• 云主机、Kubernetes Pod、内网环境基本都没配反向 DNS，不加 -n 纯属浪费时间
• 某些防火墙会故意让 DNS 查询超时，导致 traceroute 误判某跳“无响应”，实际只是解析卡住
• -n 和 -I、-q 5、-w 2 组合使用最稳妥：traceroute -n -I -q 5 -w 2 example.com

ICMP 模式（-I）比默认 UDP 更容易穿透防火墙

现实里，这种情况其实很常见：不少企业出口、云平台安全组以及运营商设备，默认会放行 ICMP Echo Reply（也就是 ping 回包），但对 UDP 端口往往卡得更严，尤其是 traceroute 默认使用的 33434+ 这类高位端口更容易被拦截。把参数切到 -I 的 ICMP 模式之后，普通用户权限就可以直接运行，不必再用 sudo，而且整体响应率通常也会更高。

• 遇到某跳全 * 但下跳又能通，优先试 -I；如果还是 *，再考虑 -T（TCP 模式）
• -I 发的是 ICMP Echo Request，和 ping 协议一致，更容易被中间设备识别为管理流量而非攻击
• 注意：部分老旧设备或严格策略环境可能禁 ICMP，此时 -T 才是兜底方案，但需 root 权限

mtr 比 traceroute 更适合定位抖动和间歇性丢包

traceroute 是单次快照，mtr 是持续观测——它每秒发包、实时刷新，能暴露 traceroute 容易漏掉的波动问题。关键看三列：Loss%（非 0 就可疑）、A vg（连续 ≥100ms 要查）、StDev（标准差 >30ms 说明抖动大）。

• 某跳 A vg 看着正常（20ms），但 Wrst 突然飙到 450ms，说明存在队列拥塞或 QoS 限速
• mtr -r -c 20 -n example.com > report.txt 可生成静态报告，方便发给 ISP 或协作排查
• 交互模式下按 d 切延迟视图、按 l 看丢包图表，比盯着 traceroute 的静态文本直观得多