Windows Server Network Troubleshooting: ping, tracert, pathping, Test-NetConnection, WinMTR and iperf3

When a website on your Windows server is slow from some places, Remote Desktop keeps dropping, or a game or application reports high latency, the cause is usually somewhere on the network path rather than on the server itself. Windows includes good diagnostic tools, and a few free ones fill the gaps. This guide explains how to use ping, tracert, pathping, Test-NetConnection, WinMTR and iperf3, how to read the results without being misled, and what to include when you contact support.

Step 1: Basic Reachability and Latency with 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

Stable times with 0% loss mean the path is healthy at that moment. Loss of a few percent or times that jump by hundreds of milliseconds point to congestion. Note that some servers and firewalls block ping, so no reply does not always mean the server is down; test a port with Step 3 as well.

Step 2: See the Path with tracert and 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

Read the results carefully: many routers deliberately give low priority to replies addressed to themselves. Loss or high latency at a middle hop that does not continue to the following hops and the final destination is not a problem. Only loss that starts at one hop and continues all the way to the end shows where trouble begins.

Step 3: Test a Specific Port with Test-NetConnection

Ping proves the server is reachable; a port test proves the service is reachable. This is the quickest way to tell a network problem from a firewall or application problem.

# 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, OwningProcess

TcpTestSucceeded : True means the port is open end to end. If ping works but the port test fails, check Windows Firewall (see opening ports in Windows Firewall) and whether the service is running.

Step 4: Continuous Route Monitoring with WinMTR

MTR combines ping and traceroute and keeps measuring every hop, which is the best way to capture intermittent problems. On Windows use WinMTR (free, open source): enter the server IP, click Start, let it run for at least 2–3 minutes (ideally while the problem is happening) and use Copy text to clipboard to save the result. Read it the same way as pathping: only loss that continues to the last hop matters. If you have a Linux machine available, see mtr, traceroute and iperf3 on Linux.

Step 5: Measure Bandwidth with iperf3

Latency tests do not show throughput. iperf3 measures the real speed between two machines. Download the Windows build of iperf3, extract it, and on the server open the port in the firewall temporarily:

# 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"

A single stream over a long distance is often slower than the port speed because of latency; compare results with -P 4 or -P 8 before concluding that bandwidth is limited.

Step 6: Check DNS, Routes and 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

If 1472 fails with "Packet needs to be fragmented but DF set" while smaller sizes work, something on the path uses a smaller MTU; that can cause pages or downloads to hang while small requests work.

Step 7: What to Send to Support

To get a route problem fixed quickly, include in your ticket:

• The server IP, your own public IP (from a "what is my IP" site) and your city and ISP.
• A WinMTR or pathping result from your side to the server, and, if possible, one from the server to your IP.
• The time the problem happened (with time zone) and whether it is constant or only at certain hours.
• For speed problems, the iperf3 results in both directions.

See also how to submit a ticket to IMIDC technical support.

FAQ

tracert shows "Request timed out" on some hops

Those routers simply do not answer traceroute probes. If the following hops and the destination answer normally, the path is fine.

Speed is fine at night but slow in the evening

That is typical congestion on international links or at your ISP during peak hours. Run tests at both times and include them in your ticket; a route with better peak-hour performance (for example a premium China route) may be the solution.

Ping works but Remote Desktop does not connect

The network path is fine; the port is blocked or the service is not answering. Follow Remote Desktop troubleshooting.

Still stuck after following these steps? Open a support ticket and the IMIDC 24/7 technical team will help. Include the server IP, your public IP and location, and the WinMTR, pathping or iperf3 results so we can pinpoint the issue faster.