按状态统计连接
连接数故障的第一步是分解：不要只看总数，而是按 TCP 状态统计数量。已建立状态高说明并发连接多（也可能是泄漏），回收态高说明主动关闭密集且回收慢，被动等待关闭状态高说明本端应用没有正常关闭连接，半连接高则提示对端建连后不回应。不同状态指向完全不同的根因，先看清分布再谈处置，能避免一上手就调内核参数、把应用侧问题掩盖过去。分布与总量要一起看：总量正常但某个状态异常增长，往往比总量超标更早暴露问题。
基本信息
| 适用平台 | Linux，连接查询工具由 iproute2 提供，几乎所有现代发行版自带 |
|---|---|
| 常见场景 | 连接数超限、端口回收慢、服务无响应、文件句柄耗尽 |
| 书写要点 | 状态名称用小写与连字符分隔，去掉表头便于计数 |
| 配套命令 | 汇总视图看总体统计，按状态逐项计数用于定位具体状态 |
| 采样建议 | 间隔数秒连续采样看趋势，比单次快照更有说服力 |
| 替代工具 | 老系统可用传统网络统计工具按状态列聚合，得到等价的分布视图 |
典型使用场景
- 服务报连接数超限：先确认是不是被动等待关闭状态堆积
- 客户端大量建连后本地端口紧张：看回收态分布与可用端口范围
- 压测或流量突增时延迟上升：看已建立数量与半连接堆积
- 怀疑连接池泄漏：观察被动等待关闭状态是否单向持续增长
- 容量评估与基线：定期采样各状态数量，异常时有对照
- 发布后回归：对比发布前后各状态分布，及时发现连接管理行为变化
一次性状态计数
一次性状态计数
ss -s # 汇总：各类连接与内存统计
ss -Htan state established | wc -l # 已建立连接数量，-H 去掉表头
ss -Htan state time-wait | wc -l # 回收态数量
ss -Htan state close-wait | wc -l # 被动等待关闭：应用未关闭连接的嫌疑
ss -Htan state syn-recv | wc -l # 半连接：建连未完成
ss -Htan state all | awk '{print $1}' | sort | uniq -c | sort -rn # 按状态聚合
ss -tanp | grep -c <端口> # 某端口上的连接数，进程信息需要权限
watch -n 5 'ss -Htan state close-wait | wc -l' # 持续观察是否单向增长状态含义与根因
| 状态 | 含义 | 常见根因 |
|---|---|---|
| ESTAB | 已建立、可传输数据的连接 | 正常并发；持续增长不回落要查连接池与业务并发 |
| TIME-WAIT | 主动关闭方的正常回收态 | 短连接密集时属正常；耗尽本地端口需优化连接复用 |
| CLOSE-WAIT | 对端已发关闭报文，本端应用未关闭 | 应用未调用关闭或连接池泄漏，调内核参数无效 |
| SYN-RECV | 收到建连请求并回应，等待对端确认 | 少量正常；大量堆积说明对端不回应或遭遇扫描 |
| FIN-WAIT-2 | 本端已关闭，等待对端关闭 | 少量正常；堆积说明对端迟迟不关闭 |
| LAST-ACK 与 CLOSING | 等待最后确认或双方同时关闭 | 少量属正常，长期堆积要查对端异常 |
被动等待关闭状态的堆积基本都是应用没有关闭连接（连接池泄漏、代码漏关），调内核参数无效，要从代码与连接池入手；把它当作内核问题处理，通常只是延后了故障复发时间。
计数细节：不加去表头参数时表头也会被行数统计数进去，结果比实际多一行，批量核对时容易错位。短时间多次采样看趋势，比单次快照更能说明问题；总量与分布结合起来看，才不会误判。