How fast is your server’s internet connection? A browser speed test measures your home connection, not the server’s. From the server’s terminal you can measure its real download and upload speeds — useful when evaluating a new VPS, investigating slow transfers, or comparing locations.

Option 1: the official Speedtest CLI (Ookla)

Ookla publishes a command-line client. Install from their repository (check speedtest.net/apps/cli for current instructions):

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

Run it:

speedtest

You’ll be asked to accept the license on first run. Output:

   Server: Example ISP - Los Angeles, CA (id: 12345)
      ISP: Your Host
  Latency:     1.02 ms   (0.08 ms jitter)
 Download:   925.33 Mbps (data used: 1.1 GB)
   Upload:   912.47 Mbps (data used: 1.2 GB)
Packet Loss:     0.0%

Choose servers:

speedtest -L                      # list nearby servers
speedtest -s 12345                # test against a specific server ID
speedtest -f json-pretty          # machine-readable output

Note that each test transfers a gigabyte or more on a fast port — it counts against monthly transfer allowances.

Option 2: speedtest-cli (Python, unofficial)

The older Python tool is in many distributions’ repositories:

sudo apt install speedtest-cli
speedtest-cli --simple
speedtest-cli --list | head
speedtest-cli --server 12345

It’s convenient but less accurate at high speeds (single-threaded, Python overhead) and may break when Ookla changes its servers. Prefer the official client for gigabit links.

Option 3: download a test file

Many networks and data centers host test files. A quick download test:

curl -o /dev/null -w "Downloaded %{size_download} bytes at %{speed_download} bytes/s\n" https://speed.example.net/1GB.bin
wget -O /dev/null https://speed.example.net/1GB.bin

Divide bytes/s by 125,000 to get Mbit/s. Pick test files hosted near the region you care about — a file in Frankfurt tells you about the path to Europe, not your server’s port.

Option 4: iperf3 between your own machines

For the most controlled measurement — e.g. between two of your servers, or your server and your office — use iperf3. It removes third-party test servers from the equation.

Reading the results

  • Nearby servers measure the port. A test to a server in the same city shows your VPS’s port speed and local network capacity.
  • Distant servers measure the path. Across oceans, results fall because of latency and TCP behaviour — that’s normal. Use several parallel connections (Speedtest does) for realistic numbers.
  • Results vary by time of day. Peak-hour congestion on transit links is common; test at different times before drawing conclusions.
  • Upload matters for servers. A web server mostly uploads to visitors. Make sure that direction is healthy.
  • Small VMs can be CPU-limited during very high-speed tests; watch top while testing.

Latency usually matters more than bandwidth

For websites, APIs, SSH, games and trading, latency shapes the experience far more than raw bandwidth. A 1 Gbps server 200 ms away feels slower than a 100 Mbps server 10 ms away. Measure it with ping and mtr from where your users are — see ping, traceroute and mtr and latency vs bandwidth.

Test before you choose a location

Each of our location pages lists test IPs and a network test you can run from your own computer:

  • USA VPS — Los Angeles, New York, Chicago and Miami, 1 Gbps ports.
  • Hong Kong VPS — CN2 routes optimised for mainland China.
  • Japan VPS — Tokyo, for Japan and the wider Asia-Pacific.

Related: VPS bandwidth explained and choosing a VPS location.

  • Networking
  • Performance
  • Linux