least connections 算法本身不导致 time_wait 增多，但其常用于高并发反向代理场景，若未启用 upstream keepalive 和内核调优（如 tcp_tw_reuse=1、tcp_fin_timeout=30、ip_local_port_range 扩大），nginx 作为客户端频繁建连/断连将引发 time_wait 堆积；需优先配置长连接池并禁用已废弃的 tcp_tw_recycle。
Least Connections 算法本身不会直接导致 TIME_WAIT 增多，但它常用于高并发反向代理场景（如 API 网关、微服务入口），此时后端连接频繁建立/关闭，若未配合长连接与内核调优，TIME_WAIT 就容易堆积。关键不是算法问题，而是连接模式和系统资源管理没跟上。
确认 TIME_WAIT 主动方是谁
先用命令定位源头：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
如果输出中 TIME_WAIT 占比高且集中在 Nginx 进程对外发起的连接上（即 Nginx 作为客户端连后端服务），说明是 Nginx 主动关闭连接造成的——这是最常见的情况，尤其在未启用 upstream keepalive 时。
启用 upstream 长连接（治本）
避免每请求都新建 TCP 连接，从根本上减少 TIME_WAIT 产生：
- 在
upstream块中配置连接池：
upstream backend_api {
least_conn;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
<pre class="brush:php;toolbar:false;"># 关键：启用长连接池（至少 32 个空闲连接）
keepalive 32;}
server { location / { proxy_pass https://www.php.cn/link/2da3df196ff25fa5183cddba80a6df9b;
必须设置，否则 HTTP/1.1 keepalive 不生效
proxy_http_version 1.1;
proxy_set_header Connection '';
}}
这样 Nginx 与后端复用已有连接，不再频繁执行四次挥手，TIME_WAIT 数量可下降 90% 以上。
调整 Linux 内核参数（兜底优化）
即使启用了长连接，突发流量或后端异常断连仍可能产生 TIME_WAIT，需合理调优内核：
- 编辑
/etc/sysctl.conf，追加以下内容：
net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_syncookies = 1
说明：
-
tcp_tw_reuse = 1：允许 TIME_WAIT socket 被快速重用于新连接（安全，推荐开启） -
tcp_fin_timeout = 30：缩短 FIN-WAIT-2 状态超时，间接缓解 TIME_WAIT 积压 -
ip_local_port_range扩大可用端口范围，避免端口耗尽 -
tcp_max_tw_buckets提高系统容忍上限（默认通常仅 32768，高并发必须调大） -
禁用
tcp_tw_recycle：该参数在 NAT 环境下会导致连接失败，2020 年起主流发行版已弃用，切勿开启
检查并清理 CLOSE_WAIT（常被误认为 TIME_WAIT）
如果 netstat 显示大量 CLOSE_WAIT，说明后端服务（如 Tomcat、Node.js）未及时 close socket，这属于应用层问题，内核参数无效：
- 用
lsof -i -n -p [pid]查看具体进程的连接状态 - 确认后端是否设置了合理的连接超时、是否正确释放响应流
- Nginx 侧可加防护：
proxy_read_timeout 60;、proxy_next_upstream error timeout http_502;
