要让Nginx keepalive真正起效，必须协同配置客户端侧（keepalive_timeout与keepalive_requests）、后端代理侧（upstream keepalive、proxy_http_version 1.1、proxy_set_header Connection ''）及资源回收（reset_timedout_connection等），三者对齐才能实现高效复用与及时释放。
要让 Nginx 的 keepalive 真正起效，不能只调一个参数，得把客户端连接、代理到后端的连接、资源释放节奏三者对齐。核心是“该复用时不断开，该释放时不硬扛”。
客户端侧：设对 keepalive_timeout 和 keepalive_requests
这两个值共同决定单个 TCP 连接的生命周期，谁先触发谁生效：
-
keepalive_timeout 是空闲等待上限（不是总寿命），比如设为
25，表示响应发完后最多等 25 秒，期间有新请求就重置计时器；超时无动静就断开 -
keepalive_requests 是硬性请求数上限，比如设为
1000，表示这个连接处理满 1000 次请求后立刻关闭，哪怕才过了 2 秒 - 静态资源密集场景（如 SPA 首屏加载）：timeout 推荐 30–45 秒，requests 设 2000 左右
- 移动端 API：timeout 控制在 15–30 秒，requests 设 500–1000，避免弱网下连接空转太久
- 微服务间调用：timeout 可压到 5–15 秒，requests 设 200–500，配合高频轮询节奏快速周转
后端代理侧：必须配 upstream keepalive
客户端连 Nginx 的长连接，不等于 Nginx 连后端也是长连接——这是两个独立链路：
- 在
upstream块里加keepalive 32;（建议值为后端节点数 × 2～4，或按 worker 进程数估算） - 在
location中必须写明：proxy_http_version 1.1;和proxy_set_header Connection ''; - 否则 Nginx 默认用 HTTP/1.0 转发，每次请求都新建后端连接，前端再长也没用
- 实测显示，合理配置后端 keepalive 可降低后端 TCP 连接数 70%，QPS 提升 25%–35%
资源回收增强：防僵尸、跳 TIME_WAIT
光靠 timeout 和 requests 还不够，网络异常或客户端失联时，连接容易卡在半死状态：
- 开启
reset_timedout_connection on;：超时直接发 RST 包，内核立刻回收 socket，跳过 TIME_WAIT - 确保
client_header_timeout和client_body_timeout≤ keepalive_timeout，防止因读取卡住被误判为空闲 - 检查系统级限制：
ulimit -n（文件描述符）、net.core.somaxconn（连接队列），避免高并发下被系统掐断
验证是否真有效，而不是纸上谈兵
改完配置别急着上线，盯几个关键信号：
- 用
curl -I https://your.site/看响应头是否有Connection: keep-alive和Keep-Alive: timeout=25 - 运行
ss -tnpo | grep :443 | grep ESTAB | wc -l，对比不同 timeout 下的 ESTABLISHED 数变化趋势 - 查
nginx_stub_status中Waiting状态占比：持续高于 30% 说明空闲连接堆积，复用率低 - 看 error log 是否频繁出现
upstream prematurely closed connection，大概率是 Nginx 与后端超时不匹配
