netstat Cheatsheet - Linux Network & Ports
Three questions dominate operations: is this port open, who is connected to me, who is sitting on that socket. netstat answers them by laying out four kernel tables at once — established sockets, listeners, the routing table and per-protocol counters. The three flags combine in ways worth memorising: -l restricts output to listeners, -n suppresses name resolution (which costs runtime and turns 10.0.0.1 into a counter-intuitive hostname), and -p attaches the owning process. For routine checks, -tlnp answers everything in one line. The state-filtering group turns output into a diagnostic instrument: a pile of TIME_WAIT means short connections by the thousand, a SYN_RECV backlog suggests SYN flood or a full accept queue, and accumulating CLOSE_WAIT is an application bug that never closed the peer handle. The routing group answers which interface traffic leaves by, which beats guessing at IP addresses. The final group points at ss and ip as faster replacements, with netstat kept for older scripts.
Typical Use Case
For back-end and operations engineers diagnosing network connections and port conflicts. netstat has essentially one job: answering "what is holding this port" and "what state are the connections in". This sheet is organised into seven groups: connection viewing, listening ports, routes and interfaces, protocol statistics, state filtering and troubleshooting, advanced options, and replacement tools. Note that ss and ip equivalents are given throughout — netstat is being phased out, and their output is considerably cleaner.
View Connections 6
netstatnetstat -anetstat -atnetstat -aunetstat -annetstat -anpListening Ports 6
netstat -lnetstat -ltnetstat -lunetstat -lxnetstat -lntpnetstat -lnupRouting Table & Interface Stats 5
netstat -rnetstat -rnnetstat -inetstat -ienetstat -rn | grep UGProtocol Statistics 5
netstat -snetstat -stnetstat -sunetstat -s | grep -i errornetstat -s | grep -i retransFilter by State & Troubleshoot 6
netstat -an | grep ESTABLISHEDnetstat -an | grep TIME_WAITnetstat -an | grep :80netstat -lntp | grep :80netstat -an | awk '{print $6}' | sort | uniq -cnetstat -an | grep ESTABLISHED | wc -lAdvanced Options 6
-n-p-c 1-o-e-vAlternatives (ss / ip) 5
ss -tlnpss -tn state establishedss -sip addrip routeParameter matrix
| Parameter | Effect | Example |
|---|---|---|
-l | Show only listening connections | netstat -lt |
-n | Do not resolve host and port names; faster output | netstat -an |
-p | Show the PID and process name holding the port (requires root) | netstat -lntp |
-a | Include all listening and non-listening connections | netstat -an |
-t / -u | TCP only / UDP only | netstat -at |
-e / -i | Append user and inode columns / interface statistics | netstat -ie |
-r | View the routing table | netstat -rn |
-s | Per-protocol statistics | netstat -st |
-c 1 | Refresh once per second to watch changes in real time | netstat -c 1 |
grep ESTABLISHED | Filter out established connections | netstat -an | grep ESTABLISHED |
grep TIME_WAIT | Filter out connections waiting to close | netstat -an | grep TIME_WAIT |
ss -tlnp | Modern replacement: faster with clearer output | ss -tlnp |
ip addr | View network interfaces (replaces ifconfig) | ip addr |
ip route | View the routing table | ip route |
Common pitfalls
SymptomThe PID column shows -, so you cannot see which process holds the port.
CauseViewing process information requires root, and a regular user cannot see the process mappings of other users.
FixRe-run with sudo; or use ss -tlnp together with permission checks.
SymptomThe port is clearly in use, yet netstat shows no listening record.
CauseThe service only bound to 127.0.0.1 while being accessed externally, or the protocol is UDP but you only looked at TCP.
FixUse netstat -anp to see TCP and UDP together; confirm whether the address the service bound to is only the local loopback.
SymptomRunning netstat is very slow, almost hanging when there are tens of thousands of connections.
CauseBy default it resolves host and port names, and -p requires a process mapping lookup.
FixAdd -n to skip resolution (most effective); on newer systems switch to ss, which reads kernel data directly via netlink.
SymptomThe number of TIME_WAIT connections explodes and short-lived connection ports run out.
CauseA large number of short connections remain in a waiting state after closing, and the kernel must hold them for a while before releasing the port.
FixSwitch to long-lived connections or a connection pool; temporarily you can tune net.ipv4.tcp_tw_reuse, but the real fix is the connection design.
SymptomYou see ESTABLISHED connections but the server does not seem to be listening.
CauseThe connection may be an orphan left by an exited process, or a TIME_WAIT remnant.
FixCross-check with -p and ss -tn state established; if needed restart the relevant service to clean up.
Symptomnetstat output format differs across systems, breaking script parsing.
CauseBSD and Linux netstat differ in column meanings and option support.
FixSwitch to ss uniformly (its format is more consistent across distributions); always use -n in scripts.
Troubleshooting
1Find which process holds a port
netstat -lntp | grep :80Root is required to see the PID; this is the fastest step for port-related problems.
2Summarize the current connection state distribution
netstat -an | awk '{print $6}' | sort | uniq -cThe count of each state is clear at a glance, most useful when ESTABLISHED or TIME_WAIT spikes.
3Count active connections
netstat -an | grep ESTABLISHED | wc -lSuits being placed in a monitoring script as a connection-count metric.
4Confirm the default gateway route
netstat -rn | grep UGWhen diagnosing can-ping-but-cannot-connect, first check whether the gateway is correct.
5The equivalent command on newer systems
ss -tlnpss reads the kernel directly via netlink, an order of magnitude faster than netstat, with more readable output.
Command Examples
Find what holds port 80
netstat -lntp | grep :80
# or the faster modern equivalent
ss -tlnp | grep :80-l shows only listening, -n skips resolution, -t shows TCP only, -p shows the process, and the last one requires root. On newer systems prefer ss; reading the kernel via netlink is much faster.
Output
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1420/nginx
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1420,fd=6))Count connections by state
netstat -an | awk '{print $6}' | sort | uniq -c | sort -rnA large backlog of TIME_WAIT usually means connections are not reused; many CLOSE_WAIT means the peer has closed but the local side has not released in time, so check the connection handling on the application side.
Output
2841 ESTABLISHED
312 TIME_WAIT
118 LISTEN
47 CLOSE_WAITFilter established connections with ss
ss -tn state established | headState filtering in ss is first-class, needing no grep pipe, and its output is tidier. Use it to take a baseline when investigating connection leaks.
Output
ESTAB 0 0 10.0.0.5:52344 93.184.216.34:443 ESTAB 0 0 10.0.0.5:41890 151.101.1.140:443
Common Pitfalls
- Without -n, netstat performs reverse DNS lookups and becomes unusably slow on large outputs; always pass -n.
- -p needs root to show the owning process; as a normal user that column is simply absent.
- A flood of TIME_WAIT does not automatically call for kernel tuning — first check whether the app opens a new TCP connection per request and whether keep-alive can be enabled.
- netstat is being superseded by ss on modern systems; prefer ss in new scripts and keep netstat for legacy hosts.
- An unreachable port may be a firewall rather than a stopped service: netstat proves local listening only, not external reachability.
Tips
- netstat is being replaced by ss; on newer systems prefer ss (faster, modern).
- Viewing processes needs root, otherwise the PID column shows -.
- Too many TIME_WAIT means frequent short connections; consider long-lived connections or a pool.
- netstat -an is fastest; -p slows it down by mapping processes.
- ss reads kernel data via netlink, an order of magnitude faster than netstat.
- The most common port-occupancy check is netstat -tlnp | grep <port>.
FAQ
How do I find which process is using port 80?
Run netstat -lntp | grep :80 — -l for listening only, -n to skip name resolution, -t for TCP, -p to show the owning process, which requires root. On modern systems prefer ss -tlnp: it is faster and cleaner. Once you have the PID, ps -p <pid> -o pid,cmd confirms the program.
Do I need to worry about a buildup of TIME_WAIT connections?
A small number is normal: the side that closes first holds the state so the last segment can be delivered, and it clears in roughly 60 seconds. But tens of thousands in a short window means connection reuse is misconfigured — check whether your app opens a new TCP connection per request and whether keep-alive can be enabled. Start by measuring the trend with netstat -an | grep TIME_WAIT | wc -l before tuning anything like tcp_tw_reuse.
Should I use netstat, ss or lsof?
ss is the modern replacement — it reads kernel netlink directly and is much faster than netstat, so prefer it on current systems. netstat remains useful for portability across older machines and scripts. lsof -i :80 is better for the reverse lookup: once you know the port or process, it shows which files and network connections it holds. They are often used together.
Why is netstat so slow without -n?
Because it tries to reverse-resolve every IP to a hostname and look up port numbers as service names like http or ssh, which can trigger many DNS lookups per query. On large outputs that dominates the runtime. Adding -n prints raw IPs and port numbers and the speedup is dramatic, which is why -ntp is the combination everyone memorizes.
What can netstat -s tell me when diagnosing the network?
-s prints cumulative counters per protocol layer. Two lines matter: netstat -s | grep -i error for the error packet total, and netstat -s | grep -i retrans for TCP retransmissions. An elevated retransmission rate usually points to packet loss, congestion, or a slow peer rather than a problem on your host. Since these are monotonic counters, run it twice with a gap and diff for a better signal.
Official References
Each command links to its official documentation below, so you can verify the latest usage and read deeper.
Maintained by LaoHand
Publicly updated on Jul 21, 2026, continuously proofread against official docs.
Contact Us
Wrong command or description? Send us corrections, business inquiries or product feedback by email.
Contact Us