## 适用场景
ping 只告诉你通不通、总体延迟多少，丢包与抖动发生在哪一段一无所知。mtr 结合了 traceroute 的逐跳发现与 ping 的持续探测，每一跳的丢包率、延迟均值与波动同时呈现，是判断链路质量、定位劣化段的主力工具。顺云云服务器到源站、到对端的链路体检，mtr 是第一选择。
## 步骤清单
交互模式直接运行即可实时观察，报告模式更适合留档与对比：r 输出报告、z 显示每跳的 DNS 反查、b 同时显示 IP 与主机名、c 指定探测包数量、w 用报告模式下更真实的计时方式。
mtr -rwzbc 100 203.0.113.20
数量给到一百才能得到有统计意义的丢包率，探测几十个包得出的结论不可靠。
## 验证方法
读报告先看最后一跳：终点丢包率代表真实到达质量，是唯一硬指标。中间某跳丢包率高但后续跳恢复正常，多半是该节点对探测包限速，属于常见现象，不代表链路有问题；从某一跳开始丢包一直持续到终点，那一跳附近才是问题段。延迟列看 Last、Avg、Best、Wrst、StDev 五列，标准差大说明抖动明显，对实时业务的影响不亚于丢包。
反向验证同样重要：链路两个方向的路径与质量可能完全不同，双向各跑一份报告对比，单向劣化立刻现形。
## 注意事项
云环境与运营商设备普遍限制探测包速率，包数给足但别把间隔压得太密，以免测出自己制造的限速。报告要附上时间与方向留档，链路问题的工单沟通里，两份不同时段的对比报告远比一句很卡有说服力。
进阶一点的习惯是建立基线对照：对关键对端定期自动跑一次报告模式存档，形成按日的链路档案。劣化发生时调出前几天的档案对比，从哪天开始、哪一跳先变差一目了然，这对工单沟通与趋势判断的价值远大于单次快照。报告里记录本机与对端的地址与方向，半年后翻档案时才对得上号。把 mtr 与 ss 的重传观测搭配使用，丢包定位与连接层印证互相支撑。