iftop: See Bandwidth by Connection in Real Time

sudo iftop -i eth0 shows a live, scrolling table of bandwidth grouped by connection: each pair of hosts talking to each other, with the send and receive rate for every pair. It is the answer to "something is saturating this link, what is it?" The iftop command listens on one interface, resolves the busiest host pairs, and redraws the table a couple of times a second so you can watch the traffic move.

The thing to know up front: iftop almost always needs root, because it puts the interface into promiscuous mode and reads packets directly (same as tcpdump). Run it with sudo. The second thing: it defaults to the first interface it finds, which is frequently the wrong one on a multi-NIC box, so get in the habit of passing -i explicitly. Everything else on this page is making the output readable (-n, -N, -P), reading the three rate columns correctly, and scoping with a filter.

The one-liner

sudo iftop -i eth0

That opens the full-screen display on eth0 and starts charting bandwidth per host pair. Press q to quit. If you omit -i, iftop picks the first non-loopback interface from the system list, which on a server with eth0, eth1, and a few veth/docker0 virtual interfaces is rarely the one you meant. Always name the interface. List your interfaces first with ip -br link if you are not sure what they are called.

Reading the display

The body of the screen is one row per host pair. The left column is the local end, the right column (after the => / <= arrows) is the remote end. The three numeric columns on the right are the moving averages of the transfer rate:

The => row is traffic leaving the local host (transmit) and the <= row is traffic arriving (receive). At the very bottom, iftop prints cumulative totals: TX (sent), RX (received), and TOTAL, each with peak and cumulative figures for the run. Rates are shown in bits per second by default (Kb, Mb, Gb), not bytes, which trips up everyone the first time. A "100Mb" reading is 100 megabits, roughly 12.5 megabytes per second.

Make the output readable: -n, -N, -P

A default iftop run does reverse DNS on every address and hides ports, which is the opposite of what you usually want when you are chasing a problem. Three switches fix it.

sudo iftop -i eth0 -n -P

-n turns off DNS resolution, so you see raw IP addresses instead of hostnames. This matters for two reasons: reverse lookups add latency and can stall the display, and on a busy host the constant DNS chatter from iftop itself shows up in the very table you are reading. -P turns on port display, appending :443, :22, :5432 and so on to each address so you can tell HTTPS from SSH from Postgres at a glance. -N is separate: it stops port numbers being resolved to service names, so a displayed port reads :443 rather than :https. It only affects how ports are labelled, so it is something you pair with -P (which is what turns port display on in the first place). Reach for -n -P when debugging; it is the most honest view.

Scope it with a filter

iftop accepts a Berkeley Packet Filter (BPF) expression after -f, the same syntax as tcpdump. This is how you stop watching everything and focus on one host, one port, or one protocol.

sudo iftop -i eth0 -n -P -f "port 443"

That restricts the capture to traffic on port 443, so the table only shows HTTPS connections. A few more that earn their keep:

sudo iftop -i eth0 -n -f "host 10.0.0.5"
sudo iftop -i eth0 -n -P -f "src port 22"
sudo iftop -i eth0 -n -f "net 192.168.1.0/24"

The first watches all traffic to or from a single host, the second isolates outbound SSH, the third scopes to one subnet. The filter is applied at capture time (it is a real BPF program, not a display filter), so it also reduces the load iftop puts on the box. You can edit the filter live without restarting: press f inside the running display and type a new expression.

For the common case of scoping to one network rather than building a BPF expression, iftop also takes -F net/mask for IPv4 (-G for IPv6), for example sudo iftop -i eth0 -n -F 192.168.1.0/24. This is a display-side filter on the source or destination network, narrower than -f but quicker to type when all you want is "just this subnet".

A worked example

Say a web server is pinned at its bandwidth cap and you want the culprit. Start broad on the public interface, IPs not names, ports on:

sudo iftop -i eth0 -n -P

The table sorts by the 10-second average with the heaviest talkers at the top. Suppose the top row reads:

198.51.100.23:443        =>     12.4Mb   11.8Mb   9.30Mb
                         <=      820Kb    790Kb    410Kb

That single remote client is pulling roughly 12 megabits a second of outbound traffic on 443. Now confirm by scoping to it and watching the trend column settle:

sudo iftop -i eth0 -n -P -f "host 198.51.100.23"

If the 40-second column holds steady near 12Mb, that one connection is your sustained load, not a momentary spike. From here it is a firewall rule or a rate-limit, but iftop has already told you the where and the how-much in under a minute.

Useful interactive keys

Once iftop is running, single keypresses reshape the view without a restart:

• p toggles port display on and off (same as launching with -P).
• n toggles DNS resolution (same as -n, but inverted: it enables/disables lookups live).
• P (capital) pauses the display so you can read a frozen frame.
• t cycles the line-display mode: two lines per pair (send + receive), one combined line, send only, receive only.
• < and > change the sort column (by source, destination, or one of the rate averages).
• 1, 2, 3 sort directly by the 2-second, 10-second, or 40-second average respectively, a faster way to reorder the table than cycling with </>.
• j / k scroll the list when there are more pairs than fit on screen.
• f edits the filter code live.
• h shows the help screen with the full key list; q quits.

These are worth learning because the common workflow is "launch broad, then narrow interactively" rather than relaunching with new flags each time.

Caveats and distro differences

iftop is not always installed. On Debian and Ubuntu it is sudo apt install iftop; on RHEL, Rocky, and AlmaLinux it is in EPEL (sudo dnf install epel-release && sudo dnf install iftop); on Alpine it is apk add iftop. It depends on libpcap, which is why the filter syntax matches tcpdump.

A few honest limits:

• iftop shows rates, not processes. It tells you which hosts and ports are busy, never which PID owns the socket. To map a connection back to a process, pair it with ss -tanp or lsof -i, or reach for nethogs, which groups bandwidth by process instead of by connection. This is the network analogue of using iotop to find the process hammering your disk: same live-monitor pattern, different resource.
• It needs root, or CAP_NET_RAW. Running as an unprivileged user without that capability fails with a permission error on the pcap open. sudo is the normal answer; granting the capability with setcap cap_net_raw+ep $(which iftop) is the alternative if you genuinely cannot use sudo.
• The bits-vs-bytes default catches people. If you think in megabytes, either divide the reading by 8 or launch with -B to show rates in bytes per second instead. Pressing B toggles the same thing live.
• On very high-throughput links it can drop frames. iftop is a monitoring tool, not an accounting tool; for billing-grade totals use the kernel's own counters (/proc/net/dev, vnstat) rather than iftop's cumulative figures.

iftop vs nload vs the others

These tools answer different questions. Pick by what you are actually trying to learn.

Reach for iftop when the question is who is talking to whom and how loud. If you only need the aggregate throughput on an interface, a clean two-graph in/out view, nload is the lighter tool and does not need a filter expression to be useful. If you need to attribute traffic to a process rather than a remote host, nethogs is the one. And if you are mapping out what is actually listening or reachable rather than what is transferring, that is a scan job, not a monitor job: see the nmap command examples for the surface-area side of the same investigation.

See also

• nload: per-interface bandwidth graphs in the terminal: when you want total throughput on a NIC rather than a per-connection breakdown
• iotop: find which process is hammering your disk: the disk-IO counterpart to iftop, same "what is using this resource right now" workflow in the terminal
• nmap command examples: mapping open ports and reachable hosts, the discovery counterpart to watching live traffic
• External: iftop project homepage and man page, pcap-filter(7) for the BPF filter syntax.

FAQ