Linux连接数问题本质是TCP状态异常堆积，需针对性优化：TIME_WAIT过多应复用连接而非盲目调参；CLOSE_WAIT高须检查应用是否未正确关闭socket；ESTABLISHED异常需排查攻击或服务端accept延迟；先确认真实瓶颈（ulimit、somaxconn、内存）再干预。
Linux系统中连接数过多，通常不是单纯的数量问题，而是大量连接堆积在特定TCP状态（尤其是TIME_WAIT、CLOSE_WAIT、ESTABLISHED异常持续）导致资源耗尽或响应变慢。关键不在“杀连接”，而在识别状态成因并针对性优化。
TCP连接状态怎么看？重点关注这三个
用netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn或ss -s快速统计各状态连接数。真正需警惕的是：
- TIME_WAIT 过多（尤其短时间激增）：正常是主动断连方的短暂状态（默认2MSL≈60秒），但若每秒新建连接远超1000，又频繁短连接，会导致端口耗尽、内存占用升高；
-
CLOSE_WAIT 长期不降：说明本机应用没调用
close()，常见于程序未正确释放socket、阻塞在读写、或崩溃后残留； -
ESTABLISHED 持续暴涨且无业务匹配：可能是爬虫、扫描、DDoS，也可能是服务端未及时
accept()或子进程卡死，连接堆积在listen队列。
TIME_WAIT 高？别急着改内核参数
盲目设置net.ipv4.tcp_tw_reuse = 1或tcp_tw_recycle = 0（后者已废弃）可能引发NAT环境下的连接异常。更稳妥的做法：
- 客户端尽量复用连接（HTTP加
Connection: keep-alive，数据库用连接池）； - 服务端避免作为主动关闭方（让客户端关连接），例如Nginx反向代理时设
proxy_http_version 1.1和proxy_set_header Connection ''； - 确认业务是否真需要高频短连接——能合并请求、改长连接就别硬扛TIME_WAIT。
CLOSE_WAIT 居高不下？查应用代码和日志
这个状态完全由本机应用控制，内核无法干预。典型排查路径：
- 用
lsof -i -n -P | grep CLOSE_WAIT定位对应PID和端口； - 查该进程日志，看是否有read/write timeout、异常退出、未捕获的IO异常；
- 检查代码中socket是否在所有分支（包括try-catch、return、error path）都执行了
close()或使用try-with-resources（Java）、with socket...（Python）等自动释放机制。
连接数真的“超限”了吗？先看实际瓶颈
Linux默认单机支持65535个端口，但连接数上限还取决于：
-
ulimit -n：进程级文件描述符限制（含socket），可临时调高：ulimit -n 65535，持久化需改/etc/security/limits.conf； -
net.core.somaxconn：listen队列长度，高并发服务建议设为65535； - 内存：每个TCP连接约3.3KB内核内存（不含应用缓冲区），万级连接需百MB以上；
- 实际业务是否真需要这么多并发？用
ss -i看rtt、retrans、retransmits，比单纯数连接更有诊断价值。
不复杂但容易忽略：多数连接数问题本质是应用设计或配置偏差，而非系统瓶颈。先明确谁在建连、为何不关、是否真要那么多，再动手调参或扩容。
