keepalive_requests 的核心作用是限制单个客户端连接最多处理的请求数，达限后强制关闭连接；它仅作用于客户端到 Nginx 的 inbound 连接，不控制时长、不适用于 upstream，也非并发限制。

keepalive_requests 的核心作用，是防止单个客户端连接在集群中“霸占太久”——它不控制连接能活多久，而是规定这条连接最多处理多少次请求后就必须关闭。设得太小，连接反复重建，加重 worker_connections 压力；设得太大，尤其在低频或异常用户场景下，容易让一条连接长期空转、挤占文件描述符和内存，影响其他正常用户接入。

明确它的作用边界

这个参数只管客户端到 Nginx 这一段（即 inbound 连接），对 Nginx 到后端服务（upstream）完全无效。它也不是并发限制，而是单连接的“工作量上限”。达到设定值后，Nginx 会在响应头中写入 Connection: close，并在当前请求结束后断开 TCP 连接，不管此时是否空闲、是否还没到 keepalive_timeout。

按业务节奏定合理数值

关键不是追求最大值，而是匹配典型用户会话内的请求数密度：

• React/Vue 单页应用：首屏加载 + 交互 + 轮询（如每 5 秒一次），一般覆盖 20–50 次请求，设为 2000 可支撑多轮行为，避免过早断连
• 高频 API 或心跳服务（如每 2 秒调用一次）：建议 1000–3000，配合较短的 keepalive_timeout（15–30 秒），让连接“快进快出”
• 低频管理后台或偶发操作页面：用户间隔长，设 200–500 更稳妥，防止连接空挂十几分钟
• 已知后端稳定性差或存在内存泄漏风险：主动设低（如 100–300），强制连接轮转，隔离异常影响

必须协同的关键配置

单独调大 keepalive_requests 无法解决占用问题，需三者联动：

• keepalive_timeout 要同步缩短：高频场景推荐 15–30 秒，与 requests 形成“双退出机制”，任一先触发即释放连接
• 确保客户端支持 Keep-Alive：HTTP/1.1 默认开启，但需确认前端未显式发送 Connection: close
• 系统级资源要兜底：检查 worker_rlimit_nofile 和系统 ulimit -n，确保文件描述符足够支撑目标连接数，否则再合理的 requests 值也会因 “too many open files” 失效

验证是否真正缓解了单连接驻留

不能只看配置生效，要观察真实连接行为：

• 用 ss -tnp | grep :443 | grep ESTAB | wc -l 对比调优前后稳定连接数变化趋势，若连接总数下降但活跃度未降，说明复用率提升、单连接更“紧凑”
• 连续请求同一接口，用 curl -I 查响应头是否持续返回 Connection: keep-alive，且第 N 次后变为 Connection: close（N ≈ 设定值）
• 压测时关注 TIME_WAIT 数量是否明显减少——这是建连频率下降的直接证据