Finding bandwidth hogs on Linux

#linux #learning #beginners #tutorial

When a Linux server starts feeling slow, uploads stall, or network costs climb, top and htop can only tell part of the story. They show CPU and memory use, not which process is moving data.

For that, start with nethogs, then use iftop or ss to confirm what the process is connected to. If you are working in a stripped-down environment, /proc is still there as a fallback.

Install the tools

These packages are available on most Linux distributions:

# Ubuntu or Debian
sudo apt install nethogs iftop -y

# RHEL or Rocky Linux, with EPEL enabled
sudo dnf install nethogs iftop -y

# Arch Linux
sudo pacman -S nethogs iftop -y

net-tools is not needed for any command in this guide. ip and ss are normally provided by the already-installed iproute2 package. On RHEL-family systems, nethogs and iftop may not be enabled in the default repositories, so enable an appropriate repository first.

Start with `nethogs`

nethogs groups current network traffic by process and shows the PID when it can associate traffic with a local socket. It is the fastest way to find the program responsible for a spike.

sudo nethogs <interface>

Replace <interface> with the network interface you want to inspect, such as eth0. Run ip link show if you need to find its name.

Use this first. Once you have the PID or process name, you can investigate the connection behind it.

Check destinations with `iftop`

iftop shows bandwidth by pairs of hosts and their remote IP addresses. It does not identify the owning process, but it answers the next question: which hosts are involved?

sudo iftop -i <interface>

Run iftop beside nethogs when possible. One shows the process; the other shows busy host pairs and the direction of the data flow.

Verify sockets with `ss`

When you need to confirm a process's active TCP connections, use ss. It maps sockets to process names and PIDs.

sudo ss -tnp

-t shows TCP connections.
-n keeps addresses as raw IPs instead of looking up hostnames.
-p includes the process name and PID.

This is useful when nethogs points to a PID and you need to inspect its socket connections or send queue (Send-Q).

Use `/proc` on minimal systems

Containers, rescue shells, and stripped-down VMs may not have the monitoring tools installed. In that case, inspect the process's open file descriptors through /proc:

sudo ls -la /proc/<pid>/fd | grep socket

Entries such as socket:[123456] contain a socket inode number. Look for that inode in /proc/<pid>/net/tcp for IPv4 TCP or /proc/<pid>/net/tcp6 for IPv6 TCP. Use /proc/<pid>/net/udp* for UDP sockets. These paths inspect the target process's network namespace, which matters when it runs in a container.

Quick reference

Tool	What it shows	Use it for
`nethogs`	Bandwidth per program	Finding the process using traffic
`iftop`	Bandwidth by host pair	Identifying hosts and traffic flow
`ss -tnp`	Established TCP sockets	Mapping connections to PIDs
`/proc`	Socket inodes and protocol tables	Diagnosing minimal systems

A practical workflow

Run nethogs and identify the PID using the bandwidth.
Use ss -tnp to see that process's TCP connections; use iftop to identify busy host pairs on the same interface.
Confirm whether the traffic is expected before stopping anything.

Routine jobs such as cron tasks and rsync backups often explain a network spike. A backup that overlaps with another job can look suspicious until you match the PID to the process. Confirm the process identity before killing it.