How to Check Network Speed in Linux: The Essential Guide Every Admin Needs

Three in the morning. Coffee’s cold. Users are complaining that “the server is slow,” and you’re staring at a terminal trying to figure out if it’s actually the network or just Karen from accounting downloading her entire photo library again.

I’ve been there more times than I care to admit. Over my decade-plus running Linux systems, I’ve learned that knowing how to check network speed isn’t just a nice skill to have—it’s essential for keeping your sanity and your job.

Here’s the thing: “checking network speed” in Linux actually means several different things depending on what you’re trying to diagnose. Are you checking the link speed of your network interface? Testing your internet bandwidth? Measuring throughput between two servers? Each scenario needs a different tool, and I’m going to walk you through all of them.

Why You Actually Need to Check Network Speed

Before we dive into commands, let me tell you why this matters. I once spent three hours troubleshooting what I thought was a slow database query. Turned out the network interface had negotiated down to 100 Mbps instead of 1 Gbps because of a flaky switch port. One command would have shown me that immediately.

You need to check network speed when:

• Users report slow application performance and you need to rule out network issues
• You’re setting up a new server and want to verify it’s getting the expected bandwidth
• File transfers are crawling and you suspect a network bottleneck
• You’re troubleshooting intermittent connectivity problems

The key is knowing which tool to reach for. Let me show you the three main scenarios and exactly how to handle each one.

Checking Network Interface Speed with ethtool

This is usually my first stop when something feels off. The ethtool command shows you what speed your network interface card (NIC) has actually negotiated with the switch or router it’s connected to.

Installing ethtool

Most Linux distributions don’t ship with ethtool by default, but it’s trivial to install:

# Debian/Ubuntu
sudo apt install ethtool

# RHEL/CentOS/Rocky
sudo yum install ethtool

Basic Usage

First, you need to know your network interface name. If you’re not sure, check your network interface in Linux using ip link show or ip addr.

Then run ethtool with your interface name:

sudo ethtool eth0

You’ll get output that looks like this:

Settings for eth0:
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    Link detected: yes

The critical lines here are Speed and Duplex. In this case, we’re getting a full gigabit connection running in full-duplex mode—exactly what we want.

When Something’s Wrong

I’ve seen this scenario play out dozens of times: everything looks fine in your application logs, ping shows connectivity, but transfers are glacially slow. You run ethtool and see:

Speed: 100Mb/s
Duplex: Half

There’s your problem. Half-duplex at 100 Mbps is not what you want in 2025. This usually means either a cable issue, a switch port problem, or auto-negotiation failure. According to the Baeldung guide on verifying NIC speed, duplex mismatches are one of the most common causes of mysterious network slowdowns.

You can force the speed and duplex if needed:

sudo ethtool -s eth0 speed 1000 duplex full autoneg off

But honestly? If auto-negotiation isn’t working, you probably have a hardware problem that needs fixing.

Testing Internet Speed with speedtest-cli

When you need to know your actual internet bandwidth—like when your boss asks why the office connection “feels slow”—speedtest-cli is your friend. It’s the command-line version of speedtest.net, and it works on headless servers.

Installing speedtest-cli

There are multiple ways to install this, but I recommend using pip:

# Using pip (works on any distro)
sudo pip3 install speedtest-cli

# Or download directly from GitHub
wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod +x speedtest-cli
sudo mv speedtest-cli /usr/local/bin/

The official speedtest-cli repository has detailed installation instructions for every distribution.

Running a Speed Test

The simplest usage is just:

speedtest-cli

This will automatically select a nearby server and test your download and upload speeds. You’ll get output like:

Testing from Your ISP (123.45.67.89)...
Download: 856.73 Mbit/s
Upload: 42.18 Mbit/s

Useful Options I Actually Use

Test against a specific server (useful for consistency):

speedtest-cli --server 12345

Get JSON output for scripting:

speedtest-cli --json

I have this running in a cron job on critical servers to log bandwidth over time. When users complain about slowness, I can pull up the data and show them it’s not actually the connection—it’s their massive Slack workspace eating all the memory. (Speaking of which, checking memory usage in Linux is another essential troubleshooting skill.)

Measuring Network Throughput with iperf3

Here’s where things get interesting. ethtool shows you the theoretical maximum. speedtest-cli tests your internet connection. But what if you need to measure actual throughput between two specific Linux servers on your network?

