Windows 伺服器網路丟包排查：ping、tracert 路由追蹤、Test-NetConnection、WinMTR 與 iperf3
當 Windows 伺服器上的網站在某些地區訪問很慢、遠端桌面頻繁斷開，或者遊戲、應用程式提示延遲很高時，原因通常出在網路路徑上，而不是伺服器本身。Windows 自帶了不錯的診斷工具，再配合幾款免費工具就能覆蓋其餘場景。本文介紹如何使用 ping、tracert、pathping、Test-NetConnection、WinMTR 和 iperf3，如何正確解讀結果、避免誤判，以及聯絡技術支援時應提供哪些資訊。
步驟 1：用 ping 測試連通性和延遲
# 50 pings to the server; watch the average time and the "Lost" count
ping -n 50 203.0.113.10
# Continuous ping (Ctrl+C to stop) while you reproduce the problem
ping -t 203.0.113.10
# IPv6 or a hostname
ping -6 -n 20 example.com延遲穩定且丟包率為 0%，說明此時線路是健康的。丟包達到百分之幾，或延遲突然跳升幾百毫秒，通常說明存在擁塞。注意，有些伺服器和防火牆會遮蔽 ping，所以 ping 不通並不一定代表伺服器宕機，請同時按步驟 3 測試埠。
步驟 2：用 tracert 和 pathping 檢視路由路徑
# Hop-by-hop route without DNS lookups (faster)
tracert -d 203.0.113.10
# tracert + loss statistics for every hop (100 probes per hop, takes a few minutes)
pathping -n -q 100 203.0.113.10解讀結果時要小心：很多路由器會刻意降低發給自身的回覆的處理優先順序。如果某個中間節點出現丟包或高延遲，但後續節點和最終目標都沒有延續這種情況，那就不是問題。只有從某一跳開始出現、並一直延續到終點的丟包，才能說明問題從哪裡開始。
步驟 3：用 Test-NetConnection 測試指定埠
ping 通只能說明伺服器可達，埠測試通過才能說明服務可達。這是區分網路問題與防火牆或應用程式問題最快的方法。
# Is Remote Desktop / a website / SSH reachable?
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
# Built-in traceroute
Test-NetConnection 203.0.113.10 -TraceRoute
# On the server: is the service actually listening?
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 80,443,3389 | Select-Object LocalAddress, LocalPort, OwningProcessTcpTestSucceeded : True 表示埠端到端暢通。如果 ping 正常但埠測試失敗，請檢查 Windows 防火牆（參見 Windows 防火牆開放埠）以及服務是否正在執行。
步驟 4：用 WinMTR 持續監測路由
MTR 結合了 ping 和 traceroute 的功能，會持續測量每一跳，是捕捉間歇性問題的最佳方式。在 Windows 上可以使用 WinMTR（免費、開源）：輸入伺服器 IP，點選 Start，讓它至少執行 2–3 分鐘（最好在問題出現期間執行），然後點選 Copy text to clipboard 複製並儲存結果。解讀方法與 pathping 相同：只有延續到最後一跳的丟包才有意義。如果你有 Linux 機器，可以參見 Linux 下使用 mtr、traceroute 和 iperf3。
步驟 5：用 iperf3 測試頻寬
延遲測試無法反映吞吐量，iperf3 可以測出兩臺機器之間的實際速度。下載 Windows 版 iperf3 並解壓，然後在伺服器上臨時放行測試埠：
# On the server: allow the test port, then start the iperf3 server
New-NetFirewallRule -DisplayName "iperf3 test" -Direction Inbound -Protocol TCP -LocalPort 5201 -Action Allow
.\iperf3.exe -s
# On the client: upload test, then download test (-R), 4 parallel streams, 20 seconds
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20 -R
# Afterwards, remove the temporary rule
Remove-NetFirewallRule -DisplayName "iperf3 test"受延遲影響，遠距離單執行緒測試的速度往往低於埠頻寬；在得出頻寬受限的結論之前，請先用 -P 4 或 -P 8 對比測試結果。
步驟 6：檢查 DNS、路由表和 MTU
# DNS: compare your resolver with a public one, and clear the local cache
Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
ipconfig /flushdns
# IP configuration and routing table on the server
ipconfig /all
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 10
# MTU: the largest packet that passes without fragmentation (1472 + 28 = 1500)
ping -f -l 1472 203.0.113.10
ping -f -l 1400 203.0.113.10如果 1472 測試失敗並提示“需要拆分資料包但是設定 DF。”（Packet needs to be fragmented but DF set），而更小的包可以正常通過，說明路徑上某處使用了更小的 MTU；這可能導致小請求正常，但網頁或下載卡住不動。
步驟 7：需要提供給技術支援的資訊
為了儘快解決線路問題，請在工單中附上：
- 伺服器 IP、你自己的公網 IP（可通過“查詢我的 IP”類網站獲取），以及你所在的城市和運營商。
- 從你這邊到伺服器的 WinMTR 或 pathping 結果；如條件允許，再附上一份從伺服器到你的 IP 的結果。
- 問題出現的時間（註明時區），以及問題是持續存在還是隻在特定時段出現。
- 如果是速度問題，請附上雙向的 iperf3 測試結果。
另請參見如何向 IMIDC 技術支援提交工單。
常見問題
tracert 部分節點顯示“請求超時”（Request timed out）？
這些路由器只是不響應 traceroute 探測包。只要後續節點和目標都能正常響應，線路就沒有問題。
深夜速度正常，晚高峰變慢？
這是國際鏈路或你的運營商在高峰時段的典型擁塞現象。請在兩個時段分別測試，並把結果附在工單中；換用高峰期表現更好的線路（例如面向中國大陸最佳化的精品線路）可能是解決辦法。
ping 得通，但遠端桌面連不上？
網路路徑沒有問題，是埠被攔截或服務沒有響應。請參見遠端桌面連線故障排查。
如果按以上步驟操作後問題仍未解決，請提交工單聯絡 IMIDC 7×24 技術支援，並附上伺服器 IP、你的公網 IP 和所在地，以及 WinMTR、pathping 或 iperf3 測試結果，方便工程師快速定位。