For twenty years, the reflex for “what’s happening on my network?” was netstat -s. In 2026, that reflex is quietly wrong. On modern Linux, netstat is deprecated, sometimes not even installed, and it reads network state in a way that can be both slower and subtly misleading. Its replacements—ss and nstat—are faster, more accurate, and already on your systems.
But they don’t do the same job. Reach for the wrong one and you’ll either get a number that’s stale, a number that’s cumulative-since-boot when you wanted “right now,” or a socket list that took ten seconds to print. Here’s how the three compare, what each is actually for, and which one tells the truth.
Table of Contents
The short answer
ss— the truth about sockets right now: who’s connected, in what state, how big their queues are. Replacesnetstat -tuanp.nstat— the truth about protocol counters over time: how many SYNs, retransmits, drops, and resets happened in the last N seconds. Replacesnetstat -s.netstat— the legacy tool that did both, less accurately, from/proc/net. Fine in a pinch; not what you standardize on in 2026.
If you remember nothing else: ss for connections, nstat for counters, netstat only when neither is available.
Why netstat fell out of favor
netstat ships in the net-tools package, which upstream has treated as effectively unmaintained for years. Minimal container images and modern distros increasingly omit it—run netstat in an Alpine or slim Debian container and you’ll often get command not found.
Beyond availability, there are real technical reasons:
- It parses
/proc/net/tcpline by line. On a host with tens of thousands of sockets, that’s slow and can produce an inconsistent snapshot as the tables change mid-read. netstat -smixes and relabels counters in ways that don’t map cleanly to the kernel’s SNMP names, making it harder to correlate with documentation or monitoring.- It’s cumulative-since-boot with no built-in delta, so “is this happening now?” requires manual subtraction.
None of this means netstat lies outright—but it’s the least precise of the three, and the ecosystem has moved on.
ss: the truth about sockets right now
ss (“socket statistics”) talks to the kernel directly via the netlink interface instead of scraping /proc. That makes it dramatically faster on busy hosts and gives a more consistent snapshot.
Everyday commands:
# All TCP sockets: listening + established, numeric, with process names
ss -tanp
# Just listening sockets and their backlog
ss -ltn
# Summary of sockets by state (fast health check)
ss -sWhat ss shows that matters:
- Socket states —
ESTAB,TIME-WAIT,SYN-SENT,LISTEN, etc. Recv-Q/Send-Q— on a listening socket, these expose backlog pressure; a growingRecv-Qon a listener means connections are arriving faster than the app is callingaccept().- Filters —
sshas a real query language:ss -tn state established '( dport = :443 or sport = :443 )' ss -tn state time-wait | wc -l # count TIME_WAIT sockets ss -tln 'sport = :22' # is sshd actually listening?
If your question is “who is connected, in what state, and are the queues backing up?”—ss is the source of truth.
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
nstat: the truth about counters over time
nstat reads the same SNMP-style counters as netstat -s (from /proc/net/snmp and /proc/net/netstat), but it’s built for the question that actually matters: what changed, and how fast?
The killer feature is delta mode. nstat keeps a per-user history file, so a bare nstat prints only what changed since you last ran it:
# Reset the baseline, wait a representative window, show the delta
nstat -n; sleep 10; nstatUseful invocations:
# Show all nonzero counters (full snapshot)
nstat -az
# Watch specific TCP health signals over 10s
nstat -n; sleep 10; nstat | grep -Ei 'ActiveOpens|PassiveOpens|AttemptFails|Retrans|ListenOverflows'Counters worth watching:
TcpActiveOpens/TcpPassiveOpens— client vs server connection rate.TcpAttemptFails— failed connection attempts (the alarm bell).TcpExtListenOverflows/TcpExtListenDrops— accept-queue overflow.TcpRetransSegs/TcpExtTCPSynRetrans— retransmissions, a network-quality signal.TcpEstabResets— abrupt teardowns.
Because it maps directly to kernel counter names, whatever nstat shows lines up cleanly with your Prometheus/node_exporter metrics and the kernel docs.
Side-by-side
| Question | Best tool | Why |
|---|---|---|
| Who’s connected right now? | ss -tanp | Live socket table via netlink |
| Is my listener’s backlog overflowing? | ss -ltn (Recv-Q) + nstat (ListenOverflows) | Queue depth + drop counter |
| How many retransmits in the last 10s? | nstat | Delta over an interval |
| How many TIME_WAIT sockets? | ss -tn state time-wait \| wc -l | State filtering |
| Rate of failed connections? | nstat (TcpAttemptFails) | Counter delta |
| Quick overall socket summary | ss -s | One-line state breakdown |
| Nothing else is installed | netstat | Legacy fallback |
Translating your old netstat habits
Old netstat | Modern equivalent |
|---|---|
netstat -tuanp | ss -tuanp |
netstat -ltn | ss -ltn |
netstat -s | nstat -az (snapshot) or nstat (delta) |
netstat -i | ip -s link |
netstat -rn | ip route |
netstat -g | ip maddr |
The whole net-tools suite (netstat, ifconfig, route, arp) maps onto iproute2 (ss, ip) plus nstat. If you’re still typing the left column, 2026 is a good year to retrain the muscle memory.
A 30-second diagnostic using the right tools
Suppose an app reports intermittent connection failures. Skip netstat entirely:
# 1. Are connections failing at the kernel level, and how fast?
nstat -n; sleep 10; nstat | grep -Ei 'AttemptFails|ListenOverflows|SynRetrans'
# 2. Is the listener's accept queue backing up right now?
ss -ltn # watch Recv-Q on the affected port
# 3. What states are the sockets piling up in?
ss -sInterpretation:
AttemptFails+ListenOverflowsrising → accept-queue/backlog problem on this host (tunesomaxconn, fix a blocked accept loop).SynRetransrising, no overflow → network or upstream issue.- A wall of
TIME-WAITinss -s→ connection churn; add pooling/keep-alive.
Two tools, three commands, and every number maps to something you can act on.
So which one tells the truth?
All three read from the kernel—none of them “lie.” But they answer different questions, and in 2026 the precise answers come from the modern pair:
sstells the truth about sockets and their state right now.nstattells the truth about protocol counters and their rate of change.netstattold both truths for a generation, less precisely, and is now a fallback—useful when it’s all you have, but no longer the default.
Retire the netstat -s reflex. Use ss when you care about connections and nstat when you care about counters, and you’ll get faster, cleaner, more trustworthy answers every time.
