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 | 只显示监听中的连接 | netstat -lt |
-n | 不解析域名与端口名，输出更快 | netstat -an |
-p | 显示占用端口的 PID 与进程名（需 root） | netstat -lntp |
-a | 包含监听与非监听全部连接 | netstat -an |
-t / -u | 只看 TCP / 只看 UDP | netstat -at |
-e / -i | 附加用户与 inode 列 / 接口统计 | netstat -ie |
-r | 查看路由表 | netstat -rn |
-s | 各协议统计信息 | netstat -st |
-c 1 | 每秒刷新一次，实时观察变化 | netstat -c 1 |
grep ESTABLISHED | 筛出已建立连接 | netstat -an | grep ESTABLISHED |
grep TIME_WAIT | 筛出等待关闭的连接 | netstat -an | grep TIME_WAIT |
ss -tlnp | 现代替代：更快且输出更清晰 | ss -tlnp |
ip addr | 查看网络接口（替代 ifconfig） | ip addr |
ip route | 查看路由表 | ip route |
Common pitfalls
SymptomPID 列显示为 -，看不到是哪个进程占用端口。
Cause查看进程信息需要 root 权限，普通用户看不到其他用户的进程映射。
Fix加 sudo 重新执行；或用 ss -tlnp 配合权限确认。
Symptom端口明明被占用，但 netstat 里看不到监听记录。
Cause服务只绑定了 127.0.0.1 而从外部访问，或协议是 UDP 却只看了 TCP。
Fix用 netstat -anp 同时看 TCP 与 UDP；确认服务绑定的地址是否只是本地回环。
Symptom执行 netstat 很慢，连接数上万时几乎卡住。
Cause默认要解析域名与端口名，且 -p 需要查进程映射。
Fix加 -n 跳过解析（最有效）；新系统改用 ss，走 netlink 直接读内核数据。
SymptomTIME_WAIT 状态连接数暴涨，短连接端口耗尽。
Cause大量短连接关闭后处于等待状态，内核需保留一段时间才能释放端口。
Fix改用长连接或连接池；临时可调 net.ipv4.tcp_tw_reuse，但根治要看连接设计。
Symptom看到 ESTABLISHED 连接但服务端似乎没在监听。
Cause连接可能来自已退出的进程留下的孤儿连接，或 TIME_WAIT 残留。
Fix结合 -p 与 ss -tn state established 交叉确认；必要时重启相关服务清理。
Symptom不同系统上 netstat 输出格式不一致，脚本解析失败。
CauseBSD 与 Linux 的 netstat 列含义与选项支持存在差异。
Fix统一改用 ss（格式跨发行版更一致）；脚本里固定使用 -n 输出。
Troubleshooting
1查端口被哪个进程占用
netstat -lntp | grep :80需 root 才能看到 PID；这是端口类问题最快的一步。
2统计当前连接状态分布
netstat -an | awk '{print $6}' | sort | uniq -c各状态数量一目了然，ESTABLISHED 或 TIME_WAIT 异常增多时最直观。
3统计活跃连接数
netstat -an | grep ESTABLISHED | wc -l适合放进监控脚本作为连接数指标。
4确认默认网关路由
netstat -rn | grep UG排查「能 ping 通但连不上」时先看网关是否正确。
5新系统上的等价命令
ss -tlnpss 走 netlink 直接读内核，比 netstat 快一个数量级，输出也更易读。
Command Examples
Find what holds port 80
netstat -lntp | grep :80
# 或更快的现代写法
ss -tlnp | grep :80-l 只看监听、-n 不解析、-t 只看 TCP、-p 显示进程，最后一个参数需 root。新系统优先用 ss，直接读内核 netlink 快很多。
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 -rnTIME_WAIT 大量堆积通常说明连接未复用；CLOSE_WAIT 多则是对端已关闭而本地没及时释放，需要查应用侧的连接处理。
Output
2841 ESTABLISHED
312 TIME_WAIT
118 LISTEN
47 CLOSE_WAITFilter established connections with ss
ss -tn state established | headss 的状态过滤是一等公民，不需要 grep 管道，输出也更整齐。排查连接泄漏时先用它取基线。
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