VPS Speed Test: How to Test Server Bandwidth and Latency with iperf3, Speedtest CLI and curl

A proper VPS speed test answers two questions: how much bandwidth the server can push and receive, and how quickly packets travel between the server and your users. This guide shows how to test server bandwidth and latency on a JUSTG cloud or dedicated server running Debian/Ubuntu or CentOS/Rocky/AlmaLinux, using iperf3 in both directions, the Speedtest CLI and a simple curl download, and how to interpret the numbers against the 500Mbps port common on JUSTG cloud servers in Johannesburg, Moscow, Tokyo and Seoul.

Step 1: Install iperf3 for a bandwidth test between two machines

iperf3 measures raw TCP throughput between two hosts you control, without any website or CDN in the middle. You need it on the JUSTG server and on the machine you test from (another server, or your own PC; Windows builds of iperf3 are also available).

# Debian / Ubuntu
apt update && apt install -y iperf3

# CentOS / Rocky Linux / AlmaLinux
dnf install -y iperf3

Step 2: Run the iperf3 server and test both directions with -R

On the JUSTG server, allow TCP port 5201 and start iperf3 in server mode:

# Debian / Ubuntu with UFW
ufw allow 5201/tcp

# CentOS / Rocky / AlmaLinux with firewalld (until next reload)
firewall-cmd --add-port=5201/tcp

# start the iperf3 server (Ctrl+C to stop)
iperf3 -s

On the other machine, run the client. By default the client sends data to the server (upload from the client's point of view). Adding -R reverses the direction so the server sends to you, which is what your visitors experience when they download pages and files. -P 4 opens four parallel streams and -t 30 runs for 30 seconds.

# upload test: your machine -> JUSTG server
iperf3 -c 203.0.113.10 -P 4 -t 30

# download test: JUSTG server -> your machine (reverse mode)
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

Read the [SUM] lines at the end. The receiver figure is the real throughput; the Retr column shows TCP retransmissions.

[SUM]   0.00-30.00  sec  1.64 GBytes   470 Mbits/sec   15   sender
[SUM]   0.00-30.03  sec  1.64 GBytes   469 Mbits/sec        receiver

Step 3: Use the Speedtest CLI (Ookla) or speedtest-cli

If you do not have a second machine, a public speed test server is the quickest check. The official Ookla Speedtest CLI is installed from Ookla's repository:

# Debian / Ubuntu
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install -y speedtest

# CentOS / Rocky Linux / AlmaLinux
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.rpm.sh | bash
dnf install -y speedtest

# run a test (nearest server), list servers, or pick one by ID
speedtest --accept-license --accept-gdpr
speedtest -L
speedtest -s 12345

The older Python tool speedtest-cli is an alternative. Remove one before installing the other on Debian/Ubuntu, because both provide a command with a similar name.

# Debian / Ubuntu
apt install -y speedtest-cli
# any distribution with Python 3
pip3 install speedtest-cli

speedtest-cli --simple
speedtest-cli --list | head -n 20
speedtest-cli --server 12345 --simple

Results depend heavily on the test server you pick: a busy or distant node may report low numbers even when your port is fine. Try two or three servers, including one near your users.

Step 4: Run a curl download test

A real file download shows what a single HTTP connection achieves. Use a large file from a well-connected mirror and discard the data:

curl -o /dev/null -w "avg speed: %{speed_download} bytes/s, total: %{time_total}s\n" \
  https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

# wget prints the speed in MB/s at the end
wget -O /dev/null https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

curl reports bytes per second. Divide by 1,000,000 for MB/s, and multiply MB/s by 8 to get Mbps.

Step 5: Interpret the results against a 500Mbps port

• Units: 500Mbps (megabits) equals 62.5 MB/s (megabytes) in theory. After TCP/IP overhead, about 470 to 480 Mbps in iperf3, or roughly 55 to 59 MB/s in a download, means the port is fully used.
• Single stream vs parallel: on long-distance paths, one TCP connection is limited by latency. If -P 4 is much faster than a single stream, the port is fine and the limit is the round-trip time.
• Direction: upload and download can differ because the route each way is different. Always test with and without -R.
• Latency: iperf3 does not measure it; use ping -c 50 to your users' region and look at average and jitter, not only the best value.
• The other end: your home connection, Wi-Fi or a busy public speed test server is often the real bottleneck.

Step 6: Test at peak hours

International links are busiest in the evening of the users' time zone. Repeat the tests during that window and compare with a quiet period. A simple loop logs several runs:

# three tests, 10 minutes apart, saved to a log file
for i in 1 2 3; do date; speedtest-cli --simple; sleep 600; done | tee -a speedtest.log

FAQ

Speedtest shows 200 Mbps on my 500Mbps VPS. Is something wrong?

Not necessarily. Try other test servers, use iperf3 with -P 4 to a machine you control, and check the reverse direction. If several methods stay well below the port speed, contact support with the outputs.

Why is download from China slower than from Europe?

Higher latency and busier cross-border links limit single-connection speed. Compare peak and off-peak results and check the route with an MTR test.

Can I leave iperf3 running permanently?

It is better not to. Start it only while testing and close the port afterwards.

If you still cannot resolve the issue, please submit a ticket to contact JUSTG technical support and include your test outputs and test times.