Use ss — it is the current standard on every modern Linux distro, and netstat is legacy there. On Ubuntu, Fedora, and Debian the netstat binary now ships in an optional net-tools package, while ss is built into iproute2 and installed everywhere. ss is also faster on busy servers because it reads socket statistics directly from the kernel instead of walking _/proc_ file by file. The catch is syntax: -tulpn does not mean the same thing everywhere, so this guide gives you the exact flag mapping, the commands worth memorising, and answers to the questions that come up when you are mid-incident at 2 a.m.
Is netstat deprecated?
On Linux, effectively yes. The net-tools package — which contains netstat, ifconfig, and route — has not tracked modern kernel features for years and is no longer installed by default on any major distribution. It still exists, still runs, and there is nothing to uninstall, but new features land only in iproute2 (the package behind ss and ip).
Three practical consequences:
- Missing on fresh installs. A default Ubuntu 24.04 or Fedora server has no
netstatuntil you installnet-toolsby hand. This is why so many people search for thenetstatequivalent — the binary is simply gone. - No modern socket info.
netstatpredates features like TCP fast open, subflow-level socket stats, and cgroup socket attribution.ssreports them natively. - The Windows exception. On Windows,
netstatis alive and well —netstat -anois still the standard way to map a PID to a listening port there. Only the Linux story is deprecation.
What is the ss command in Linux?
ss means “socket statistics”. It dumps the kernel’s view of every TCP, UDP, and Unix socket: state, addresses, ports, processes, timers, and queue depths. The workhorse form is:
# Everything listening, with the owning process
sudo ss -tulpnFlag by flag, that reads: TCP (-t), UDP (-u), listening sockets only (-l), show processes (-p), numeric output — no DNS lookups (-n). The sudo matters for -p: without root you see ports but get no process names for sockets you do not own.
Two more one-liners that cover most of the job:
# All established connections to/from port 443, with processes
sudo ss -tnp 'sport = :443 or dport = :443'
# Summary table: how many sockets in each state
ss -sThat filter syntax is a genuine upgrade over netstat’s grep-and-pray approach — it runs inside the kernel, so it is exact rather than text-matched.
How do you check which process is using a port?
This is the single most common reason to reach for either tool. With ss:
sudo ss -ltnp 'sport = :8080'Example output on a machine running a dev server:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 *:8080 *:* users:(("node",pid=214113,fd=18))The users:(...) field gives you the process name and PID directly — no second command needed. If the port is busy but no process shows, you are usually looking at a socket held by another network namespace (a container). From the host, run sudo ss -ltnp and look for the port with an empty process column, then match it with docker ps or nsenter into the container’s namespace.
Prefer a dedicated tool? sudo lsof -i :8080 -sTCP:LISTEN does the same job and works identically on macOS and most BSDs, which is why it survives in runbooks. On Linux, though, ss is already there.
What are the differences between ss and netstat?
Same job, different plumbing: netstat scrapes _proc/net/tcp_ in userspace, while ss uses netlink to ask the kernel directly — which is why ss returns in milliseconds on a server with 50k open sockets and netstat does not. Day to day, the difference is the flags. Here is the mapping worth taping to your monitor:
| You want | netstat | ss |
|---|---|---|
| Listening TCP ports + process | netstat -tlpn | ss -tlpn |
| All TCP + UDP connections | netstat -tulpna | ss -tulpna |
| Routing table | netstat -r | ip route |
| Interface statistics | netstat -i | ip -s link |
| Kernel socket summary | — | ss -s |
| Filter by port in-kernel | — | ss -tnp 'sport = :22' |
Notice the first two rows are identical: by luck, ss’s short flags line up with netstat’s for the common cases, so muscle memory mostly survives the move. The bottom rows are where netstat has no answer — the routing and interface jobs moved to the ip command, and the summary/filter rows only exist in ss.
When should you still use netstat?
Two honest cases. First, portability: on a mixed fleet of Linux, AIX, or older BSD boxes, netstat is the one syntax present everywhere. Second, muscle-memory continuity in old runbooks — if a runbook says netstat -tlpn and the box has net-tools installed, it still works fine.
Otherwise, default to ss and update the runbook. A useful companion when you are rewriting those runbooks on a server is the journalctl cheat sheet, which pairs naturally with port checks when you are diagnosing a service that will not start: /en/blog/2026-09-02/journalctl-cheat-sheet.
Why is the ss command not found?
Because you are either on a very old distro (pre-2007-era, before iproute2 was standard) or — far more likely — you are not on Linux at all. ss is not a macOS command; macOS ships lsof and netstat but no ss. Same for the BSDs, mostly. On Windows, use netstat -ano or PowerShell’s Get-NetTCPConnection.
If you genuinely are on Linux and ss is missing, install iproute2:
sudo apt install iproute2 # Debian/Ubuntu
sudo dnf install iproute2 # Fedora/RHELThe 30-second answer
ss over netstat on Linux, every time: it is preinstalled, faster, and can filter in-kernel. netstat -tlpn becomes ss -tlpn, process hunting becomes sudo ss -ltnp 'sport = :PORT', and routing tables belong to ip route now. Keep netstat for cross-platform scripts and old muscle memory; keep this page for the flag mapping.
— mrsaynothing