keepalive_requests的核心作用是限制单个长连接处理请求数上限，防止单连接长期占用内存、文件描述符及worker槽位；典型设为2000（React场景），需协同keepalive_timeout（15–30s）及upstream长连接配置。
keepalive_requests 的核心作用，是给每条客户端到 Nginx 的长连接“划一条工作红线”：不是让它永远干活，而是明确告诉它“干满 N 次就休息”。这样既保留了复用价值，又防止单个连接长期霸占内存、文件描述符和 worker 连接槽位。
它到底在防什么
单条连接过度占用，常见于三类情况：
- 用户行为稀疏但连接未断：比如管理后台用户打开页面后离开半小时，连接空闲却仍驻留内存
- 异常客户端持续复用：如某 SDK 未正确关闭连接，反复发请求却不释放，连接对象越积越多
- SSL 上下文或 header 缓冲未及时清理：连接存活越久，关联的 TLS session、解析状态等资源越难回收
设多少才合适
关键看“一个典型连接实际会处理多少请求”，而不是盲目堆高数字：
- React/Vue 单页应用：首屏 + 交互 + 轮询，一般 20–50 次资源请求起步，设 2000 覆盖完整会话周期
- 高频 API（如每秒心跳）：设 1000–3000，支撑数分钟活跃期，避免每 10–20 秒就重建一次
- 低频后台接口或内网调用：设 200–500 更稳妥，防止连接空转太久
- 含长轮询或 SSE 的服务：建议 10–20，强制快速轮换，避免单连接长期挂起又无法感知断连
光设这个值远远不够
必须同步收紧时间维度和下游链路，形成双重约束：
- keepalive_timeout 缩短至 15–30 秒：高频场景下，连接本就不该空闲太久；超时设太长反而让“活而无用”的连接滞留
- 确认客户端启用复用且 idle timeout 不过长：比如 OkHttp 或 Python urllib3 中 max_idle_connections 和 keep_alive_timeout 应略大于 Nginx 设置，避免客户端先断
- 反向代理时，upstream 块必须配 proxy_http_version 1.1 和 proxy_set_header Connection ''：否则 Nginx 到后端仍是短连接，前端调优全白费
- 禁用 keepalive_disable msie6 等老旧兼容指令：现代 RPC 客户端或 App SDK 可能被误判为不支持 Keep-Alive
怎么知道调对了
别只看配置写了没，要观察真实连接行为：
- 用 ss -tnp | grep :80 | grep ESTAB | wc -l 查看活跃连接数是否稳定，而非持续缓慢上升
- 检查 Nginx 日志中 $connection_requests 字段分布：多数连接是否在 500–2000 区间关闭？若大量连接在 100 就断，说明值偏小
- 压测时对比 TIME_WAIT 数量变化：合理调优后，相同 QPS 下应明显下降
- 出现大量 "client closed connection while waiting for request"，往往提示 keepalive_timeout 过短，而非 keepalive_requests 不够
