mtr 是什么
mtr 把 ping 与 traceroute 合成一个工具：它像 traceroute 一样逐跳探测路径，又像 ping 一样对每一跳持续发包并累计统计，于是每一跳的丢包率、最小时延、最大时延与抖动都摆在同一条水平线上。判断『从哪一跳开始变差』这件事，它几乎是最快的工具。交互模式下实时刷新界面，报告模式适合把结论留档或被脚本采集。
基本信息
| 适用平台 | Linux/macOS 需安装 mtr 包；Windows 可用 WinMTR 等移植版本 |
|---|---|
| 默认探测方式 | ICMP 回显；用 -T -P 端口 可切换为 TCP 探测，穿透只放行特定端口的策略 |
| 运行模式 | 交互模式实时刷新，报告模式跑完指定轮数后输出一张表 |
| 权限 | 普通用户可用；部分模式与参数需要 root |
| 统计建议 | 丢包判断至少跑一百轮，样本太少结论不稳 |
典型使用场景
- 定位丢包起点：观察 Loss% 从哪一跳开始非零零并延续到终点
- 区分内网与运营商问题：前几跳干净、出口之后开始恶化，责任边界清晰
- 评价链路抖动：结合 Avg、Wrst 与 StDev 判断时延是否稳定
- 长时采证：报告模式跑几百轮，把结果贴给线路供应商作为依据
- 验证整改效果：调整线路后重跑，比对同一目标的丢包与时延是否恢复
交互与报告模式
交互与报告模式
mtr 8.8.8.8 # 交互界面，按 q 退出
mtr -r -c 100 -n 8.8.8.8 # 报告模式：100 轮后输出表格，不解析名称
mtr -r -c 100 -w -n 8.8.8.8 # 宽报告，完整显示主机名或地址列
mtr -r -c 200 -z -n 8.8.8.8 # 附带自治域信息，便于判断归属运营商
mtr -T -P 443 -r -c 100 -n example.com # 用 TCP 443 探测，绕开被拦的 ICMP报告模式输出示例
报告模式输出示例
HOST Loss% Snt Last Avg Best Wrst StDev
1. 10.0.0.1 0.0% 100 0.4 0.5 0.3 1.2 0.1
2. 10.0.1.1 0.0% 100 1.2 1.3 1.0 3.4 0.3
3. 202.x.x.x 8.0% 100 12.1 13.0 11.8 95.0 15.2
4. 目标地址 8.0% 100 12.5 13.2 12.0 97.4 14.9 # 终点同样丢包才是真丢包输出逐列读法
| 列 | 含义 | 异常表现 |
|---|---|---|
| Loss% | 该跳的丢包百分比 | 只中间跳丢而终点正常，通常是设备限速或不回包 |
| Snt | 已发送并参与统计的探测轮数 | 轮数太少时百分比没有统计意义 |
| Last | 最近一次探测的往返时延 | 单点数值波动大，参考价值低于平均值 |
| Avg | 平均往返时延 | 某一跳后整体抬升说明瓶颈在其之后 |
| Best / Wrst | 最小与最大往返时延 | 最大与最小差距悬殊说明队列堆积或抖动 |
| StDev | 时延标准差，衡量稳定性 | 数值接近平均值说明路径极不稳定 |
判读口诀：丢包从哪一跳开始、之后是否延续。中间跳单独丢包而后续几跳不再丢，多半是该设备不回应探测；只有终点持续丢包才是真实丢包。
TCP 模式（-T 配 -P 指定端口）在只放行业务端口的网络里更可信，但设备可能对探测与真实业务做不同处理，最终结论仍要结合业务侧观察。
丢包位置判读
| 现象 | 含义 | 处理方向 |
|---|---|---|
| 中间某跳丢包，后续各跳与终点均无丢包 | 该设备对探测报文限速或不回应 | 不作为故障上报，继续看终点数据 |
| 从某一跳起丢包并延续到终点 | 该跳之后存在真实丢包 | 锁定该跳与上一跳之间的链路，联系对应管理方 |
| 终点丢包但中间跳干净 | 目标侧拥塞或本机出口问题 | 换来源与目标做交叉测试，确认丢包在哪一侧 |
| 全程偶发丢包且与时间相关 | 链路拥塞、无线干扰或对端限速 | 延长采样时间并对齐业务高峰时间线 |
把中间跳的丢包率直接报给线路供应商，常被回复设备对探测限速；有说服力的证据是终点的丢包率与业务可观测的重传情况。