How to Test Network Speed in Linux Terminal: speedtest-cli, iperf3 and the Zero-Install wget Trick

CodexFuse Team · 2026-11-04T10:14:13.290Z · 11 min read min read

Five ways to measure network speed from a Linux terminal: the official Ookla CLI, the archived speedtest-cli, fast-cli, iperf3, and a wget one-liner that needs nothing installed.

When you need to test network speed in Linux, the terminal is the fastest place to do it — especially on a headless server where no browser exists. A VPS hosting plan may advertise a 1 Gbps port, but the only number that matters is what your machine actually measures. The Linux command line gives you five solid ways to find out: the official Ookla Speedtest CLI, the older community speedtest-cli, fast-cli, iperf3 for machine-to-machine tests, and a wget one-liner that needs nothing installed at all.

This guide shows how to test network speed in Linux with five terminal tools, from the official Ookla CLI to a zero-install wget one-liner. It walks through all five from a Linux network speed test terminal workflow: the install commands, the exact flags to use, what each tool actually measures, and how to read the numbers on a datacenter link. Every command and download URL below was verified on 2026-11-04.

What is the fastest way to test network speed on Linux?

The fastest method depends on what you want to measure. Pick your lane first, then read the section for it:

Internet speed, properly: install Ookla's official speedtest CLI and run speedtest. It reports latency, jitter, packet loss, download and upload against a nearby Speedtest server.
Download speed, quickest: fast (fast-cli) — one command, minimal output, powered by fast.com.
Between two machines you own: iperf3 -s on one machine and iperf3 -c <server-ip> on the other. This tests your pipe, not the public internet.
Nothing to install: wget -O /dev/null https://cachefly.cachefly.net/100mb.test and read the transfer rate from the progress output.

The rest of this guide explains when each lane is the right one — and the traps inside the older guides.

Which Linux speed test tool should you use?

Use this table to pick before you install anything. The five tools answer different questions:

Tool	Install	Measures	Best for	Watch out for
Official Ookla `speedtest`	packagecloud repo, then `sudo apt install speedtest`	Latency, jitter, packet loss, download and upload vs a Speedtest server	The definitive internet-speed number	License limits it to personal, non-commercial use
`speedtest-cli` (community)	`pip install speedtest-cli` or `sudo apt install speedtest-cli`	Download/upload vs speedtest.net	Quick scripts following old guides	Repository archived April 2026; Debian warns it is increasingly inaccurate on fast connections
`fast-cli`	`npm install --global fast-cli` (needs Node.js 22.12+)	Download via fast.com (upload with `--upload`)	The fastest download-only check	First run downloads ~200 MB of Chrome through Puppeteer
`iperf3`	`sudo apt install iperf3`	Maximum achievable bandwidth between your own client and server	LAN and VPS-to-VPS throughput	Not an internet speed test — you need a server you control on the other end
wget/curl trick	Preinstalled on virtually every distro	Download rate from a real test file	Zero-install spot checks	Single file, single stream, download only

How do you install speedtest-cli on Ubuntu?

