mtr
mtr命令是一个网络诊断工具，用于检测网络的连通性和延迟。MTR是My Traceroute的缩写，是traceroute和ping命令的结合体。
mtr默认使用ICMP协议，在介绍mtr的详细用法前我们先了解下ICMP协议。
IMCP
ICMP（Internet Control Message Protocol，互联网控制报文协议）
是一种网络层（OSI 第三层）协议，主要用于在 IP 网络中传递控制信息和错误信息，而不是用来传输业务数据。
ICMP的作用是：
1、网络连通性测试
最常用的就是ping命令，发送的是ICMP Echo Request，对方回复ICMP Echo Reply，用来判断网络是否可达、是否丢包以及延迟
2、网络故障和错误反馈
当 IP 包在传输过程中出现问题时，ICMP 会返回错误信息，例如：
| 场景 | ICMP 类型 |
|---|---|
| 目标主机不可达 | Destination Unreachable |
| 路由中 TTL 用尽 | Time Exceeded |
| 需要分片但禁止分片 | Fragmentation Needed |
例如：路由器发现下一跳不可达时就会被源主机发送一个ICMP不可达报文
3、网络路径诊断
traceroute和tracert就是通过ICMP实现的
mtr的用法
Usage:
mtr [options] hostname
-F, --filename FILE 从文件中读取hostname(s)
-4 使用IPv4
-6 使用IPv6
-f, --first-ttl NUMBER 起跳ttl参数，跳过前面的N-1跳，只只显示TTL=N后的跳（不改变真实路由，只是不显示）
-m, --max-ttl NUMBER maximum number of hops
-u, --udp 使用UDP 替代 ICMP echo
-T, --tcp 使用 TCP 替代ICMP echo
-P, --port PORT 使用TCP、SCTP或UDP探测时的目标端口
-s, --psize PACKETSIZE 设置探测包的 payload 大小（字节）
-i, --interval SECONDS 设置探测包的 发送间隔
-r, --report 报告模式（一次性输出，不刷新）
-w, --report-wide 报告模式，宽屏对齐输出（字段不截断）
-c, --report-cycles COUNT 发送探测包次数，设置20快速判断，设置100较为可信
-j, --json 以json格式输出
-x, --xml 以xml格式输出
-C, --csv 以csv格式输出
-l, --raw 以原始格式输出
-n, --no-dns 不做反向dns解析(只显示ip)
-y, --ipinfo NUMBER 输出 IP 归属信息（国家 / 运营商）在linux上执行mtr时，mtr会直接操作网络层构造IP/ICMP报文，所以一般需要使用sudo执行
示例：
sudo mtr -r -n -c 100 www.baidu.com
输出结果:
Start: 2026-01-15T19:00:01+0800
HOST: LTB-MBP.local Loss% Snt Last Avg Best Wrst StDev
1.|-- 183.2.172.177 0.0% 100 2.0 1.8 0.4 26.2 3.4| 字段 | 含义 | 解读要点 |
|---|---|---|
HOST |
当前跳主机 | * 代表无响应 |
Loss% |
丢包率 | 核心指标 |
Snt |
发送包数 | 统计样本量 |
Last |
最近一次延迟 | 波动参考 |
Avg |
平均延迟 | 主要看 |
Best |
最小延迟 | 理想情况 |
Wrst |
最大延迟 | 是否有抖动 |
StDev |
抖动 | 越小越稳定 |
ICMP限速
分析MTR输出时，需要关注两个方面：丢包率 和延迟 。如果在某个跳点看到一定程度的丢包，这可能说明该路由器有问题。然而，一些服务提供商普遍会限制MTR使用的ICMP响应速率。这可能会让人误以为丢包，实际上并没有丢包。要判断看到的丢包是真实的还是速率限制引起的，可以看看后续跳跃。如果跳跃显示损失为0.0%，那么很可能是因为：ICMP响应速率限制导致的而非真实的丢包，以下面的MTR结果为例:
root@localhost:~# mtr -r www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2第二跳的丢包率虽然是 50%，但是其后续跳没有丢包且最终能到到达第8跳，所以整个链路实际上通的，第二跳的丢包率是因为ICMP限速导致的。
可能有的同学会有疑问了，难道最后一跳不会出现ICMP限速吗？
实际上，mtr发送数据包后，会根据收到的 ICMP 响应类型来判断：
中间跳返回：ICMP Type 11 (Time Exceeded)
→ "TTL 耗尽，我不是目标"
→ 继续增加 TTL 探测下一跳
最后一跳返回：ICMP Type 0 (Echo Reply)
或 ICMP Type 3 (Destination Unreachable)
→ "我就是目标主机"
→ 停止探测过程可以类比快递配送链路：
- 中间转运站（路由器）：可能不会告诉你"包裹经过了这里"（限制或完全不响应ICMP Time Exceeded）
- 最终收货点（目标主机）：必须签收并确认"收到了"（响应ICMP Echo Reply）
即使中间转运站不告诉你进度，只要最后收到包裹并有签收确认，就说明整条链路是通的。
真实的丢包场景
以下面的MTR结果为例：
root@localhost:~# mtr -r www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2在这个示例中，第三跳的丢包率高达60%且后续跳均出现了丢包率并且影响了最后的第8跳，所以可以判断第三跳是有问题的。由于中间跳ICMP限速和真实丢包会同时发生，所以会出现中间跳的丢包率高于最后一跳丢包率。
当判断确实出现了丢包时，最好使用MTR双向测试下，因为数据包可能是发送时遇到了问题，也可能是在返回响应时出现了问题。
延迟
MTR还能测试主机与目标主机之间连接的延迟。由于物理约束，延迟总是随着路由跳数的增加而增加。然而，增长应保持一致且线性。延迟通常是相对的，并且很大程度上取决于主机连接的质量及其物理距离。 在评估可能有问题的连接的 MTR 报告时，除了给定区域中其他主机之间的已知连接速度之外，还应将早期的功能齐全的报告视为上下文。
以下面的MTR结果为例：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2在第3跳和第4跳之间延迟突然增高，并且在后续跳中仍然很高，这可能表明存在网络延迟问题。
但是，高延迟并不总是意味着当前路由有问题。 像上面这样的报告意味着，尽管第四跳存在某种问题，流量仍然到达目标主机并返回源主机。 延迟也可能是由返回路线问题引起的。 返回路线不会在 MTR 报告中看到，并且数据包可以采用完全不同的路线往返于特定目的地。
在上面的示例中，虽然在第3跳和第4跳之间的延迟存在较大跳跃，但在任何后续跳中延迟并没有再增高。 由此，可以合理地假设第四个路由器存在问题。
ICMP限速也会导致延迟增加，以下面的MTR报告为例：
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2乍一看，第4跳和第5跳之间的延迟突然增高了。然而，在第五跳之后，延迟急剧下降。这里测得的实际延迟约为40ms，且并没有影响最后一条的延迟，网络实际上是没有问题的。
什么时候需要使用TCP和UDP协议进行检测？
三种协议的对比
| 协议 | 默认使用场景 | 优点 | 缺点 |
|---|---|---|---|
| ICMP | 默认模式 | 最常用,大多数设备支持 | 容易被防火墙过滤 |
| UDP | 测试 UDP 服务 | 模拟真实 UDP 流量 | 可能被过滤,不可靠 |
| TCP | 测试 Web/API 服务 | 最接近真实应用流量,不易被过滤 | 需要指定端口 |
什么时候使用TCP模式？
-
场景 1：ICMP被防火墙屏蔽或ICMP限速
ICMP 模式失败
mtr api.example.com
→ 大量 "waiting for reply" 或 100% 丢包改用 TCP 模式（测试 443 端口）
mtr -T -P 443 api.example.com
→ 正常显示路由路径 -
场景 2：测试特定服务的网络质量
测试 HTTPS 服务（443 端口）
mtr -T -P 443 api.example.com
测试 HTTP 服务（80 端口）
mtr -T -P 80 www.example.com
测试 SSH 服务（22 端口）
mtr -T -P 22 server.example.com
测试数据库（3306 端口）
mtr -T -P 3306 db.example.com
mtr使用TCP协议进行网络检测的过程是通过 TCP三次握手的前两步完成的
Client → SYN (dst port 443, TTL=N)
Server → SYN-ACK
Client → RST （立刻）mtr的TCP模式只完成"三次握手的前两步"，并在收到响应后立刻主动 RST，不会建立真正的TCP连接，更不会形成大量的ESTABLISHED 连接，对目标主机性能几乎没有影响。
什么时候使用UDP模式？
-
场景 1：测试 UDP 应用
测试 DNS 服务（53 端口）
mtr -u -P 53 8.8.8.8
测试 VoIP/视频会议（如 10000-20000 端口范围）
mtr -u -P 16384 meeting.example.com
测试游戏服务器
mtr -u -P 27015 game.example.com
测试 VPN（如 OpenVPN，1194 端口）
mtr -u -P 1194 vpn.example.com
-
场景 2：ICMP 被限流但 UDP 没有
某些网络对 ICMP 限流但允许 UDP
mtr -u api.example.com
小结
有了 mtr 之后，当客户反馈诸如："我们办公室是千兆宽带、Wi-Fi 也是满格，就是你们的产品不行，页面加载慢、接口响应慢"这类问题时，不必慌张。
拉上客户一起跑一跑 mtr，把链路情况和丢包率、延迟摆出来，沿途每一跳的网络状态都会清清楚楚地呈现在眼前。问题究竟出在本地网络、运营商链路，还是服务器侧，基本就一目了然了。