keepalive_requests控制单个tcp连接最多处理的http请求数，达限即关闭连接；需与keepalive_timeout协同，实际生命周期取二者触发先者，默认值100，react等密集请求场景建议1000–3000。
调优 keepalive_requests 不是为了盲目增大数值，而是让每个长连接在资源占用与复用收益之间取得合理平衡。它和 keepalive_timeout 是一对协同工作的参数，单独调整效果有限。
它到底控制什么
keepalive_requests 表示单个 TCP 连接上最多能处理多少个 HTTP 请求。达到这个数量后，Nginx 会在响应头中加入 Connection: close，并在当前请求结束后关闭该连接——哪怕连接还处于空闲状态、远未到超时时间。
默认值是 100，适用于普通网站；但在高并发 API 或 React 类前端密集加载场景下，这个值常成为连接复用的瓶颈。
怎么设才合适
关键看你的业务请求模式：
- 静态资源多、单次页面加载请求数高（如 React 应用含 JS/CSS/图片/字体共 30+ 个请求）→ 建议设为 1000–3000
- 纯 JSON API 接口轻量、响应快、客户端复用频繁（如 App 轮询）→ 可设为 2000–5000，降低建连开销
- 后端服务老旧、存在内存泄漏风险或连接稳定性差 → 建议调低至 50–200，强制连接轮转，避免“老化连接”拖累整体
- 代理后端不支持 HTTP/1.1 长连接（如某些旧版 PHP-FPM 或 CGI 模式）→ 设为 10–50 更稳妥
必须配合 keepalive_timeout 使用
这两个参数共同决定连接的实际生命周期：
-
keepalive_timeout 30s;：空闲 30 秒无新请求就关连接 -
keepalive_requests 2000;：即使没空闲满 30 秒，处理完第 2000 个请求也关连接
真实连接寿命 = 二者中先触发的那个。所以如果只把 keepalive_requests 调到 5000，但 keepalive_timeout 还是默认 65 秒，那大多数连接根本达不到 5000 次就因空闲超时被关了。
高频短周期请求场景（如每 2 秒一次心跳），建议 缩短 timeout（15–30 秒）+ 调高 requests（1000+）；低频长耗时接口，则可保持 timeout 稍长（60–120 秒），requests 维持默认或略增即可。
注意作用范围和常见误区
keepalive_requests 只影响客户端到 Nginx 的这一段连接，对 Nginx 到 upstream 的连接池完全无效——后者需单独配置 upstream keepalive N 和 proxy_http_version 1.1 等参数。
不要设为 0（不限制），长期复用可能引发连接状态异常、内存缓慢增长或掩盖真实问题；也不要脱离系统资源谈调优——过高的值会增加 worker 进程的连接管理负担，尤其在文件描述符受限时容易触发 too many open files 错误。
验证是否生效，不能只看配置是否加载成功，而要观察实际连接行为：用 ss -tnp | grep :80 | grep ESTABLISHED | wc -l 查看活跃连接数变化趋势，结合压测工具（如 wrk -c 200 -t 4 -d 30s）对比 QPS 与连接复用率提升情况。
