keepalive_requests 限制单条客户端长连接最多处理的请求数，达限即断连；需按业务类型设值（如 SPA 建议 2000，API 轮询 1000–3000，后台页 200–500），并联动调优 keepalive_timeout、upstream 长连接等配置。
设置 keepalive_requests 的核心，是让每条客户端到 Nginx 的长连接“干够活、不占位”——它不控制连接能活多久，而是明确限制最多处理多少次请求后就必须关闭。设小了，连接反复重建，握手开销暴涨；设大了，低频或异常连接会长期空转，挤占内存、文件描述符和 worker 槽位。
按业务类型定数值
关键看一个典型用户会话周期内实际发起多少次 HTTP 请求，目标是覆盖完整行为链，又不过度冗余：
- React/Vue 单页应用：首屏加载（JS/CSS/图片/字体等 20–50 个资源）+ 后续交互 + 轮询（如每 5 秒一次），建议设为 2000
- 高频轻量 API 或心跳服务（如 App 每 2–5 秒轮询一次）：设 1000–3000，配合较短超时加快周转
- 低频后台或管理页面：用户操作间隔长、请求稀疏，设 200–500 更稳妥，避免连接空挂十几分钟
- 含长轮询（SSE）或后端稳定性差的服务：主动设低（如 10–20 或 100–300），强制快速轮换，隔离异常影响
必须同步调优的配套项
单独改 keepalive_requests 效果有限，以下配置需联动调整：
-
缩短
keepalive_timeout至 15–30 秒：高频场景下，连接本就不该空闲太久；与 requests 构成“双退出机制”，任一先触发即释放 -
确认客户端支持复用：HTTP/1.1 默认开启 Keep-Alive，但需检查前端未显式发送
Connection: close -
反向代理必须配 upstream 长连接：upstream 块中启用
keepalive N，并确保proxy_http_version 1.1和proxy_set_header Connection ''已配置，否则前端调优全白费 -
禁用老旧兼容指令：如
keepalive_disable msie6，现代 SDK 或 App 客户端可能被误判为不支持 Keep-Alive
验证是否调得合理
不能只看配置写了没，要观察真实连接行为：
- 用
ss -tnp | grep :443 | grep ESTAB | wc -l查活跃连接数：调优后应更稳定，不再持续缓慢上升 - 查 Nginx 日志中
$connection_requests字段分布：多数连接应在设定值区间（如 500–2000）内关闭；若大量连接在 100 就断，说明值偏小 - 压测时对比
TIME_WAIT数量：合理调优后，相同 QPS 下应明显下降 - 用
curl -I连续请求，观察响应头：前几次返回Connection: keep-alive，接近设定值后变为Connection: close
不复杂但容易忽略：它只管客户端到 Nginx 这一段，对 upstream 完全无效；也不是并发限制，而是单连接的“工作量上限”。达到设定值后，Nginx 会在响应头写入 Connection: close，并在当前请求结束后断连——不管此时是否空闲、是否还没到超时时间。
