Your server feels slow, but CPU and memory look fine. The culprit is often the network: a process hammering an external API, a container leaking connections, a misconfigured queue worker retrying thousands of failed jobs per minute. If you run a few Linux servers without a dedicated SRE, knowing which commands to reach for, and what numbers actually matter, saves you from chasing the wrong thing for an hour.
What you are actually trying to answer
Network monitoring on Linux usually comes down to four questions: How much bandwidth is each interface using right now? Which process or connection is responsible? Is the volume trending in a direction that will cause a problem? And are any external dependencies (SSL certificates, DNS, upstream APIs) quietly failing? Those four questions need different tools, and most guides only cover the first one.
The tools worth knowing, and when to use each one
Most Linux distributions ship with or can quickly install the following. You do not need all of them; knowing what each one is good at stops you from reaching for the wrong one.
- ss: the modern replacement for netstat. Shows every open socket, which process owns it, and its state. Fast and accurate. Use it first.
- ip -s link: reads interface counters directly from the kernel. Good for a quick bytes-in/bytes-out snapshot without installing anything.
- nload: a terminal dashboard showing per-interface throughput in real time, in and out, with a rolling average. Easy to read at a glance.
- iftop: shows bandwidth per connection pair (source IP to destination IP), sorted by volume. Useful for spotting a specific remote host consuming disproportionate bandwidth.
- nethogs: groups bandwidth by process rather than by connection. This is the tool to reach for when you know the interface is busy but not which process is responsible.
- tcpdump: raw packet capture. Overkill for everyday monitoring but essential for diagnosing TLS handshake failures, DNS misbehaviour, or unexpected traffic on a port.
- vnstat: logs interface traffic to a small database and lets you query hourly, daily, and monthly totals. Lightweight and persistent across reboots.
A practical command sequence for diagnosing traffic in five minutes
Run these in order. Each one narrows the search. The expected output comments explain what you are looking for.
# 1. Check raw interface counters (no install needed)
ip -s link show eth0
# Look for: RX errors > 0 or TX dropped > 0 -- these suggest a hardware or MTU issue
# 2. See total throughput per interface in real time
# Install: apt install nload OR yum install nload
nload eth0
# Look for: Curr (current) vs Avg; spikes well above the average warrant investigation
# Press right arrow to switch interfaces; q to quit
# 3. Find which remote hosts are taking the most bandwidth
# Install: apt install iftop OR yum install iftop
sudo iftop -i eth0 -n
# -n suppresses DNS lookups so the display updates faster
# Look for: any single host consuming > 50% of visible bandwidth
# Press p to toggle ports; q to quit
# 4. Find which local process owns the traffic
# Install: apt install nethogs OR yum install nethogs
sudo nethogs eth0
# Look for: a process with send+received KB/s far above the others
# Press q to quit
# 5. Check open connections and listening ports
ss -tulnp
# -t TCP -u UDP -l listening -n numeric -p process
# Look for: unexpected LISTEN entries on ports you did not open
# 6. Count connections per remote IP (useful for spotting floods)
ss -n state established '( dport = :443 or dport = :80 )' \
| awk '{print $5}' \
| cut -d: -f1 \
| sort | uniq -c | sort -rn | head -20
# Look for: any single IP with > 100 simultaneous connections
# 7. Check historical daily traffic totals
# Install: apt install vnstat OR yum install vnstat
# Then enable and start: systemctl enable --now vnstat
vnstat -d
# Look for: days where RX or TX is 2-3x the usual daily average
What to alert on: concrete thresholds
Tools give you numbers. Thresholds turn numbers into actionable signals. The right threshold depends on your server's role, but the following starting points work for most application servers.
- Inbound bandwidth sustained above 80% of your provisioned link for more than five minutes: alert immediately. On a 1 Gbps port, that is 800 Mbps. On a shared 100 Mbps DigitalOcean droplet, it is 80 Mbps.
- TX errors or RX drops on an interface greater than zero over a five-minute window: worth a warning. A handful of drops is normal; a steady climb suggests a congested uplink or a misconfigured MTU.
- Established TCP connections to a single remote IP exceeding 200: investigate for a connection leak or an aggressive client. Web scraper traffic often looks like this.
- CLOSE_WAIT connections growing and not draining: the local application is not closing sockets properly. Check your application process first with nethogs.
- A new LISTEN port that was not there yesterday: treat as a security event until proven otherwise. ss -tulnp captures a snapshot; diff two snapshots taken 24 hours apart to spot changes.
- DNS resolution time exceeding 200 ms on repeated lookups: your upstream resolver may be failing over. dig +stats your-domain.com @8.8.8.8 shows the query time in the stats section.
Rule of thumb: before you add network capacity, check whether a single process or a single remote IP is responsible. Scaling the network when one misbehaving process is the cause wastes money and leaves the real problem in place.
How to monitor containers, services, and SSL alongside network traffic
Network traffic rarely fails in isolation. A spike in outbound traffic from a container often means a queue worker is retrying failed jobs at high frequency, or a deployment pushed bad code that is logging errors in a tight loop. Watching the network without watching what is generating the traffic leaves you guessing.
For Docker containers, cgroup-level network counters are exposed in /sys/fs/cgroup/net_cls and through the Docker stats API. Running docker stats --no-stream gives you a per-container snapshot of network I/O alongside CPU and memory. If you run Laravel on a server and use Horizon or Supervisor to manage queue workers, a worker that is crash-looping will produce a burst of short-lived connections that look like a traffic spike in iftop. The guide on how to monitor containers on a VPS covers the cgroup approach in more detail.
SSL certificate expiry is a network-adjacent problem that catches teams off guard. A certificate that expires quietly takes down HTTPS traffic with no process crash and no disk alert. You can check expiry from the command line with: echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates. The notAfter line tells you when it expires. Automate a check that alerts at 30 days and again at 7 days.
DNS monitoring sits in the same category. A domain whose nameserver TTL has changed, or whose A record has been altered, will cause traffic to disappear rather than spike. A daily dig check against an authoritative nameserver and a trusted public resolver lets you spot divergence quickly.
When manual tools are not enough for a production fleet
The commands above are exactly what you should run during an active incident. For ongoing visibility across multiple servers, you need something that runs those checks continuously, stores the trends, and tells you when a threshold is crossed, without you staying logged in. A linux server monitoring tool that auto-discovers listening ports, tracks connection counts over time, and correlates a network spike with a log burst saves significant investigation time.
Opservo installs with a single command and auto-discovers listening ports, Docker containers, systemd services, and SSL certificate expiry on every server it monitors. When a network threshold is crossed, it correlates the spike with log entries from the same time window and surfaces a plain-English explanation of what changed. For Laravel monitoring, it watches Horizon and Supervisor workers and alerts if one stops or enters a crash loop, which is often the source of that unexpected outbound traffic surge. Remote actions are opt-in per server, so every fix command is approved and audited before it runs.
# Install the Opservo agent (Linux only; single static binary under 10 MB)
curl -sSL https://api.getopservo.com/install.sh | sudo bash
# No inbound ports opened; all traffic is outbound HTTPS
# First findings appear within five minutes
Install the Opservo agent on up to two servers free (no card required) to get continuous network-threshold alerts, port-change detection, and SSL expiry monitoring without staying logged in. — one command installs a read-only agent and your first findings arrive in five minutes: start free. Related: guides monitor docker containers on a vps.
Originally published on the Opservo blog.
Top comments (0)