keepalive_requests 通过主动关闭高复用连接预防响应延迟：避免缓冲区膨胀、连接槽位挤占、后端过早断连重试及状态重初始化开销；需与 keepalive_timeout 等协同调优。
keepalive_requests 本身不直接控制响应时间，但它通过主动终结长连接，间接防止因连接老化、状态累积或资源僵化导致的响应延迟升高。
为什么长连接会拉长响应时间
单个 TCP 连接复用次数过多后，可能出现以下问题：
- Nginx worker 中该连接关联的缓冲区、解析上下文、SSL session 缓存等持续驻留，内存占用缓慢增长，GC 或内存分配压力间接拖慢处理速度
- 前端轮询异常（如 JS 错误导致每秒发请求但间隔抖动），连接长期活跃却未真正释放，挤占有效连接槽位
- 后端服务（如 Node.js、Tomcat）对连接有自身超时策略（如 keepAliveTimeout=25s），而 Nginx 的 keepalive_requests 过大，导致连接在后端已关闭后仍被复用，触发 upstream prematurely closed connection 等重试或错误路径，增加延迟
- 连接空闲期过长但未及时回收，等待新请求时需重新初始化部分状态（如 header parser 重置、流控检查），带来微小但可累积的开销
keepalive_requests 如何起作用
它给每个长连接设一道“请求数红线”：达到设定值后，Nginx 主动发送 Connection: close 并关闭连接，强制客户端新建连接。这相当于把一个可能变“钝”的连接，在它开始影响性能前就换掉。
- 不是等连接出错才断，而是预防性退出
- 与 keepalive_timeout 形成双重约束：谁先满足，连接就先结束
- 避免连接在低频、高抖动、或异常行为下“苟延残喘”，从而维持整体连接池的健康度和响应一致性
按业务节奏设置合理阈值
目标是让连接生命周期匹配典型用户会话，既不过早断连增加建连开销，也不过晚释放积累隐患。
- React/Vue 单页应用：首屏 + 路由切换 + API 轮询（如每 5–10 秒一次）+ 图片懒加载，单次会话常达 50–80 请求 → 建议 keepalive_requests 1000–2000
- 高频心跳类接口（如实时状态上报）：QPS 高、单连接每秒复用多次 → 设为 500–1500，配合 keepalive_timeout 15–30s，确保连接不过期也不滞留
- Node.js 后端：若 server.keepAliveTimeout = 25s，且平均请求处理耗时 60ms，则单连接每秒约复用 16 次；设 keepalive_requests 500，预期寿命约 31 秒 —— 略低于后端超时，可减少 stale connection
- 后端为 Java（Tomcat）：确认其 maxKeepAliveRequests ≥ Nginx 设置值，否则 Nginx 复用时后端已断连，引发重试延迟
必须配套的关键配置
单独调大或调小 keepalive_requests 效果有限，需协同优化：
- keepalive_timeout 必须同步设置：推荐 15–30s（非默认 65s），尤其对响应敏感场景，防“活连接零请求”堆积
- 启用 reset_timedout_connection on：对超时未完成的连接直接 RST，加速资源释放，减少 TIME_WAIT 对响应链路的干扰
- 静态资源加强缓存（Cache-Control: max-age=31536000）+ 启用 Brotli/Gzip：从源头减少重复请求数，比单纯调大 keepalive_requests 更有效压降连接压力
- 监控 waiting 连接数：用 stub_status 查看 waiting 值是否长期高位，若持续 > 总 active 的 30%，说明空闲连接未及时清理，需调低 keepalive_requests 或 timeout
