当网站访问很慢或无法访问时，若排除其它显著问题，而检测到 ping 有明显丢包时，建议您作链路测试。Windows 环境下，您可以通过 WinMTR 工具（优先使用） 或 TRACERT 命令行工具进行链路测试来判断问题来源。
通常情况下，请依照下述步骤进行处理：
利用链路测试工具探测网络状况和服务器状态。
根据链路测试结果分析处理。
WinMTR 工具（优先使用）
mtr（My traceroute）作为一款网络测试工具，集成了 tracert 与 ping 这两个命令的图形界面。ping 与 tracert 通常被用來检测网络状况和服务器状态，具体说明如下：
| 命令名称 | 具体说明 |
|---|
| ping | 送出封包到指定的服务器。如果服务器有回应就会传送回封包，并附带返回封包来回的时间 |
| tracert | 返回从用户的电脑到指定的服务器中间经过的所有节点(路由)以及每个节点的回应速度。 |
WinMTR 是 mtr 工具在 Windows 环境下的图形化实现，适合 Windows 下做路由追踪及 ping 测试。WinMTR 默认发送 ICMP 数据包进行探测，无法切换。
相比 TRACERT 命令行工具，WinMTR 能避免节点波动对测试结果的影响，测试结果更正确。Windows 环境下，建议优先使用 WinMTR 进行链路测试。（点击官方网站下载获取。）
操作步骤
在官网下载 WinMTR 后 ，直接解压运行。运行程序后，在 Host 字段输入目标服务器域名或 IP（前面不要包含空格）。
单击 Start 开始测试。（开始测试后，相应按钮变成了 Stop。）
运行一段时间后，单击 Stop 停止测试。
说明：您可以多测试几分钟，测试结束后，将结果导出。
Interval（sec）：每次探测的间隔（过期）时间，默认为 1 秒。
Ping size(bytes)： ping 探测所使用的数据包大小，默认为 64 字节。
Max hosts in LRU list： LRU 列表支持的最大主机数，默认值为 128。
Resolve names：通过反查 IP 以域名显示相关节点。
Copy Text to clipboard：将测试结果以文本格式复制到粘贴板。
Copy HTML to clipboard：将测试结果以 HTML 格式复制到粘贴板。
Export TEXT：将测试结果以文本格式导出到指定文件。
Export HTML：将测试结果以 HTML 格式导出到指定文件。
Options：可选参数。具体包括：
查看 WinMTR 运行后的返回结果。
说明：默认配置下，WinMTR 测试结果说明如下：
第一列（Hostname）：到目的服务器要经过的每个节点主机 IP 或域名。
第二列（Nr）：节点编号。
第三列（Loss%）：节点丢包率。ping 数据包回复失败的百分比，由此可判断那个节点(线路)出现故障，是服务器所在机房还是国际路由干路。
第四列（Sent）：已发送的数据包数量。
第五列（Recv）：已成功接收的数据包数量。
第六、七、八、九列（Best 、Avg、Worst、Last）：分别是回应时间的最小值、平均值、最大值和最后一个数据包的回应时间。
TRACERT 命令行工具
TRACERT (Trace Route) 是 Windows 自带的网络诊断命令行实用程序，用于跟踪 Internet 协议 (IP) 数据包传送到目标地址时经过的路径。
TRACERT 通过向目标地址发送 ICMP 数据包来确定到目标地址的路由。在这些数据包中，TRACERT 使用了不同的 IP 生存期 (TTL) 值。由于要求沿途的路由器在转发数据包前至少必须将 TTL 减少 1，因此 TTL 实际上相当于一个跃点计数器 (hop counter)。当某个数据包的 TTL 达到零 (0) 时，相应节点就会向源计算机发送一个 ICMP 超时 的消息。
TRACERT 第一次发送 TTL 为 1 的数据包，并在每次后续传输时将 TTL 增加 1，直到目标地址响应或达到 TTL 的最大值。中间路由器发送回来的 ICMP 超时 消息中包含了相应节点的信息。
操作步骤
在桌面底部单击 开始 菜单，选择 运行。
打开运行框后，在框中输入 cmd 并单击 确定。
在命令运行界面中，输入 tracert ，按回车键后，界面将显示 tracert 的用法说明。
根据具体用法，输入待跟踪的目标地址。
示例
C:\> tracert -d 223.5.5.5
通过最多 30 个跃点跟踪到 223.5.5.5 的路由
1 * * * 请求超时。
2 9 ms 3 ms 12 ms 192.168.17.20
3 4 ms 9 ms 2 ms 111.1.20.41
4 9 ms 2 ms 1 ms 111.1.34.197
5 11 ms * * 211.140.0.57
6 3 ms 2 ms 2 ms 211.138.114.62
7 2 ms 2 ms 1 ms 42.120.244.190
8 32 ms 4 ms 3 ms 42.120.244.238
9 * * * 请求超时。
10 3 ms 2 ms 2 ms 223.5.5.5
分析链路测试结果
以如下链路测试结果示例图为基础进行阐述：
操作步骤
判断各区域是否存在异常，并根据各区域的情况分别处理。
区域 A：客户端本地网络，即本地局域网和本地网络提供商网络。针对该区域异常，客户端本地网络相关节点问题，请对本地网络进行排查分析；本地网络提供商网络相关节点问题，请向当地运营商反馈。
区域 B：运营商骨干网络。针对该区域异常，可根据异常节点 IP 查询归属运营商，然后直接或通过阿里云售后技术支持，向相应运营商反馈问题。
区域 C：目标服务器本地网络，即目标主机归属网络提供商网络。针对该区域异常，需要向目标主机归属网络提供商反馈问题。
结合 Avg（平均值）和 StDev（标准偏差），判断各节点是否存在异常。
若 StDev 很高，则同步观察相应节点的 Best 和 Wrst，来判断相应节点是否存在异常。
若 StDev 不高，则通过 Avg 来判断相应节点是否存在异常。
注意：上述 StDev 高 或者 不高，并没有具体的时间范围标准。而需要根据同一节点其它列的延迟值大小来进行相对评估。比如，如果 Avg 为 30 ms，那么，当 StDev 为 25 ms，则认为是很高的偏差。而如果 Avg 为 325 ms，则同样的 StDev（25 ms），反而认为是不高的偏差。
查看节点丢包率，若 Loss% 不为零，则说明这一跳网络可能存在问题。
导致节点丢包的原因通常有两种：
人为限制了节点的 ICMP 发送速率，导致丢包。
节点确实存在异常，导致丢包。
确定当前异常节点的丢包原因。
若随后节点均没有丢包，说明当前节点丢包是由于运营商策略限制所致，可以忽略。如前文链路测试结果示例图中的第 2 跳所示。
若随后节点也出现丢包，说明当前节点存在网络异常，导致丢包。如前文链路测试结果示例图中的第 5 跳所示。
说明：前述两种情况可能同时发生，即相应节点既存在策略限速，又存在网络异常。对于这种情况，若当前节点及其后续节点连续出现丢包，而且各节点的丢包率不同，则通常以最后几跳的丢包率为准。如前文链路测试结果示例图所示，在第 5、6、7 跳均出现了丢包。所以，最终丢包情况，以第 7 跳的 40% 作为参考。
通过查看是否有明显的延迟，来确认节点是否存在异常。通过如下两个方面进行分析：
若某一跳之后延迟明显陡增，则通常判断该节点存在网络异常。如前文链路测试结果示例图所示，从第 5 跳之后的后续节点延迟明显陡增，则推断是第 5 跳节点出现了网络异常。
注意：高延迟并不一定完全意味着相应节点存在异常，延迟大也有可能是在数据回包链路中引发的，建议结合反向链路测试一并分析。
ICMP 策略限速也可能会导致相应节点的延迟陡增，但后续节点通常会恢复正常。如前文链路测试结果示例图所示，第 3 跳有 100% 的丢包率，同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。