nethogs: Per-Process Bandwidth Monitor

Every other network monitoring tool tells you what's happening on your network. nethogs tells you who's responsible.

When your connection slows to a crawl, tools like iftop show traffic flowing between hosts and ports—useful, but incomplete. You see that something is saturating your upload bandwidth, but what? Which application? nethogs answers that question directly: it shows you a list of processes, sorted by how much bandwidth each one is consuming, right now.

How It Works

nethogs monitors network traffic and matches each connection to the process that created it. It does this by examining the /proc filesystem, where Linux exposes the relationship between network sockets and process IDs. No packet inspection, no application instrumentation—just direct process attribution.

The result is a real-time table showing process name, PID, user, network interface, and bandwidth (sent and received). The display updates every second by default, with numbers smoothed to prevent chaotic jumping.

Basic Usage

Run with root privileges:

sudo nethogs

Monitor a specific interface:

sudo nethogs eth0

Monitor multiple interfaces:

sudo nethogs eth0 wlan0

Set a custom refresh rate (in seconds):

sudo nethogs -d 5

Interactive Controls

While running:

• m — Cycle display modes: KB/s, total KB, total with time
• s — Toggle between sent, received, or both
• r — Force immediate refresh
• q — Quit

The Usual Suspects

Your computer is often doing things you didn't ask it to do.

System update services download hundreds of megabytes in the background. Package managers—apt, yum, dnf—don't ask permission. Cloud sync services (Dropbox, Google Drive, OneDrive) upload your files whether you're watching or not. Backup software runs on schedules you've forgotten. Torrent clients seed quietly.

nethogs reveals all of it. That mysterious bandwidth drain? Probably one of these.

Web browsers complicate things—Chrome spawns dozens of processes, so you might see multiple entries for a single browser. Container systems attribute traffic to the Docker daemon rather than individual containers. VPNs show all traffic as belonging to the VPN client, not the applications actually generating it.

Investigating Further

Once nethogs identifies a suspicious process, dig deeper:

# What files and connections does this process have open?
sudo lsof -p [PID]

# What's its process tree?
pstree -p [PID]

# What system calls is it making?
sudo strace -p [PID]

For packet-level analysis, use tcpdump with filters based on the ports or hosts you discover in lsof output.

Machine-Readable Output

For scripting and monitoring integration, use trace mode:

sudo nethogs -t

This outputs parseable lines showing process, sent bytes, received bytes—suitable for feeding into log aggregation or alerting systems.

Limitations

nethogs requires root privileges. No exceptions.

Process attribution works well for direct connections, but tunnels obscure the truth. Traffic through a VPN appears as the VPN client's bandwidth, not the applications behind it. Proxies and network namespaces create similar blind spots. Containerized environments often show traffic attributed to the runtime, not individual containers.

Most importantly: nethogs shows only what's happening now. It provides no historical data, no aggregation over time. For long-term monitoring, you need different tools—or scripts that capture nethogs output continuously.

When to Reach for nethogs

Use nethogs when bandwidth consumption seems wrong and you need to know which process is responsible. It answers one question extremely well: who on this machine is using my network right now?

For everything else—historical analysis, aggregate statistics, network-wide visibility—you need other tools. But for immediate process-level attribution, nethogs is unmatched.