That’s where iperf3 comes in. It’s the gold standard for network performance testing, and I use it constantly when setting up new infrastructure or troubleshooting connectivity between servers.

Installing iperf3

# Debian/Ubuntu
sudo apt install iperf3

# RHEL/CentOS/Rocky
sudo yum install iperf3

How iperf3 Works

You need two machines: one acts as the server (listener), and one acts as the client (initiator). The official iPerf documentation covers the protocol in depth, but the practical usage is straightforward.

On the server machine:

iperf3 -s

This starts iperf3 in server mode, listening on port 5201.

On the client machine:

iperf3 -c server-ip-address

This will run a 10-second test and show you the bandwidth:

[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec

Advanced iperf3 Techniques

Run a longer test (30 seconds instead of 10):

iperf3 -c server-ip -t 30

Test in reverse (server sends to client):

iperf3 -c server-ip -R

Use parallel streams for high-speed networks:

iperf3 -c server-ip -P 4

According to TechTarget’s iPerf best practices guide, parallel streams are essential when testing 10Gbps+ connections because a single stream often can’t saturate the link.

One warning: iperf3 will use all available bandwidth. Don’t run this on production links during business hours unless you want angry phone calls.

Real-Time Bandwidth Monitoring Tools

Sometimes you don’t need to run a test—you need to watch what’s happening right now. These tools show live network usage, and they’ve saved me countless hours of troubleshooting.

nload: Visual Bandwidth Monitor

sudo apt install nload
nload eth0

This gives you a beautiful ASCII graph of incoming and outgoing traffic in real-time. Perfect for watching traffic patterns and spotting spikes.

iftop: Connection-Level Monitoring

sudo apt install iftop
sudo iftop -i eth0

iftop shows you exactly which connections are using bandwidth, sorted by usage. When someone asks “what’s eating all our bandwidth,” this is how I find out.

nethogs: Process-Level Monitoring

sudo apt install nethogs
sudo nethogs eth0

This is my favorite for finding bandwidth hogs. nethogs groups traffic by process, so you can see that yes, it’s actually that backup job consuming 800 Mbps, not the database.

The comparison of bandwidth monitoring tools breaks down the differences beautifully: nload for visualization, iftop for connection details, and nethogs for process-level tracking.

Troubleshooting Common Network Speed Issues

Over the years, I’ve seen the same problems pop up again and again. Here’s what to check when network speed isn’t what you expect.

The Interface Negotiated Wrong Speed

Check with ethtool. If you’re seeing 100 Mbps instead of 1 Gbps, try a different cable, different switch port, or check for physical damage. I once traced slow speeds to a cable that had been run through a door jamb for six months.

High CPU Usage Is Limiting Throughput

Network processing takes CPU cycles. If you’re pushing gigabit speeds and checking CPU usage shows you’re pegged at 100%, that’s your bottleneck—not the network itself.

Duplex Mismatch

One side set to full-duplex, the other to half-duplex. This causes packet collisions and terrible performance. Both sides need to match, and auto-negotiation usually handles this unless there’s a hardware problem.

Firewall or QoS Limiting Traffic

Sometimes the network is fine, but something is rate-limiting you. Check firewall rules, QoS policies, and bandwidth shapers. Using traceroute can help identify where packets are being delayed.

Quick Reference: Which Tool When

Here’s my mental checklist for which tool to use:

• Interface not performing as expected? → Use ethtool to check negotiated speed and duplex
• Internet connection seems slow? → Use speedtest-cli to test bandwidth to the internet
• Need to verify throughput between two servers? → Use iperf3 for direct measurement
• Want to watch traffic in real-time? → Use nload, iftop, or nethogs depending on detail level
• Troubleshooting a specific slow application? → Start with nethogs to see which process is using bandwidth

Building Your Network Troubleshooting Toolkit

Checking network speed is just one piece of the system administration puzzle. When I’m tracking down performance issues, I’m usually cycling through several commands: checking network speed, then verifying disk usage isn’t maxed out, confirming services are running properly, and reviewing logs.

The real skill isn’t just knowing these commands—it’s knowing which one to reach for when you’re half-asleep at 3 AM and the pager is going off. Build muscle memory by actually using these tools, not just reading about them.

Network speed issues are inevitable in system administration. The difference between a good admin and a great one is how quickly you can isolate and fix them. Now you’ve got the tools—go use them before the next crisis hits.