推荐用netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'按状态分类统计TCP连接，输出如ESTABLISHED 42、TIME_WAIT 1893；TIME_WAIT过多需检查本机是否主动关闭及tcp_tw_reuse是否启用为1；CLOSE_WAIT堆积表明应用未调用close()；ss命令更高效，但状态字段名和位置不同，迁移时需验证。
netstat 查看 TCP 连接状态的常用组合
直接用 netstat -an | grep : 只能看到连接快照，无法判断状态分布是否异常。真正要分析回收效率，必须按 ESTABLISHED、TIME_WAIT、CLOSE_WAIT、FIN_WAIT2 等状态分类统计。
推荐命令：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'。它把每行的最后一个字段（即状态）作为键计数，输出类似：ESTABLISHED 42、TIME_WAIT 1893、CLOSE_WAIT 7。
-
$NF是 awk 中“最后一列”的简写，netstat -n 输出中状态总在末尾，比硬写列号（如 $6）更可靠 - 不加
-p（进程名）是为了避免权限不足报错；如需关联进程，改用ss -tunp更稳妥 - 注意：CentOS 8+/RHEL 8+ 默认不预装 netstat，需先安装
net-tools包
TIME_WAIT 过多说明什么？怎么确认是不是回收慢
TIME_WAIT 本身不是错误，而是 TCP 正常挥手后的必经状态（持续 2×MSL，默认 60 秒）。但若数量长期 >5000 且持续增长，大概率是主动关闭方（通常是服务端）在短连接高频场景下未复用连接，或内核参数限制了快速回收能力。
关键检查点：
- 确认是否真由本机发起关闭：用
netstat -n | grep TIME_WAIT | head -5看本地端口是否为高位（如 32768–65535），若是，说明本机是主动关闭方 - 查内核是否启用快速回收：
cat /proc/sys/net/ipv4/tcp_tw_reuse应为1；/proc/sys/net/ipv4/tcp_tw_recycle在 4.12+ 内核已被移除，设了也无效 - TIME_WAIT 占用的是 socket 描述符，不是内存大头，但会挤占本地端口范围；可通过
cat /proc/sys/net/ipv4/ip_local_port_range查可用端口数
CLOSE_WAIT 大量堆积意味着服务端没调用 close()
CLOSE_WAIT 出现，代表对端已发 FIN，本机 TCP 栈已回 ACK，但应用层迟迟没调用 close() 或 shutdown()。这是典型的资源泄漏信号，和 netstat 本身无关，但 netstat 是第一个暴露它的工具。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
排查步骤：
- 用
netstat -tnp | grep CLOSE_WAIT拿到 PID，再用ps -p确认进程存活状态-o pid,ppid,cmd - 结合
lsof -p看该进程打开的 socket 是否真卡在 CLOSE_WAIT| grep TCP - 常见原因：代码里忘了在异常分支调 close()、阻塞在 read() 未超时、使用连接池但未正确归还连接
- 不要靠调大
/proc/sys/net/ipv4/tcp_fin_timeout来“缓解”——这只是延长僵尸时间，掩盖问题
netstat 的替代方案：ss 更快更准，但输出格式不同
netstat 依赖 /proc/net/tcp 解析，有开销且在高并发下可能卡顿；ss 直接读内核 socket 表，延迟低、结果实时性更好。但它的状态字段名略有差异：ESTAB 而非 ESTABLISHED，TIME-WAIT 带短横线。
等效统计命令：ss -tn | awk '{++s[$1]} END {for (i in s) print i, s[i]}'。注意 $1 是首列（状态），因为 ss -tn 输出第一列就是状态缩写。
- ss 不显示 PID，要查进程必须加
-tunp并以 root 运行；普通用户会看到 “Permission denied” 提示，而非静默跳过 - ss 默认不解析地址，
-tln比-tn多显示监听地址，适合查端口占用 - 如果脚本里原来用 netstat 统计状态，迁移到 ss 时务必验证状态字段位置和命名，否则统计全错
真正难的不是看懂 netstat 输出，而是把某个状态异常（比如突增的 FIN_WAIT2）和具体服务逻辑、超时配置、负载变化对应起来。这需要结合日志、监控指标、以及对应用网络模型的理解——netstat 只是给你一个准确的切片位置。
