mtr 命令详解
更新时间：2026-08-28。本文是「一个命令一个文档」系列，聚焦
mtr——网络基础命令族（见网络基础与远程访问命令族）。它把 traceroute 和 ping 揉在一起：一边描路径，一边持续统计每一跳的丢包和延迟。
mtr（My TraceRoute）持续向目标发送探测包，实时显示从本机到目标每一跳的丢包率与延迟曲线。它比一次性 traceroute 更能暴露"间歇性"问题。
一、基本用法
bash
mtr example.com # 交互式实时刷新每跳统计
mtr -n example.com # -n 不解析主机名，只显示 IP
mtr -r -c 100 example.com # -r 报告模式（非交互），发 100 包后输出汇总，适合记录留证
mtr -T -P 443 example.com # -T 用 TCP（默认 UDP/ICMP），-P 指定端口交互模式默认每秒一包，实时滚动每跳的 Loss%（丢包）和 Avg/Last/ Best/Wrst 延迟。要留证据或写进排障报告，用
-r -c N跑完出静态汇总。
二、读关键列
text
Host Loss% Snt Last Avg Best Wrst StDev
1. gateway 0.0% 100 1.2 1.5 1.0 3.0 0.4
3. isp-router 12.0% 100 22.4 25.1 20.0 60.2 8.1 ← 这一跳开始丢包
4. backbone 0.0% 100 23.0 24.0 21.0 55.0 7.0关键看 Loss%：如果某一跳有丢包但后续跳丢包又归零，通常是该跳设备"限速回 ICMP"造成的假象（策略性丢弃探测包），不代表真实业务丢包。真正的问题跳是"丢包从这一跳开始并延续到终点"的那一跳。延迟看 Avg/Wrst，Wrst 高说明有突发抖动。
三、mtr vs traceroute vs ping
| 命令 | 特点 |
|---|---|
| ping | 只测端到端，无路径 |
| traceroute | 路径快照，单次 |
mtr | 路径 + 持续统计每跳丢包/延迟 |
想确认"某跳是不是真在丢包、是不是间歇性"，mtr 是最佳工具——traceroute 一次的
*说明不了问题，mtr 跑 100 包看 Loss% 才有说服力。
四、踩坑：中间跳丢包未必是真问题
bash
# 第 3 跳 Loss 15% 但第 4、5 跳都是 0%，多半是该跳限速回探测包
# 业务实际走的是后续跳，真实丢包看"最后一跳之前持续的那段"这是读 mtr 最容易误判的点：ICMP 探测包常被中间路由器优先级调低甚至丢弃，造成"假丢包"。判断标准是丢包是否延续到终点——中间跳孤立的丢包通常可忽略。
五、实战：证明"不是我们机房的问题"
bash
mtr -r -c 200 -n customer-site.com > mtr-report.txt # 留存报告给客户/上游运营商一句话总结
mtr = traceroute + 持续 ping：实时/报告模式统计每跳丢包率与延迟，-T -P 走 TCP 端口；定位网络瓶颈跳首选。读 Loss% 时记住：中间跳孤立丢包多为设备限速假象，真正问题看丢包是否延续到终点。单次路径用 traceroute，端到端用 ping。