keepalive_requests通过计数方式主动终止长连接，与keepalive_timeout共同构成双退出机制，实际生命周期取二者先触发者；React应用推荐设2000，需配合timeout缩至15–30秒及强缓存优化。
核心思路是用 keepalive_requests 主动“掐断”连接的生命周期，不让它无限期空闲挂起。它不看时间，只数请求次数——达到设定值就关掉连接，从而避免客户端维持大量低频、长时、无实际负载的连接。
keepalive_requests 怎么起作用
这个参数和 keepalive_timeout 是并行生效的两个退出条件：任一触发，连接即关闭。实际连接寿命 = “处理完 N 个请求” 和 “空闲满 T 秒” 中先发生的那个。
- 设为 1000：一个连接最多服务 1000 次请求，哪怕只用了 2 秒就干完了，也会立刻断开
- 设为 0：不限请求数，连接会一直等下去，直到超时或客户端主动断开，极易堆积
- 典型场景中，用户一次完整交互（首屏+API轮询+资源加载）往往在几百到两千次请求内完成，远低于默认 100 或盲目设为 5000 的值
针对堆积问题的推荐取值
不是越大越好，关键是匹配真实业务节奏：
- 前后端分离的 React/Vue 应用：设为 2000，覆盖页面加载、状态同步、微前端资源拉取全过程
- 高频 JSON API（如移动端心跳、实时状态上报）：设为 1000–3000，确保撑过 1–3 分钟活跃周期后自动轮转
- 含大量静态资源的官网类站点：可设为 3000–5000，但必须同步开启强缓存（Cache-Control: max-age=31536000），否则无效请求数会虚高
必须配套调整的关键参数
单改 keepalive_requests 效果有限，需形成“请求数 + 空闲时长”双重约束：
- keepalive_timeout 缩短至 15–30 秒：高频服务下，空闲超过 20 秒基本意味着连接已闲置，没必要再等
- reset_timedout_connection on：对超时未完成的请求直接 RST 复位，不走优雅关闭，加速 worker 连接槽位释放
- 确认 upstream 也启用长连接：反向代理场景下，若后端（如 Flask/FastAPI）没配 keepalive，Nginx 单边复用反而导致连接卡死
怎么验证是否真起效
别只看配置写了没，要观察运行态表现：
- 打开 stub_status，关注
waiting连接数：长期稳定在高位（比如持续 >500 且波动小），说明空闲连接堆积，参数可能设得太松 - 检查 error log 中是否频繁出现
client closed connection while waiting for request：这是客户端已断开但 Nginx 还在等请求，反映 keepalive_timeout 或 keepalive_requests 失衡 - 用
ss -tan | grep :443 | wc -l对比高峰与低谷的 ESTABLISHED 连接数变化幅度——调优后，连接数应随流量峰谷明显起伏，而非长期高位黏着
