Something on the box is listening on a port you don’t recognise. Or a service swears blind it started, and nothing can reach it. Either way the first question is the same, which is what’s actually open right now, and for a long time netstat was how everybody answered it.
What Is netstat?
Short for network statistics. It reads the kernel’s networking tables and prints them back at you: open connections, listening sockets, the routing table, per-interface counters, multicast groups. It ships as part of the net-tools package, which has been around roughly forever and turns up on just about every Unix-like system you’ll ever log into.
One thing to get out of the way early, though. netstat is deprecated, and has been for years. The ss command replaced it. On a lot of current distributions netstat isn’t even installed until you go and fetch net-tools yourself with apt or dnf. It still shows up everywhere regardless, in old runbooks, in half the answers on Stack Overflow, on that one server nobody has rebuilt since 2016. Which is exactly why it’s still worth being able to read.
Why Use netstat?
Nearly every network problem collapses down to three questions. Is anything listening on that port at all? Is the connection established or is it stuck in some other state? And which process owns it? netstat answers all three at once, and that’s really the whole reason it survived this long.
- Working out why a connection keeps getting refused
- Seeing which ports are open and what’s sitting behind them
- Watching connection states pile up when something’s going wrong
- Spotting a listener you definitely didn’t put there
Basic Usage
Run it bare and you get everything, unix domain sockets included, which is almost always more than you asked for:
netstat
Useful for about ten seconds. The flags are where it turns into an actual tool.
1. Display All Connections and Listening Ports
netstat -a
The -a is literally all: listening sockets and established connections together, in one list. On a busy server that’s a wall of text, so most people pair it with grep or narrow it down with -t for TCP only. Worth knowing that it pulls in unix sockets too, and those are hardly ever what you want when you’re chasing something over the network.
2. Show Listening Ports Only
netstat -l
Drops the established connections and leaves just the things sitting there waiting for someone to connect.
This is the one I reach for when a service insists it came up fine. It tells you whether the thing actually bound to a port, and often enough the answer is that it bound to 127.0.0.1 when you needed 0.0.0.0. Which looks identical in the service logs and is the entire problem.
3. Display Numerical Addresses
netstat -n
Left to itself, netstat tries to turn every address into a hostname and every port number into a service name. Fine when DNS is healthy. Less fine when you’re debugging a network issue, because DNS is frequently part of what is broken, and the command just sits there grinding through reverse lookups that are never coming back.
-n skips all of that and gives you raw numbers. Honestly, just get in the habit of always passing it.
4. Show Process IDs
netstat -p
Adds the PID and the program name, which is the difference between knowing something is on 8080 and knowing which specific java process is on 8080.
There’s a catch here that trips people up constantly. You need root to see processes you don’t own. Run it without sudo and that column comes back empty, and it reads like a bug in the tool rather than a permissions problem, so people waste a genuinely irritating amount of time on it.
5. Combine Options for Detailed Output
In practice almost nobody types those flags one at a time. They type this:
netstat -tulnp
Breaking it down:
- t: TCP connections
- u: UDP connections
- l: Listening ports
- n: Numerical addresses
- p: Show process information
TCP and UDP listeners, numeric addresses, and the process behind each one. That’s the answer to “what’s running on this machine and who is responsible for it” in a single line. Learn this one properly and you can more or less forget the rest.
Example Output
A trimmed sample:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1023/sshd tcp6 0 0 :::80 :::* LISTEN 1204/apache2
Reading left to right: the protocol, two queue columns, the local address, the foreign address, the connection state, then the process holding it.
Give those queue columns a look while you’re there. Recv-Q and Send-Q should both be sitting at zero on a healthy connection. Numbers stacking up in Send-Q generally mean the far end has stopped reading, and that’s a real signal rather than noise.
In the sample above, sshd is listening on 22 across every interface, and apache2 has port 80 over IPv6. That :: is just the IPv6 wildcard, same idea as 0.0.0.0.
Modern Alternatives
ss is the replacement, and it comes from iproute2 rather than net-tools. It pulls socket data straight out of the kernel instead of parsing files under /proc, so on a machine holding thousands of connections it’s noticeably quicker. It also does state filtering that netstat simply cannot.
The good news is that the muscle memory transfers. ss -tulnp does what netstat -tulnp does. If you already know the netstat flags you’re most of the way to knowing ss.
So reach for ss on anything current. Keep netstat in your head for the older boxes, because those are the ones that break.
Conclusion
netstat is old, officially on its way out, and you’re still going to end up using it. That’s not a contradiction. The servers that need debugging the most are rarely the new ones.
If you take one thing away, make it netstat -tulnp, with sudo in front of it. That single command covers most of what you’ll ever need netstat for.
Then go and learn ss -tulnp for everything after that.
