當網站訪問很慢或無法訪問時，若排除其它顯著問題，而檢測到 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% 的丟包率，同時延遲也明顯陡增。但隨后節點的延遲馬上恢復了正常。所以判斷該節點的延遲陡增及丟包是由于策略限速所致。