keepalive_requests指令用于限制客户端到Nginx长连接的最大请求数，需配合keepalive_timeout使用，二者任一触发即断连；推荐根据业务场景设为200–5000不等。
在 server 块中限制「客户端到 Nginx」的长连接最大请求数，直接使用 keepalive_requests 指令即可，它作用于 Nginx 与客户端之间的连接，无需 upstream 或 proxy 相关配置。
配置位置和基本写法
该指令必须放在 http、server 或 location 块中。最常用且推荐的做法是写在 server 块顶层：
-
keepalive_requests 1000;表示每个客户端长连接最多处理 1000 个请求后，Nginx 主动关闭该连接 - 它默认生效，只要客户端发起的是 HTTP/1.1 并带
Connection: keep-alive头（现代浏览器默认如此） - 不需要额外开启开关，也不依赖
proxy_pass或upstream
必须配合 keepalive_timeout 使用
keepalive_requests 和 keepalive_timeout 是“或”关系：任一条件满足即断连。因此两者需协同设置：
-
keepalive_timeout 60s;控制空闲超时（无新请求时最多等 60 秒） -
keepalive_requests 2000;控制活跃上限（不管是否空闲，处理完 2000 个请求就关） - 真实连接寿命 = 二者中先触发的那个。例如高 QPS 场景下，连接可能远未空闲就已达请求数上限
典型适用场景与取值建议
不同业务模式对连接复用强度要求差异大，数值不能照搬：
- React/Vue 单页应用（首屏加载 JS/CSS/图片/接口共 30–50+ 请求）→ 推荐 1000–3000
- 移动端 App 轮询 API（轻量 JSON，QPS 高）→ 可设 2000–5000，减少建连开销
- 后台管理类页面（请求稀疏、单次操作间隔长）→ 200–500 更稳妥，避免连接长期滞留
- 内网服务间调用（低延迟、高稳定性）→ 可适当提高，但需监控 worker 内存 RSS 是否呈锯齿波动
验证是否生效
可通过以下方式确认配置已起作用：
- 用
curl -H "Connection: keep-alive" -v http://your-domain/连续发起请求，观察第 N+1 次响应头是否含Connection: close - 启用
nginx_stub_status模块，关注Active connections中Waiting状态数是否稳定，而非持续攀升 - 日志中添加
$connection_requests变量，统计单连接请求数分布，看是否集中在设定值附近截断
