Linux连接数过多本质是TCP状态异常堆积，需针对性优化：TIME_WAIT过多应复用连接而非盲目调参；CLOSE_WAIT高须检查应用是否未正确关闭socket；ESTABLISHED异常需排查攻击或服务端accept延迟；先确认真实瓶颈（ulimit、somaxconn、内存）再干预。
Linux 系统中连接数过多，本质不是数量本身超标，而是大量连接卡在特定 TCP 状态（尤其是 TIME_WAIT、CLOSE_WAIT、异常增长的 ESTABLISHED）导致端口耗尽、响应变慢或新建连接失败。排查要从状态分布入手，再定位进程和业务逻辑。
先看连接状态分布，别只数总数
用 ss -s 快速获取全局统计，重点关注三类：
- estab：真实活跃连接，持续暴涨且无业务匹配 → 查是否泄漏、攻击或 accept 延迟
-
time-wait：主动断连后的临时状态（默认约 60 秒），数量大不等于有问题，要看是否引发
Cannot assign requested address -
close-wait：对方已关闭，本机没调
close()→ 几乎 100% 是应用代码缺陷
进一步按状态筛选：ss -tn state time-wait | wc -lss -tn state close-wait | wc -l
加 -p（需 root）可直接看到对应进程名和 PID，例如：ss -tnp state close-wait | head -10
TIME_WAIT 多了，先判断是不是真影响服务
单纯数值高不用慌，重点看三点：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 本地端口范围是否快用完：
cat /proc/sys/net/ipv4/ip_local_port_range（如 32768–60999，共约 28K）；若time-wait长期 >25K，且出现连接失败报错，才算真问题 - 新建连接是否延迟升高或失败：用
curl -w "@format.txt" -s http://api/测time_connect，或查 Nginx 日志是否有connect() failed (99: Cannot assign requested address) - 是否集中在某类服务：比如所有 TIME_WAIT 都来自 :80 或 :3306，说明是 Web 反向代理或数据库短连接行为导致
CLOSE_WAIT 高？立刻查应用代码
这个状态完全由本机应用控制，内核无法干预。典型路径：
- 用
lsof -iTCP -sTCP:CLOSE_WAIT -n -P或ss -tnp state close-wait定位 PID 和端口 - 查该进程日志：找 read/write timeout、SocketTimeoutException、未捕获的 IO 异常或崩溃堆栈
- 检查代码：Java 是否在所有分支（包括 catch、return、finally）都 close 了 Socket/InputStream；Python requests 是否用了 session 或显式
response.close()；Go 的 http.Client 是否设了合理的Timeout和KeepAlive
能优化的参数，只动这几个关键项
优先改应用，再考虑内核参数。安全有效的调整只有：
-
net.ipv4.tcp_tw_reuse = 1：允许 TIME_WAIT socket 在时间戳递增前提下复用于新 outbound 连接（客户端场景有效，服务端效果有限） -
net.ipv4.ip_local_port_range = 1024 65535：扩大可用端口范围，缓解高频短连接压力 -
net.core.somaxconn = 65535：增大 listen 队列，避免 SYN 请求被丢弃（配合应用层 accept 能力）
切勿启用 tcp_tw_recycle —— Linux 4.12+ 已移除，NAT 环境下会导致连接失败。
