如何使用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的用法 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，把链路情况和丢包率、延迟摆出来，沿途每一跳的网络状态都会清清楚楚地呈现在眼前。问题究竟出在本地网络、运营商链路，还是服务器侧，基本就一目了然了。