Below is the complete speedtest-cli Ubuntu setup: install it, run your first test, and learn which flags matter. You install it with pip install speedtest-cli (from the project's README) or sudo apt install speedtest-cli on Debian/Ubuntu — the package exists in Debian bookworm under that exact name. For script-friendly output, the README documents --simple ("Suppress verbose output, only show basic information"), --bytes ("Display values in bytes instead of bits") and --csv for machine-readable results. If you are on a desktop and just want the number quickly, our guide to checking your internet speed covers the browser route; the terminal route here is for servers and automation.

Know what you are installing, though: the sivel/speedtest-cli repository was archived by its owner on April 30, 2026 and is now read-only, with the latest release v2.1.3 dating back to 2021-04-08. The README itself warns, "There is the potential for this tool to report results inconsistent with Speedtest.net," and says issues about such inconsistencies "will be closed as wontfix." Debian's package page adds its own warning: "This tool has shown to become increasingly inacurate with high-speed connections." On a modern gigabit VPS, prefer the official CLI below.

Is speedtest-cli the same as Ookla's Speedtest CLI?

No — and the names are the trap. speedtest-cli is the archived community Python tool above; speedtest is Ookla's own official binary. Ookla describes it as "the first official Linux-native Speedtest application backed by Ookla," maintained by the Ookla team, and its manual states it "measures the latency, jitter, packet loss, download bandwidth, and upload bandwidth of the network connection between the client and a nearby Speedtest Server." That is a meaningfully richer test than the community tool's download/upload pair.

On Debian/Ubuntu you install it from Ookla's packagecloud repository, exactly as the repo page documents:

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

The version verified for this guide is 1.2.0.84 — the binary downloaded from install.speedtest.net on 2026-11-04 self-reports "Speedtest by Ookla 1.2.0.84 (ea6b6773cf)". Run speedtest with no arguments for the human-readable test, or speedtest -f json for machine output; the valid formats are human-readable (default), csv, tsv, json, jsonl and json-pretty, with the machine formats reporting in bytes. Two things the older blog guides get wrong: the official CLI has no --simple flag (human-readable is already the default), and its license restricts it to "personal, non-commercial use, through a command line interface on a personal computer" — read that line before scripting it on company infrastructure.

How do you test download speed with fast-cli on Linux?

The fast-cli Linux install is a single npm command: npm install --global fast-cli (Node.js 22.12 or newer required), then run fast. It tests your download speed using fast.com and prints a single number — the README shows output like "72 Mbps". Add --upload ("Measure upload speed in addition to download speed") when you need the uplink too, or --json for scripted parsing.

The one surprise: fast-cli "uses Puppeteer under the hood" and "on first run, it downloads Chrome (~200 MB) if it's not already installed," per the project's README. That makes it a poor fit for a minimal server you want to keep lean — it is really a desktop convenience tool. The project is active and MIT-licensed, but for servers, the official Ookla CLI or the wget trick below wastes less disk.

How do you run an iperf3 server/client test?

You run iperf3 in server mode on one machine and client mode on the other. Every iperf3 server client test follows the same two-command pattern. Install with sudo apt install iperf3 on both, then:

# on the server machine (listens on TCP port 5201 by default)
iperf3 -s

# on the client machine (10-second test by default)
iperf3 -c 203.0.113.10

The flags you will actually use, verbatim from the official man page: -t sets the test duration in seconds (default 10), -i sets the pause between periodic throughput reports, -P sets the number of parallel client streams, -R reverses the test so the server sends to the client, -u switches from TCP to UDP, and -J outputs JSON instead of human-readable text. A longer parallel test looks like iperf3 -c 203.0.113.10 -t 30 -P 4.

The critical distinction: iperf3 is "a tool for active measurements of the maximum achievable bandwidth on IP networks," developed by ESnet / Lawrence Berkeley National Laboratory — it measures the pipe between two endpoints you control, and says nothing about your internet speed to the outside world. Use it to answer "is the link between my two VPS machines actually delivering what the host claims," not "how fast is my internet." Note that iperf3 tests the raw pipe only; what your visitors feel also depends on TLS termination and any reverse proxy in front of your app. Version 3.22 was released 2026-09-29.

What is the zero-install wget speed test trick?

The trick is downloading a large test file straight to /dev/null and reading the transfer rate that wget prints — no package to install, no account, no test server to set up. The GNU wget manual documents -O /dev/null as discarding the download ("all will be concatenated together and written to file"), and wget's default progress display reports the rate when the transfer finishes:

wget -O /dev/null https://cachefly.cachefly.net/100mb.test

A real run of that command on 2026-11-04 finished with the line 2026-11-04 10:12:08 (2.28 MB/s) — that parenthesized figure is your measured download rate. The curl equivalent prints the average instead of a progress bar:

curl -o /dev/null -s -w '%{speed_download}\n' https://cachefly.cachefly.net/100mb.test

That printed 20131439 — bytes per second, per the curl manual's definition of speed_download. Divide by 1,000,000 for ~20.1 MB/s, multiply by 8 for ~161 Mbps. Two honest caveats: this tests download only, over a single stream, against one CDN — and the test-file URL matters. The cachefly URL above returned HTTP 200 with a Content-Length of exactly 104857600 bytes (100 MiB) when checked on 2026-11-04, but the speedtest.tele2.net URLs that older guides recommend timed out on the same day's checks, so don't copy those. Test-file URLs rot; verify with a HEAD request before you trust one.

What do speed test numbers mean on a datacenter link?

The classic check bandwidth Linux command is the wget trick from the previous section — but the numbers it prints still need interpreting. Download is what most people quote, upload matters as soon as your server serves traffic, and latency (plus jitter, the variation in latency) decides how "snappy" everything feels. On a datacenter link, three things routinely confuse first-time testers.

First, units: tools report in megabits per second (Mbps), while downloads show megabytes per second (MB/s) — divide by 8 to convert, so 161 Mbps is ~20.1 MB/s. Second, a single-stream test like the wget trick measures one TCP connection; real workloads open many, which is why iperf3 -P 4 often reports higher totals. Third, your VPS shares its host's uplink with neighbors, so test at different times of day before concluding anything — one slow reading at peak hour is not proof your provider is throttling you.

Finally, raw bandwidth is only half the story: how efficiently your stack uses it is the other half, which is why a fast link still feels slow on HTTP/1.1 — see our HTTP/2 guide for the protocol side of the same problem.

Sources

Every fact in this article was verified on 2026-11-04 from the sources below:

sivel/speedtest-cli GitHub repository — archived April 30, 2026; latest release v2.1.3 (2021-04-08); README flag definitions and the "inconsistent with Speedtest.net" warning
Debian speedtest-cli package page (bookworm) — the "increasingly inacurate with high-speed connections" warning
Ookla Speedtest CLI page (speedtest.net/apps/cli) — "the first official Linux-native Speedtest application backed by Ookla"
packagecloud ookla/speedtest-cli repository — the Debian install script line
Official Ookla Speedtest CLI 1.2.0 binary and bundled manual, downloaded from install.speedtest.net and executed — version string, --format options, measured metrics, personal non-commercial license
sindresorhus/fast-cli GitHub repository — install command, Node.js 22.12+ requirement, Puppeteer/~200 MB Chrome first-run note, --upload flag
iperf.fr and the esnet/iperf GitHub repository (official iperf3.1 man page) — bandwidth-measurement definition, port 5201, 10-second default, all flags, version 3.22 (2026-09-29)
GNU Wget manual — -O/--output-document behavior and the default progress display
curl man page (curl.se) — -w/--write-out and the speed_download definition
Author's live tests, 2026-11-04 — HEAD checks on the cachefly and tele2 test-file URLs, plus the wget and curl runs quoted above

Frequently Asked Questions

Is speedtest-cli the same as Ookla's Speedtest CLI?

No. speedtest-cli is the community Python tool whose repository was archived in April 2026; speedtest is Ookla's official binary. They share a name pattern and a heritage, but different authors, different commands, and different accuracy on modern connections.

Why is my VPS speed test slower than the advertised port speed?

Usually one of three things: you ran a single-stream test against a shared uplink at a busy hour, the test server was far away or congested, or you compared megabits to megabytes. Re-test with parallel streams (iperf3 -P 4), at different times of day, before drawing conclusions.

Can I test upload speed without installing anything?

Not meaningfully — the wget/curl trick is download-only. For upload, install fast-cli and run fast --upload, or use Ookla's official speedtest CLI, which measures upload in every run.

Which port does iperf3 use?

TCP port 5201 by default. Your client must be able to reach that port on the server machine, so check the server's firewall if the client hangs on connect.

Is fast-cli accurate enough for server testing?

It gives a reasonable download number via fast.com, but it is built for desktops: it needs Node.js 22.12+ and downloads ~200 MB of Chrome on first run. On a lean server, the official Ookla CLI or the wget trick gives you the number with far less baggage.