netstat

What it does

netstat displays a snapshot of networking state on the local machine: active TCP/UDP connections and their states (ESTABLISHED, LISTEN, TIME_WAIT, etc.), ports currently listening for connections and the process that owns them, the kernel's IP routing table, and per-interface traffic statistics. It's one of the most commonly reached-for tools for answering "what's this machine talking to" and "what's listening on this box," even though it's formally deprecated in favor of ss on Linux.

Beginner examples

• netstat -a — list all connections and listening ports (with hostname/service-name lookups, which can be slow)
• netstat -an — same, but numeric (faster, no DNS lookups)
• netstat -l — show only sockets in the listening state
• netstat -r — show the kernel routing table

netstat -tulnp

Advanced examples

• The classic "what's listening and who owns it" combo: sudo netstat -tulnp — TCP + UDP, listening only, numeric, with PID/program name
• Find every connection to/from a specific remote IP during an investigation: netstat -an | grep 203.0.113.5
• Check for excessive TIME_WAIT connections that can indicate a connection-handling or load issue: netstat -an | grep TIME_WAIT | wc -l
• Inspect interface-level packet errors and drops alongside connection state: netstat -i

sudo netstat -tulnp | grep :5432

Common mistakes

• Running plain netstat -a on a busy machine without -n and waiting a long time while it does reverse-DNS lookups on every remote address — always add -n for speed unless you specifically need hostnames.
• Forgetting sudo/root when trying to see the PID/program column (-p) for sockets owned by other users — without root, those fields often show blank or "-".
• Assuming netstat is guaranteed to be installed — many modern minimal Linux images ship only ss by default, requiring the net-tools package for netstat.
• Misreading connection states — e.g., panicking over many TIME_WAIT entries, which is normal, expected cleanup behavior for recently closed TCP connections, not necessarily a problem.

Tips

• Memorize netstat -tulnp (or -nutlp) — it's the single most useful invocation for "what's listening on this machine and what owns it."
• Use -n by default to avoid slow reverse-DNS lookups unless you specifically want resolved hostnames.
• If netstat isn't installed, ss accepts nearly the same flags (ss -tulnp) and is the actively maintained replacement worth learning in parallel.

Best practices

• Prefer ss for new scripts and automation — it's faster (reads directly from the kernel rather than /proc parsing in some implementations) and is the tool the Linux networking stack maintainers actively develop.
• When auditing what's exposed on a server, run sudo netstat -tulnp as a first pass, then cross-check against your firewall rules to confirm only intended ports are reachable externally.
• Don't rely on netstat's presence in automation for production systems — check for ss first and fall back to netstat only if necessary, since minimal container images frequently lack net-tools entirely.

Real-world use cases

• Auditing a server to confirm which ports are actually listening and which processes own them, as part of a security review or incident response.
• Diagnosing connection pool exhaustion or leak issues by counting connections in each TCP state (ESTABLISHED, TIME_WAIT, CLOSE_WAIT).
• Checking the routing table on a multi-homed server to confirm traffic is taking the expected path.

Common interview questions

• Why is netstat considered deprecated, and what replaces it? It's part of the unmaintained net-tools package; ss (from iproute2) is the actively maintained replacement, offering more detail and better performance.
• What does a large number of connections in TIME_WAIT usually mean? It's usually normal — TIME_WAIT is the standard TCP state a connection sits in briefly after closing to ensure delayed packets are handled correctly; only treat it as a problem if it grows unbounded and correlates with actual resource exhaustion.
• How would you find which process is listening on port 8080? sudo netstat -tulnp | grep :8080 (or the ss equivalent, sudo ss -tulnp | grep :8080).