在 traceroute 输出结果中，每行开头的数字表示路径经过的跳数（Hop），而后面的三个毫秒数值（例如“1.234 ms 1.456 ms 1.678 ms”）才代表该跳的往返时延（RTT）。如果看到“*”，说明当前节点没有响应 ICMP 超时消息，这通常与防火墙策略、限速或丢弃探测包有关，并不一定表示网络已经中断。
traceroute 输出里哪一列代表跳数延迟
在 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 以上高位端口，往往更容易被拦截或过滤。将 traceroute 参数切换为 -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 的静态输出会更直观
