核心是让连接复用、少断连：需同时优化客户端到Nginx（keepalive_timeout/keepalive_requests）和Nginx到upstream（upstream keepalive/keepalive_timeout/keepalive_requests）的长连接配置，并协同调优后端超时与内核参数。
要降低负载均衡集群中因频繁建连导致的 TIME_WAIT 耗尽问题，核心不是“减少单次断连后的等待时间”，而是**让连接复用起来、少断连**。Nginx 作为反向代理层，必须同时优化客户端侧和上游侧的 keepalive 行为，否则任一侧短连接都会在中间节点（比如 Nginx 本机）堆积 TIME_WAIT。
客户端到 Nginx 的长连接控制
确保前端（浏览器、App、SDK）与 Nginx 之间能稳定复用连接：
-
设合理的
keepalive_timeout：API 网关建议 15–30 秒，高并发微服务间调用可压到 5–15 秒；静态资源可放宽至 60–120 秒。该值需略小于客户端自身的 keep-alive timeout（如 OkHttp 默认 300 秒、Chrome 约 5–6 分钟），避免 Nginx 先断引发重连 -
调高
keepalive_requests：默认 100 容易触发“刚用几次就断”，API 场景建议设为 1000–3000；若后端稳定且请求轻量，可到 5000。它不延长空闲时间，但能显著减少单位时间内建连次数 -
检查 client 头部干扰：确认没启用
keepalive_disable msie6等过时指令；禁用可能透传Connection: close的逻辑
Nginx 到 upstream 的连接池必须显式开启
这是最关键的一步——Nginx 默认对每个请求都新建后端连接，TIME_WAIT 主要就堆在这里：
-
upstream 块中加
keepalive N：例如keepalive 128;表示每个 worker 进程最多缓存 128 个空闲到后端的连接。推荐值 = 后端单实例稳定并发连接数 × 0.6～0.8（如 TomcatmaxConnections=200，则设 120～160） -
配套启用 HTTP/1.1 和清空 Connection 头：
proxy_http_version 1.1;<br> proxy_set_header Connection '';
否则即使配置了 keepalive，也可能因协议降级或头部冲突导致复用失败 -
设置上游 keepalive 超时：在 upstream 块内加
keepalive_timeout 30s;，且必须严格小于后端服务的空闲超时（如 Spring Boot 默认 60s，则 Nginx 最多设 55s），防止单方面断连引发 reset
协同调优 keepalive_requests 防止连接老化
仅开连接池不够，单连接若长期复用，可能因后端连接老化、内存泄漏或流控机制被主动关闭，反而触发 upstream prematurely closed connection 错误：
-
该参数作用于 upstream 连接，非客户端连接：它限制“一个 Nginx 到后端的长连接最多处理多少次请求”，到数即标记为可关闭（实际仍受
keepalive_timeout约束） -
HTTP/1.1 后端建议 1000–3000，gRPC 可设 5000–10000（依赖 HTTP/2 多路复用）；老旧 Java 应用保守设 500–1000，并确认 Tomcat 的
maxKeepAliveRequests≥ 此值 - 避免盲目设过大：若后端每分钟只来几个请求，设 5000 意味着连接空闲几十秒仍占槽位，挤压真正活跃连接空间
验证与兜底措施
调优后必须验证是否真正在复用：
- 用
ss -ant | grep :80 | awk '{print $NF}' | sort | uniq -c观察 ESTABLISHED 数量是否稳定、TIME_WAIT是否明显下降 - 开启
stub_status，关注Active connections与Reading/Writing/Waiting分布，Waiting 高而 Reading/Writing 低，说明空闲连接积压 - Linux 内核层面可辅助调整：
net.ipv4.tcp_tw_reuse = 1（仅对客户端角色有效）、net.ipv4.tcp_fin_timeout = 30，但不能替代连接池优化
