Your network is slow, but you don't know why
Your laptop feels sluggish, or your server's load average is climbing, and you suspect the network is the bottleneck. Maybe a background update is hammering the connection, or a misconfigured service is flooding the interface with retries. You need to see exactly what is moving across the wire, who is talking to whom, and which process is holding the bandwidth hostage.
GUI network monitors often lag behind the reality of the traffic. They poll at low frequencies and consume resources you are trying to save. Terminal-based tools read the packet counters directly from the kernel. They update in real time and show you the data without the overhead of a graphical stack.
What the tools actually measure
Network monitoring utilities slice the data differently. Choosing the wrong tool wastes time.
nload acts like a toll booth counter. It shows the total volume of data entering and leaving a specific interface. It does not care about IP addresses, ports, or processes. It tells you if the pipe is full.
iftop is a traffic camera that tracks conversations. It displays host-to-host connections sorted by bandwidth. It shows you the source and destination IPs, the ports, and the current throughput for each flow. It answers the question "Who is talking to whom?"
nethogs is a license plate reader attached to the process table. It groups traffic by the local process generating it. It tells you which executable is consuming bandwidth, even if that process is talking to multiple destinations. It answers the question "Which application is using the network?"
These tools require root privileges to capture packets. On Fedora, sudo is the standard mechanism. You do not need to switch to the root shell. Prefix the command with sudo to grant the necessary capabilities for packet capture.
Check the peak values, not just the current line. Bursts hide in the average.
Install and run the monitoring stack
Install the tools from the default repositories. Fedora includes all three in the base repos, so you do not need third-party sources or COPR.
sudo dnf install -y iftop nload nethogs
# -y skips the confirmation prompt for a clean install
# Installs the binaries and shared libraries from the Fedora base repository
Start with nload to check the aggregate throughput on your primary interface. This is the quickest way to confirm if the link is saturated.
sudo nload
# Shows real-time upload and download graphs for the default interface
# Press 'q' to quit, 'i' to toggle interface selection if multiple exist
When you need to see host-to-host traffic, switch to iftop. It displays a list of connections sorted by bandwidth usage.
sudo iftop -n
# -n disables DNS resolution for faster performance and cleaner output
# Shows top connections by bandwidth, updates every 2 seconds by default
If the traffic is high but you do not know which application is responsible, run nethogs. It groups traffic by process ID and executable name.
sudo nethogs
# Groups bandwidth usage by process, shows both TCP and UDP traffic
# Useful for identifying runaway downloads or background sync tools
Disable DNS resolution with -n. Resolving thousands of IPs will slow the tool down and obscure the data.
Read the output correctly
The tools provide raw numbers. You need to know which columns matter.
nload displays two graphs: one for incoming traffic and one for outgoing. Below the graphs, it lists statistics. Current is the instantaneous rate. Min and Max show the range since the tool started. Avg is the average rate. Ttl is the total bytes transferred. Watch the Max value to catch spikes that the average smooths out.
iftop output has several columns. SENT is the upload rate for that connection. RECV is the download rate. Cum is the cumulative data transferred since iftop started. Peak is the highest rate observed. Rates shows the average over 2, 10, and 40 seconds. The 40-second average is useful for spotting sustained transfers versus short bursts.
nethogs output includes DEV for the interface, UID for the user ID, PID for the process ID, and PROGRAM for the executable path. SENT and RECV show the bandwidth for that process. If multiple processes share the same executable name, nethogs lists them separately by PID.
Filtering traffic in iftop helps isolate specific hosts. Use the -f flag to apply a Berkeley Packet Filter expression.
sudo iftop -n -f "host 192.168.1.5"
# -f applies a BPF filter to show only traffic matching the expression
# Restricts output to traffic involving the specified IP address
Keybindings in iftop allow interactive filtering. Press s to filter by source IP, d to filter by destination IP, and P to toggle port display. Press p to pause the update cycle while you read the output.
Kill the process, then verify the traffic drops. Correlation is not causation until you see the effect.
Common errors and interface issues
nethogs requires a valid network interface. If you run it on a system with only a loopback interface active, it will print an error.
Error: No valid interface found
Ensure your network manager has brought up the interface before running the tool. Check the interface status with ip link.
ip link show
# Lists all network interfaces and their state
# Look for 'state UP' to confirm the interface is active
iftop may show zero traffic if you are monitoring a bridge interface while the traffic flows through a physical slave. Always specify the correct interface with -i if the default selection is wrong.
sudo iftop -i eth0 -n
# -i forces monitoring on the specified interface instead of the default
# Prevents monitoring the wrong device when multiple interfaces exist
If the interface name changes between reboots, check ip link to find the current name. Fedora uses predictable network interface names, but virtual machines sometimes shift names if the virtual hardware configuration changes.
iftop may fail with a permission error if sudo is not used or if the user lacks the CAP_NET_ADMIN capability.
Cannot open device: Permission denied
Run the command with sudo. Fedora's default sudoers configuration allows members of the wheel group to execute commands with elevated privileges.
If the network is completely unresponsive, check the service logs before blaming the application.
journalctl -xeu NetworkManager
# -x adds explanatory text, -e jumps to the end, -u filters by unit
# Shows recent errors and status changes for the network manager
Monitor the interface, not the application. The application can lie; the packet counter cannot.
Choose the right tool for the job
Use nload when you need a quick overview of total bandwidth consumption on a specific interface. Use iftop when you are debugging latency or need to identify which remote hosts are consuming the most bandwidth. Use nethogs when you need to pinpoint the local process responsible for network activity. Use ss -tulnp when you need a static snapshot of open sockets and listening ports. Use journalctl -xeu NetworkManager when the interface is missing or the tool reports no valid interfaces. Stay on the command line for monitoring; GUI tools add overhead and often lack the granularity of terminal-based utilities.