mtr 是什么
mtr 把 ping 与 traceroute 合在一起：持续向目标发送探测包，统计路径上每一跳的丢包率与延迟分布。判定的关键在于「从哪一跳开始丢、是否一直持续到终点」：中间某一跳单独丢包，多数是该设备对 ICMP 做了限速，不能作为故障依据；只有从某跳开始丢包并延续到终点，才说明这一段路径存在问题。
基本信息
| 报告模式 | mtr -rwzc 20 203.0.113.10 |
|---|---|
| TCP 探测 | mtr -T -rwzc 20 -P 443 203.0.113.10 |
| 采样次数 | -c 指定，次数越多结论越稳 |
| 输出形式 | -j 输出 JSON，便于前后对比 |
| 解析地址 | -z 显示主机名，排查时更直观 |
典型使用场景
- 跨地域访问慢，定位是哪一段路径引入延迟
- 间歇性丢包，判断是否固定在某一跳之后
- 确认某个网段的可达性与路由走向是否符合预期
- 业务变更前后对比同一目标的路径与延迟
- 向运营商报障前准备逐跳证据
常用命令
常用命令
mtr -rwzc 20 203.0.113.10 # 报告模式，20 次采样后输出
mtr -T -rwzc 20 -P 443 203.0.113.10 # 用 TCP 443 探测，绕开 ICMP 限制
mtr -rwzc 100 203.0.113.10 # 拉长采样再下结论
mtr -j -c 20 203.0.113.10 > path.json # 保存 JSON，便于与后续结果对比现象与结论
| 现象 | 含义 | 能否作为故障依据 |
|---|---|---|
| 中间跳单独丢包 | 该设备对 ICMP 限速 | 不能，属正常现象 |
| 某跳起持续丢到终点 | 该段路径存在丢包 | 可以作为依据 |
| 末跳丢包率非零 | 目标主机或最后一段有问题 | 结合目标侧检查 |
| 各跳延迟均匀升高 | 链路时延本身较长 | 不是丢包问题 |
判读顺序
- 先看末跳结果，确认目标是否整体可达
- 再看丢包从哪一跳开始，是否持续到终点
- 中间单跳丢包直接忽略，不要写进结论
- 换一种探测方式复核，例如用 TCP 端口探测替代 ICMP
ICMP 与应用流量可能走不同路径，也可能被中间设备区别对待。业务是 HTTPS 时用 -T -P 443 探测，得到的结论更贴近真实流量。
单次结果受瞬时波动影响很大，延迟与丢包结论都应基于足够多次的采样，并记录采样时间窗口。