当使用ping命令测试时出现丢包或网络不通，可以通过链路测试工具定位问题原因。本文介绍如何使用MTR工具进行链路测试，并提供分析结果的思路。
测试流程
通常情况下，链路测试流程如下图所示。
您可以访问IP地址查询 - IPLark等网站，获取本地网络对应的公网IP地址。
目标服务器指代目标服务的域名或者公网IP地址。
工具介绍
MTR是一款网络诊断工具，其将ping和traceroute的功能合并，相对于traceroute只会做一次链路跟踪测试，mtr会对链路上的相关节点做持续探测并给出相应的统计信息。因此，mtr能避免节点波动对测试结果的影响，所以其测试结果更准确。
如果您使用Linux系统，您可以通过安装mtr软件包来使用mtr。对于Windows系统，您可以选择使用WinMTR。有关以上两种工具的安装及使用说明，请参考如下介绍。
mtr（Linux）
安装说明
CentOS 6/7/8
Ubuntu/Debian
使用介绍
命令格式
mtr命令的格式如下所示，其中hostname指代服务域名，ip指代服务的公网ip地址。
mtr [options] hostname/ip参数说明
常见的可选参数说明如下表所示，您也可以通过man mtr命令查看更多参数说明。
可选参数 | 参数说明 |
| 以报告模式显示输出。 |
| 将每次链路跟踪的结果分别列出来。 |
| 指定ping数据包的大小。 |
| 不对IP地址做域名反解析。 |
| 设置发送数据包的IP地址。 说明 该参数用于主机存在多个IP地址的场景。 |
-4 | 只使用IPv4协议。 |
-6 | 只使用IPv6协议。 |
运行mtr命令后，系统默认进入交互模式。在此模式下，您可以按？键或者h键以显示帮助菜单，并根据帮助文档的提示来控制mtr工具的行为或切换显示视图。
使用示例
使用IPv4协议进行网络诊断。
sudo mtr -4 www.aliyun.com回显结果示例说明
以执行mtr 目标IP地址命令为例，返回结果如下：
My traceroute [v0.92]
i Z (1 l) 2024-11-25T13:25:18+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.xxx 0.0% 20 2.0 2.1 1.8 2.4 0.2
2. 10.xxx 45.0% 20 2.6 3.0 2.3 7.7 1.6
3. 10.xxx 0.0% 20 2.3 2.2 2.0 2.4 0.1
4. 11.xxx 0.0% 20 4.1 5.8 3.6 16.1 3.8
5. 10.xxx 0.0% 20 4.8 4.4 4.2 4.8 0.1
6. 115.xxx 26.3% 20 4.3 4.4 4.3 4.6 0.1
7. 220.xxx 20.0% 20 5.6 5.1 4.9 5.6 0.1
8. ???
9. 58.xxx 0.0% 20 13.5 13.7 13.5 14.2 0.2
10. 58.xxx 31.6% 19 10.2 10.4 10.2 11.5 0.3
11. 58.xxx 0.0% 19 18.4 15.3 12.4 31.7 5.3
12. ???
13. ???
14. ???
15. 180.xxx 0.0% 19 9.0 9.0 8.8 9.1 0.1默认配置下，返回结果列表中各数据项的说明如下。
参数 | 参数说明 |
Host | 节点IP地址和域名。您可以按 |
Loss% | 节点丢包率。 |
Snt | 已发送数据包数。默认值是10，可以通过参数 |
Last | 最近一次的探测延迟值。 |
Avg | 探测延迟的平均值。 |
Best | 探测延迟的最小值。 |
Wrst | 探测延迟的最大值。 |
StDev | 标准偏差。该值越大说明相应节点越不稳定。 |
WinMTR（Windows）
安装说明
下载WinMTR后无需安装，直接解压运行即可，操作方法非常简单，操作步骤如下。
前往WinMTR官网，下载WinMTR。
下载完成后，解压文件并进入
WinMTR-v092 > WinMTR-v092 > WinMTR_x64目录，双击 WinMTR 应用程序启动工具。启动后界面顶部包含 Host 输入框，可输入目标主机地址，然后单击 Start 开始链路检测。
使用介绍
在Host中，输入目标服务器域名或IP地址。
重要输入的目标服务器域名或IP地址不能包含空格。
单击 Start 开始测试后，路由跟踪结果将以表格形式展示，包含 Hostname、Nr、Loss%、Sent、Recv、Best、Avrg、Worst、Last 等列。
您还可以使用其他功能或设置其他参数，功能及参数说明如下：
功能或参数
参数说明
Copy Text to clipboard
将测试结果以文本格式复制到剪贴板。
Copy HTML to clipboard
将测试结果以HTML格式复制到剪贴板。
Export TEXT
将测试结果以文本格式导出到指定文件。
Export HTML
将测试结果以HTML格式导出到指定文件。
Options
可选参数，包括如下设置：
Interval（sec）：每次探测的间隔时间。默认为1秒。
Ping size（bytes）：PING探测所使用的数据包大小，默认为64字节。
Max. hosts in LRU list：LRU列表支持的最大主机数，默认值为128。
Resolve names：通过反查IP地址以域名显示相关节点。
单击Start，开始测试。
开始测试后，Start会自动变成Stop，WinMTR自动显示测试结果。
运行一段时间后，单击Stop停止测试。
回显结果示例说明
以测试目标服务器域名为例，返回示例如下：
WinMTR 返回的路由跟踪结果以表格形式展示各跳数节点的网络状况。示例中共约 13 个节点，部分节点存在较高丢包率（如 40%、71%、90%），末尾节点显示 No response from host，表示目标主机未响应。
默认配置下，返回结果中各数据项的说明如下：
参数 | 参数说明 |
Hostname | 节点IP地址和域名。 |
Nr | 节点编号。 |
Loss% | 节点丢包率。 |
Sent | 已发送的数据包数量。 |
Recv | 已成功接收的数据包数量。 |
Best | 节点延迟的最小值。 |
Avg | 节点延迟的平均值。 |
Worst | 节点延迟的最大值。 |
Last | 节点延迟的最后一次值。 |
StDev | 标准偏差。该值越大说明相应节点越不稳定。 |
结果分析指南
由于mtr命令有更高的准确性，本文以mtr命令测试结果为例，对链路测试结果的分析进行简要说明。后续的说明，均以如下链路测试结果示例图为基础进行阐述。
My traceroute [v0.92]
i sZ (1 1) 2024-11-25T10:52:08+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.xxx 5.0% 199 1.9 2.0 1.8 12.0 0.7
2. 11.xxx 41.2% 199 2.2 2.5 2.1 15.1 1.5
3. 11.xxx 0.0% 199 2.3 2.4 2.2 8.7 0.6
4. 11.xxx 0.0% 199 3.8 6.7 3.4 244.1 25.2
5. xxx 0.5% 199 4.2 4.3 4.1 11.8 0.6
6. 115.xxx 21.1% 199 4.8 4.6 4.5 6.8 0.3
7. 115.xxx 63.8% 199 7.4 9.6 7.4 26.8 4.7
8. 202.xxx 52.3% 199 11.6 11.7 11.5 12.9 0.2
9. 58.xxx 30.3% 199 16.5 16.7 16.4 33.5 1.5
10. 58.xxx 4.0% 199 14.5 14.5 14.5 15.6 0.1
11. 58.xxx 0.0% 199 17.8 18.6 17.6 38.0 3.1
12. ???
13. ???
14. ???
15. 186.xxx 0.0% 199 14.4 14.3 14.3 15.3 0.1网络区域说明
通常情况下，从客户端到目标服务器的整个链路显著包含以下几个网络区域。关于网络区域的说明及对应区域的异常处理建议，请参阅以下内容。
客户端本地网络
本地局域网和本地网络提供商网络，如前文链路测试结果示例图中的区域A，该区域的异常可以分为两种。
如果是客户端本地网络相关节点出现异常，则需要对本地网络进行相应排查分析。
如果是本地网络提供商网络相关节点出现异常，则需要向当地运营商反馈问题。
运营商网络
运营商网络，如前文链路测试结果示例图中的区域B，可能会经过多个骨干网络。如果该区域出现异常，可以根据异常节点IP地址查询该IP地址归属的运营商，然后直接或通过阿里云售后技术支持，向相应运营商反馈问题。
目标服务器本地网络
目标主机归属网络提供商网络，如前文链路测试结果示例图中的区域C，如果该区域出现异常，则需要向目标主机归属网络提供商反馈问题。
如果中间链路某些部分启用了链路负载均衡，则mtr命令只会对首尾节点进行编号和探测统计。中间节点只会显示相应的IP地址或域名信息。
指标分析思路
要对网络链路连通性或网络性能进行分析，可以基于Loss%（丢包率）、Avg（平均值）、StDev（标准偏差）以及延迟指标来进行综合分析判断，以下介绍基于以上指标分析链路连通性的基本思路。
Loss%（丢包率）
任一节点的Loss%（丢包率）如果不为零，则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有如下两种：
运营商基于安全或性能需求，人为限制了节点的ICMP发送速率，导致丢包。
节点确实存在异常，导致丢包。此时您可以结合异常节点及其后续节点的丢包情况，来判定丢包原因：
如果随后节点均没有丢包，则通常说明异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。如前文链路测试结果示例图中的第2跳所示。
如果随后节点也出现丢包，则通常说明异常节点确实存在网络异常，导致丢包。如前文链路测试结果示例图中的第6跳所示。
如果随后节点出现没有丢包的节点和丢包的节点，即相应节点既存在策略限速，又存在网络异常。对于这种情况，如果异常节点及其后续节点连续出现丢包，而且各节点的丢包率不同，则通常以最后几跳的丢包率为准。如前文链路测试结果示例图所示，在第 6、7、8、9跳均出现了丢包。所以，最终丢包情况，以第9跳的30.3%作为参考。
Avg（平均值）和 StDev（标准偏差）
由于链路抖动或其他因素的影响，节点的Best和Wrst值可能相差很大。而Avg（平均值）统计了自链路测试以来所有探测的平均值，所以能更好地反映出相应节点的网络质量。而StDev（标准偏差值）越高，则说明数据包在相应节点的延时值越不相同（越离散）。所以标准偏差值可用于协助判断Avg是否真实反映了相应节点的网络质量。例如，如果标准偏差很大，说明数据包的延迟是不确定的。可能某些数据包延迟很小（例如25 ms），而另一些延迟却很大（例如350 ms），但最终得到的平均延迟反而可能是正常的。因此，此时Avg并不能很好地反映出实际的网络质量情况。
综上，建议分析标准如下：
如果StDev值很高，则同步观察相应节点的
Best和Wrst，来判断相应节点是否存在异常。如果StDev值不高，则通过Avg来判断相应节点是否存在异常。
说明StDev值高或者不高，并没有具体的数值判断标准，而需要根据同一节点其他列的延迟值大小来进行评估。例如，如果Avg为30ms，当StDev为25ms时，则认为是很高的偏差。而如果Avg为325ms，当StDev同样为25ms时，反而认为是不高的偏差。
延迟
延迟跳变
如果在某一跳之后延迟陡增，则通常判断该节点存在网络异常。如前文链路测试结果示例图所示，从第6跳之后的后续节点延迟陡增，则推断是第6跳节点出现了网络异常。不过，高延迟并不一定完全意味着相应节点存在异常。如前文链路测试结果示例图所示，第6跳之后，虽然后续节点延迟陡增，但测试数据最终仍然正常到达了目的主机。所以，延迟大也有可能是在数据回包链路中引发的。建议结合反向链路测试一并分析。
ICMP限速导致延迟增加
ICMP策略限速也可能会导致相应节点的延迟陡增，但后续节点通常会恢复正常。如前文链路测试结果示例图所示，第9跳有30%的丢包率，同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。因此，可以判断该节点的延迟陡增及丢包是由于策略限速所致。
示例分析及结论
My traceroute [v0.92]
i sZ (1 1) 2024-11-25T10:52:08+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.xxx 5.0% 199 1.9 2.0 1.8 12.0 0.7
2. 11.xxx 41.2% 199 2.2 2.5 2.1 15.1 1.5
3. 11.xxx 0.0% 199 2.3 2.4 2.2 8.7 0.6
4. 11.xxx 0.0% 199 3.8 6.7 3.4 244.1 25.2
5. xxx 0.5% 199 4.2 4.3 4.1 11.8 0.6
6. 115.xxx 21.1% 199 4.8 4.6 4.5 6.8 0.3
7. 115.xxx 63.8% 199 7.4 9.6 7.4 26.8 4.7
8. 202.xxx 52.3% 199 11.6 11.7 11.5 12.9 0.2
9. 58.xxx 30.3% 199 16.5 16.7 16.4 33.5 1.5
10. 58.xxx 4.0% 199 14.5 14.5 14.5 15.6 0.1
11. 58.xxx 0.0% 199 17.8 18.6 17.6 38.0 3.1
12. ???
13. ???
14. ???
15. 186.xxx 0.0% 199 14.4 14.3 14.3 15.3 0.1结合上述链路测试结果示例图及分析思路，可以得出如下结论。
在链路中，第2、6、7、8、9跳出现了丢包现象，但后续的3、4、5、10、11、15跳并未出现大量丢包，如果对应的业务网络请求并无异常，则可以判断2、6、7、8、9跳的丢包可能是触发了ICMP限速导致。
第4跳
Wrst值较高，但是Avg值不高，有可能是某一次探测时网络有波动或者设备性能波动引发的瞬时网络链路波动。整条链路节点延迟平均值介于1.8 - 17.6之间，显示整条链路网络延迟较低。
基于以上几条分析结论，可以判断实例中的网络链路正常。如果实际业务网络中确实存在网络波动，可以结合反向链路测试结果进行分析。
对网络结果分析的思路较为灵活，以上仅为指标分析的一些常见方法。在实际的网络结果分析中，您需要结合自身的实际情况进行综合评估，以便得出准确的结论。如果单向网络链路测试无法提供明确的结论，您可以结合反向链路测试进行更深入的问题分析与定位。
常见链路异常场景
常见的链路异常场景将以在Linux操作系统上执行mtr命令为例进行说明。具体结果应以您实际操作系统和工具的返回结果为准。
目标主机网络配置不当
数据包在目标地址出现了100%的丢包。初步看是数据包没有到达，其实很有可能是目标服务器相关安全策略，例如防火墙、iptables等禁用了ICMP所致，导致目的主机无法发送任何应答。所以，该场景需要排查目标服务器的安全策略配置。
[root@mycentos ~]# mtr --no-dns www.xxx.com
My traceroute [v0.75]mycentos (0.0.0.0)
Wed Jun 15 19:06:29 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. ???
3. 111.xxx.xxx.xxx 0.0% 10 521.3 90.1 2.7 521.3 211.3
4. 111.xxx.xxx.9 0.0% 10 2.9 4.7 1.6 10.6 3.9
5. 211.xxx.xxx.29 80.0% 10 3.0 3.0 3.0 3.0 0.0
6. 221.xxx.xxx.85 0.0% 10 1.7 7.2 1.6 34.9 13.6
7. 221.xxx.xxx.5 0.0% 10 5.2 5.2 5.1 5.2 0.0
8. 221.xxx.xxx.26 0.0% 10 5.3 5.2 5.1 5.3 0.1
9. 173.xxx.xxx.105 100.0% 10 0.0 0.0 0.0 0.0 0.0ICMP限速
中间链路节点出现较高丢包率，但后续节点恢复正常。这通常是运营商或中间网络设备对ICMP报文进行了策略限速所致，并非真实的网络丢包。如示例中第4跳丢包率83%，但第5跳恢复正常；第9跳丢包率90.4%，可结合反向MTR链路测试综合分析，确认是否为限速策略所致。
My traceroute [v0.92]
i xxx Z (172.xxx 7) 2025-06-16T11:01:14+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.xxx.26 12.6% 95 1.9 1.8 1.6 2.5 0.1
2. 10.xxx.89 0.0% 95 3.0 3.5 2.8 14.0 1.3
3. 11.xxx.41 0.0% 95 1.8 1.9 1.7 4.0 0.4
4. 11.xxx.17 83.0% 95 3.1 4.3 2.9 7.3 1.5
5. 11.xxx.54 0.0% 95 9.5 9.6 9.2 13.4 0.6
6. 12x.xxx.246 0.0% 95 11.4 84.8 10.9 524.7 136.7
7. 11.xxx.170 0.0% 95 9.2 10.2 9.0 39.4 4.2
8. ???
9. 11.xxx 162 90.4% 95 7.8 7.9 7.8 8.0 0.1
10. ???链路中存在环路
数据包在第5跳之后出现了循环跳转，导致最终无法到达目标服务器。这通常是由于运营商相关节点路由配置异常，即链路中存在环路所致。所以，该场景需要联系相应节点归属运营商处理。
[ xxx@mycentos ~]# mtr --no-dns www.google.com
My traceroute [v0.75]mycentos (0.0.0.0) Wed Jun 15 19:06:29 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 63.xxx.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.xxx.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.xxx.0.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix xxx tl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.xxx.56 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. 72.xxx.57 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. 72.xxx.56 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. 72.xxx.57 0.0% 10 0.0 0.0 0.0 0.0 0.0
9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0链路中断
数据包在第4跳之后未能收到任何反馈，Loss%、Last、Avg、Best 等指标均未显示任何统计数据。这通常是由于相应节点的中断所致。建议结合反向链路测试进行进一步确认。该场景需联系相应节点所属的运营商进行处理。
@mycentos ~]# mtr -no-dns www.google.com
My traceroute [v0.75]mycentos (0.0.0.0) Wed Jun 15 19:06:29 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 63.xxx.xxx.3 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.xxx.xxx.57 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.xxx.xxx.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix-xxx.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0