Diagnosing a slow network path, step by step

Updated November 2026

"The network is slow" can mean a dozen different faults. Working through the same tests in the same order turns a vague complaint into a specific finding, such as "1% loss starting at the second router, in one direction only", that someone can actually fix.

1. Pin down the problem

Write down the two endpoints (names and addresses), the direction of the slow transfer, what speed you expected and what you saw, and when it happens. A file copy from a server in another city that runs at 40 Mbit/s on a 1 Gbit/s link is a precise, testable complaint. "Everything is slow" is not.

2. Ping: delay and basic loss

# Linux and macOS
ping -c 100 server.example.net
# Windows
ping /n 100 server.example.net

Note the average round-trip time (RTT) and the loss percentage. The RTT matters for everything later: TCP throughput on a path depends on it. Loss above zero on a wired path is worth chasing. Bear in mind some hosts and firewalls drop or deprioritize ping, so no reply is not proof of a fault.

3. mtr: where does it start?

mtr combines traceroute and ping and shows loss and delay per hop:

mtr -r -w -c 100 server.example.net

-r prints a report after -c rounds (one per second), and -w keeps hostnames from being cut. Read it carefully:

Loss at one middle hop that disappears at later hops is usually not real. Many routers give low priority to answering probes, as the mtr manual notes. Real loss continues all the way to the last hop.
Loss that starts at a hop and stays in every hop after it points at that hop or the link into it.
A big jump in delay that stays for all later hops usually means distance (a long link) or a queue building up.

If ICMP is filtered, try TCP probes to a port the server accepts: mtr -r -w -T -P 443 server.example.net.

4. iperf3 in both directions

Now measure what TCP actually achieves, with an iperf3 server near the far end:

iperf3 -c server.example.net -t 30
iperf3 -c server.example.net -t 30 -R
iperf3 -c server.example.net -t 30 -P 8

Compare the three. A large gap between directions points to a one-way problem such as loss, duplex mismatch or a policer. A big gain from -P 8 points to a window or loss limit on single streams. Watch the Retr column: steady retransmissions confirm loss. Reading results covers the patterns in detail.

5. Check the arithmetic

A single TCP stream can never go faster than its window divided by the RTT. Work out what the path needs: bandwidth × RTT. For 1 Gbit/s and 40 ms, that is 1,000,000,000 × 0.040 = 40,000,000 bits, or 5 MB. If either host caps its buffers at 4 MB, one stream tops out near 4 × 1,048,576 × 8 ÷ 0.040 ≈ 840 Mbit/s even on a perfect path, and an old 64 KB window would give only about 13 Mbit/s. If your result matches this ceiling, the fix is host tuning, not the network. See TCP tuning.

6. MTU problems

A path MTU problem typically shows as connections that open and then hang on large transfers, while small requests work. Test with a full-size, don't-fragment ping:

# Linux: 1472 bytes of data + 8 ICMP + 20 IPv4 = 1500
ping -M do -s 1472 -c 4 server.example.net
# Windows
ping /f /l 1472 server.example.net
# Show the path MTU hop by hop (Linux)
tracepath -n server.example.net

If 1472 fails but a smaller size works, something on the path has a smaller MTU, and it may not be sending the ICMP messages that would let TCP adapt. MTU and MSS explains the fixes.

7. Duplex, errors and the first hop

Check the local end before blaming the provider:

ethtool eth0 (Linux) shows link speed, duplex and auto-negotiation. Both ends of a cable must agree.
ip -s link show eth0 shows error and drop counters; run it before and after a test and compare.
On the switch port, look for CRC errors and, on half-duplex links, late collisions.
Rule out Wi-Fi by repeating the key tests from a wired host.

8. Locate the loss

Divide the path. Run iperf3 or a UDP test from the client to a host halfway along, then from that host to the far end. A gentle UDP test at a rate well below the link speed shows loss clearly without TCP hiding it:

iperf3 -c midpoint.example.net -u -b 100M -t 20
iperf3 -c midpoint.example.net -u -b 100M -t 20 -R

Repeat until you find the segment where loss appears. Remember that loss may exist in one direction only.

9. Use perfSONAR where you can

perfSONAR is an open-source toolkit for running and sharing end-to-end measurements. It schedules iperf3, iperf 2 and nuttcp throughput tests, one-way delay and loss tests with OWAMP, two-way tests with TWAMP, and traceroutes, and stores the results over time. Many research and education networks run perfSONAR hosts, so you can often test against a host near each end of a path, or install the toolkit yourself to watch a path continuously. One-way measurements are especially useful: they show which direction is losing packets.

10. Report what you found

When you escalate to a provider or another team, send the endpoints, times, RTT, the mtr report, iperf3 results in both directions (JSON from -J is ideal) and the segment where the problem starts. That evidence usually gets a fault fixed far faster than a complaint about speed.