网络问题如何排查？mtr命令详解

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的用法

1. Usage:
2. mtr [options] hostname
4. -F, --filename FILE              从文件中读取hostname(s)
5. -4                               使用IPv4
6. -6                               使用IPv6
7. -f, --first-ttl NUMBER           起跳ttl参数，跳过前面的N-1跳，只只显示TTL=N后的跳（不改变真实路由，只是不显示）
8. -m, --max-ttl NUMBER             maximum number of hops
9. -u, --udp                        使用UDP 替代 ICMP echo
10. -T, --tcp                        使用 TCP 替代ICMP echo
11. -P, --port PORT                  使用TCP、SCTP或UDP探测时的目标端口
12. -s, --psize PACKETSIZE           设置探测包的 payload 大小（字节）
13. -i, --interval SECONDS           设置探测包的 发送间隔
14. -r, --report                     报告模式（一次性输出，不刷新）
15. -w, --report-wide                报告模式，宽屏对齐输出（字段不截断）
16. -c, --report-cycles COUNT        发送探测包次数，设置20快速判断，设置100较为可信
17. -j, --json                       以json格式输出
18. -x, --xml                        以xml格式输出
19. -C, --csv                        以csv格式输出
20. -l, --raw                        以原始格式输出
21. -n, --no-dns                     不做反向dns解析(只显示ip)
22. -y, --ipinfo NUMBER              输出 IP 归属信息（国家 / 运营商）

复制代码

在linux上执行mtr时，mtr会直接操作网络层构造IP/ICMP报文，所以一般需要使用sudo执行
示例：
sudo mtr -r -n -c 100 www.baidu.com
输出结果:

1. Start: 2026-01-15T19:00:01+0800
2. HOST: LTB-MBP.local               Loss%   Snt   Last   Avg  Best  Wrst StDev
3.   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结果为例:

1. root@localhost:~# mtr -r www.google.com
2. HOST: example                       Loss%   Snt   Last  Avg  Best  Wrst   StDev
3.    1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
4.    2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
5.    3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
6.    4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
7.    5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
8.    6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
9.    7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
10.    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 响应类型来判断：

1. 中间跳返回：ICMP Type 11 (Time Exceeded)
2.             → "TTL 耗尽，我不是目标"
3.             → 继续增加 TTL 探测下一跳
5. 最后一跳返回：ICMP Type 0 (Echo Reply)
6. 或 ICMP Type 3 (Destination Unreachable)
7.             → "我就是目标主机"
8.             → 停止探测

复制代码

过程可以类比快递配送链路：

• 中间转运站（路由器）：可能不会告诉你"包裹经过了这里"（限制或完全不响应ICMP Time Exceeded）
  
• 最终收货点（目标主机）：必须签收并确认"收到了"（响应ICMP Echo Reply）
  

即使中间转运站不告诉你进度，只要最后收到包裹并有签收确认，就说明整条链路是通的。
真实的丢包场景

以下面的MTR结果为例：

1. root@localhost:~# mtr -r www.google.com
2. HOST: localhost                      Loss%   Snt   Last  Avg  Best  Wrst   StDev
3.    1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
4.    2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
5.    3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
6.    4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
7.    5. 72.14.233.56                  50.0%    10    7.2   8.3   7.1  16.4   2.9
8.    6. 209.85.254.247                40.0%    10   39.1  39.4  39.1  39.7   0.2
9.    7. 64.233.174.46                 40.0%    10   39.6  40.4  39.4  46.9   2.3
10.    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结果为例：

1. root@localhost:~# mtr --report www.google.com
2. HOST: localhost                      Loss%   Snt   Last   Avg  Best  Wrst  StDev
3.     1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
4.     2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
5.     3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
6.     4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
7.     5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
8.     6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
9.     7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
10.     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报告为例：

1. root@localhost:~# mtr --report www.google.com
2. HOST:  localhost                     Loss%   Snt   Last  Avg  Best  Wrst   StDev
3.     1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
4.     2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
5.     3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
6.     4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
7.     5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
8.     6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
9.     7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
10.     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限速
  

1. # ICMP 模式失败
2. mtr api.example.com
3. → 大量 "waiting for reply" 或 100% 丢包
5. # 改用 TCP 模式（测试 443 端口）
6. mtr -T -P 443 api.example.com
7. → 正常显示路由路径

复制代码

• 场景 2：测试特定服务的网络质量
  

1. # 测试 HTTPS 服务（443 端口）
2. mtr -T -P 443 api.example.com
4. # 测试 HTTP 服务（80 端口）
5. mtr -T -P 80 www.example.com
7. # 测试 SSH 服务（22 端口）
8. mtr -T -P 22 server.example.com
10. # 测试数据库（3306 端口）
11. mtr -T -P 3306 db.example.com

复制代码

mtr使用TCP协议进行网络检测的过程是通过 TCP三次握手的前两步完成的

1. Client → SYN (dst port 443, TTL=N)
2. Server → SYN-ACK
3. Client → RST   （立刻）

复制代码

mtr的TCP模式只完成“三次握手的前两步”，并在收到响应后立刻主动 RST，不会建立真正的TCP连接，更不会形成大量的ESTABLISHED 连接，对目标主机性能几乎没有影响。
什么时候使用UDP模式？

• 场景 1：测试 UDP 应用
  

1. # 测试 DNS 服务（53 端口）
2. mtr -u -P 53 8.8.8.8
4. # 测试 VoIP/视频会议（如 10000-20000 端口范围）
5. mtr -u -P 16384 meeting.example.com
7. # 测试游戏服务器
8. mtr -u -P 27015 game.example.com
10. # 测试 VPN（如 OpenVPN，1194 端口）
11. mtr -u -P 1194 vpn.example.com

复制代码

• 场景 2：ICMP 被限流但 UDP 没有
  

1. # 某些网络对 ICMP 限流但允许 UDP
2. mtr -u api.example.com

复制代码

小结

有了 mtr 之后，当客户反馈诸如：“我们办公室是千兆宽带、Wi-Fi 也是满格，就是你们的产品不行，页面加载慢、接口响应慢”这类问题时，不必慌张。
拉上客户一起跑一跑 mtr，把链路情况和丢包率、延迟摆出来，沿途每一跳的网络状态都会清清楚楚地呈现在眼前。问题究竟出在本地网络、运营商链路，还是服务器侧，基本就一目了然了。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！