keepalive_requests控制客户端到nginx的单个长连接最多处理请求数，达限即关闭；需与keepalive_timeout协同生效，实际生命周期取二者最小值，默认100，高频场景建议1000–3000。
设置 keepalive_requests 是 Nginx 性能优化中控制长连接健康度的关键一环——它不靠时间“等超时”，而是按实际请求数主动断连，防止连接老化、内存滞留和响应延迟上升。
明确作用对象：只管「客户端到 Nginx」的连接
这个指令限制的是浏览器或 App 等客户端与 Nginx 之间的 TCP 连接最多处理多少个请求。它对 Nginx 到后端（upstream）的连接完全无效——后者需在 upstream 块里配 keepalive_requests 和 keepalive。
- 配置位置只能是
http、server或location块 - 不能写在
upstream、if或map中，否则报错或静默忽略 - 数值为整数，默认 100；设为 0 表示不限制（不推荐）
协同 keepalive_timeout 才算真正生效
这两个参数共同决定一条长连接的实际寿命，谁先触发，连接就先关闭：
-
keepalive_timeout 30s：空闲 30 秒无新请求，就关连接 -
keepalive_requests 500：哪怕只用了 2 秒就处理完第 500 个请求，也立刻关 - 真实生命周期 = min(空闲时长, 达限耗时)，不是简单相加
例如高频轮询接口（每 2 秒一次），若只设 keepalive_timeout 60s 却没调高 requests，连接大概率在处理完 30 次请求后就因空闲超时被关——复用收益大打折扣。
按业务类型选值，避免拍脑袋
默认 100 适合普通页面，但现代应用往往需要更高复用率：
- React/Vue 单页应用（首屏+路由+API+图片共 40–100 请求）→ 推荐 1000–2000
- 移动端心跳/状态上报（QPS 高、单连接每秒复用多次）→ 1000–3000，搭配
timeout 15–30s - 老旧后端或存在内存泄漏风险的服务 → 降为 50–200，加快连接轮转，暴露问题
- 纯静态资源（JS/CSS/图片）且并发高 → 可设 2000–5000，显著减少建连开销
验证是否按预期工作
光改配置不够，得看效果：
- 启用
stub_status，观察Active connections中Reading/Writing/Waiting分布是否平稳，避免Waiting长期 > 500 - 日志中加入
$connection_requests变量，统计单连接处理请求数分布，确认是否集中在设定阈值附近截断 - 压测前后对比 Worker 进程 RSS 内存曲线：从“缓慢爬升”变为“小幅锯齿波动”，说明内存释放更及时
不复杂但容易忽略
