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 测试结果，方便工程师快速定位。