Describe the problem precisely
Slow transfers have many causes: your own connection, the path across the internet, the other server, the TCP settings or the server's own load. Before testing, write down which destination is slow, how it behaves (slow, drops, or unstable), when it started and whether it is constant or only at certain times. That turns a vague complaint into something that can be tested.
Rule out your VPS first with the checks in the slow VPS guide, because a busy CPU or a full disk can look like a network problem.
Measure latency and loss with ping
Ping sends small packets and reports the round-trip time and the percentage lost. Run enough packets for a stable picture, for example 100. Some loss is a symptom, but a router that limits replies to ping can mislead you, so confirm with the next tools.
ping -c 100 -i 0.2 example.com | tail -n 4
ping -c 20 1.1.1.1 | tail -n 3Trace the path with mtr
mtr combines ping and traceroute: it lists each router between you and the destination with loss and latency for each hop. It is the most useful tool for this problem. Install it, and run it as a report with a hundred cycles so that results are meaningful.
sudo apt install mtr-tinysudo dnf install mtrmtr -rwzbc 100 example.comRead the mtr output correctly
Loss at one hop in the middle that does not continue to later hops is usually a router that deprioritises replies to ping and is not a real problem. Real loss shows up in that hop and every hop after it, including the final destination. A big jump in latency that stays high on all later hops marks where the delay starts, such as a long-distance link. A final hop with no loss and normal latency means the path is healthy, whatever the middle hops show.
Test in both directions
Routing is often different in each direction, so a path that looks fine from your server to the destination can be bad in reverse. Run mtr from your own computer to your server's address as well, and save both. The reverse test shows what your users or your other servers experience.
mtr -rwzbc 100 YOUR_SERVER_IPpathping YOUR_SERVER_IPMeasure throughput
To test the link between two machines you control, run iperf3 on one as a server and on the other as a client. Test both directions and with several streams, because a single TCP stream can be limited by latency and loss. Open the test port only while you test and only for the client address.
sudo apt install iperf3sudo dnf install iperf3iperf3 -siperf3 -c OTHER_SERVER_IP -t 20
iperf3 -c OTHER_SERVER_IP -t 20 -R
iperf3 -c OTHER_SERVER_IP -t 20 -P 4Test a real download
For a quick check against a public file, curl reports the average speed. Run the same test against several hosts and at different times. If only one destination is slow while others are fast, the problem is probably at or near that destination.
curl -o /dev/null -s -w "speed %{speed_download} bytes/s time %{time_total}s\n" https://speed.cloudflare.com/__down?bytes=100000000Check the server's own TCP statistics
Retransmissions show that packets are being lost or delayed on connections to and from your server. A rising retransmit count with normal CPU and memory points to the network path. These counters accumulate since boot, so compare two readings a minute apart.
nstat -az TcpRetransSegs TcpOutSegs
sleep 60
nstat -az TcpRetransSegs TcpOutSegs
ss -ti dst example.com | head -n 8What to send to support
A good report gets a faster answer. Include the affected IP addresses, the times with the time zone, the mtr output in both directions, ping statistics, the iperf3 or curl results and how often it happens. State what you have ruled out. Do not paste your SSH keys or passwords, and mention if the problem started after a change you made.
{ date -u; echo; mtr -rwzbc 100 TARGET; echo; ping -c 50 TARGET | tail -n 4; echo; ip -br a; ip route; } > ~/network-evidence-$(date +%F-%H%M).txt 2>&1
ls -l ~/network-evidence-*.txtOfficial documentation
These upstream references provide more detail on the commands and workflows in this guide.