Speed-test websites measure your connection to their servers. iperf3 measures throughput between two machines you control — your VPS and your office, two servers in different data centers, or a server and a backup target. It’s the standard tool for verifying port speed and diagnosing slow transfers.
Install on both ends
sudo apt install iperf3 # Debian/Ubuntu
sudo dnf install iperf3 # RHEL familyWindows and macOS builds are available too. Both sides should run iperf3 (not the older, incompatible iperf2).
Start the server
On one machine (say, your VPS):
iperf3 -sIt listens on TCP port 5201. Open it temporarily in the firewall:
sudo ufw allow 5201Close it again when you’re done, and stop the server with Ctrl+C. To run a single test and exit: iperf3 -s -1.
Run the client
On the other machine:
iperf3 -c 203.0.113.10[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 12 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec receiver- Bitrate — achieved throughput.
- Retr — TCP retransmissions; a high count indicates packet loss or congestion.
By default the client sends to the server (upload from the client’s perspective).
Useful options
iperf3 -c host -R # reverse: server sends to client (download)
iperf3 -c host --bidir # both directions at once
iperf3 -c host -P 8 # 8 parallel streams
iperf3 -c host -t 30 # run 30 seconds
iperf3 -c host -i 1 # report every second
iperf3 -c host -4 # force IPv4
iperf3 -c host -p 5202 # different port
iperf3 -c host -J > result.json # JSON output for scriptsWhy parallel streams matter
A single TCP connection over a long distance is limited by latency and the TCP window: throughput ≈ window / RTT. Between continents (150+ ms), one stream may reach only a fraction of the port speed, while -P 8 fills it. That’s not a network fault — it’s TCP physics — and it’s why download managers open several connections.
If a single stream is much slower than parallel ones on a long path:
- Try BBR congestion control, which handles latency and light loss better than CUBIC — see TCP BBR.
- Check that TCP window scaling isn’t limited (default Linux buffers are usually fine for up to ~1 Gbps at moderate RTT).
UDP tests: loss and jitter
iperf3 -c host -u -b 100M # send UDP at 100 Mbit/sThe report shows jitter and lost/total datagrams. UDP doesn’t back off like TCP, so this reveals how much loss occurs at a given rate — relevant for VoIP, video streaming, games and WireGuard tunnels. Increase -b until loss appears to find the path’s real capacity.
Interpreting results
| Observation | Likely meaning |
|---|---|
| Close to port speed (e.g. ~940 Mbit/s on 1 Gbps) | Healthy — Ethernet/TCP overhead takes the rest |
Upload fine, download (-R) slow |
Asymmetric path or congestion in one direction |
| Many retransmits | Packet loss somewhere — check with mtr |
One stream slow, -P 8 fast |
Latency-bound TCP window; consider BBR |
| Fast at night, slow in the evening | Peak-hour congestion on a transit link |
| Varies a lot between runs | Shared bottleneck on the path, or CPU limits on small VMs |
Your local connection is often the bottleneck: test from a well-connected server when you want to know what the VPS can do.
Public iperf3 servers
Some networks run public iperf3 servers for testing. They’re handy, but often busy and rate-limited — treat results as rough. Testing against a server you control is more reliable.
Bandwidth vs plan type
Throughput depends on the port speed and how traffic is metered:
- Port speed — the maximum rate (e.g. 1 Gbps).
- Monthly transfer — the total volume per month (e.g. several TB).
- Unmetered at a fixed rate — e.g. a set number of Mbps you can use 24/7 without volume limits.
Our USA VPS plans use 1 Gbps ports with monthly transfer allowances, while Hong Kong VPS plans offer unmetered CN2 bandwidth at a fixed rate. See VPS bandwidth explained.
Related: speedtest-cli on a server and latency vs bandwidth.