MTR 通过聚合多次 traceroute 结果，能更准确定位丢包节点；本文以 MTR 输出为例，说明 ICMP 探测比 UDP 更可靠，并逐字段拆解 Loss%、Snt、延迟统计等关键指标的含义与判读陷阱。
探测类型与可靠性
traceroute 与 MTR 均支持 UDP 与 ICMP 两种探测模式，原理均是发送递增 TTL 的数据包，利用路由器返回的 TTL exceeded ICMP 报文构建路径。作者实测表明 ICMP 模式触发回复的概率更高：traceroute 需显式加 -I 参数启用 ICMP，而 MTR 默认即为 ICMP，建议优先使用 ICMP 追踪以减少 ??? 节点。
MTR 核心字段解读
MTR 逐跳输出包含：主机名或 IP（-n 可禁用解析）、Loss% 丢包率、Snt 发送包数、Last/Avg/Best/Wrst/StDev 五项往返时延统计。示例中第 2 跳显示 ???，仅表示该路由器未回复 TTL exceeded，若后续跳点丢包率为 0% 且延迟正常，通常可忽略；真正需关注的是某跳 Loss% 持续非零且后续跳点同步升高的情况。
判读常见误区
单次 traceroute 仅能展示路径，无法量化丢包；MTR 持续运行才能揭示间歇性拥塞。注意：某跳延迟抖动大但丢包为 0，多为队列排队延迟而非链路故障；若某跳 Loss% 100% 但后续跳点正常，通常是该路由器限制 ICMP 速率而非真丢包。务必结合端到端业务表现综合研判。
运维人员应养成「先跑 MTR -n -c 100 目标 IP，再对比业务端感知」的排查习惯，重点核对持续非零 Loss% 与后续跳点延迟阶跃，避免被单跳抖动或 ICMP 限速误导，快速定位真实故障域。
原文: APNIC Blog（2022-03-28）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog