keepalive_requests控制单个长连接最多处理的请求数，达上限后nginx主动关闭连接；默认100，仅作用于客户端到nginx的http/1.1 keep-alive连接，与keepalive_timeout共同决定连接生命周期，二者任一触发即断连。
直接设一个数值不难，难的是让这个数既不让连接频繁重建，又不拖慢内存回收。关键不是“设多大”，而是让它和你的真实请求节奏、资源水位对得上。
先搞清它到底管什么
keepalive_requests 不是延时器，也不是并发控制器，它只干一件事：一条 TCP 连接从建立开始，最多处理多少个请求后必须关闭。每次响应发完，计数加 1；达到设定值，Nginx 就在响应头里加 Connection: close，然后断连——不管这连接刚忙完还是正空闲着。
- 它只作用于客户端到 Nginx 这一段（即浏览器 → Nginx），对 upstream（Nginx → 后端）完全无效
- 只对 HTTP/1.1 keep-alive 连接生效，HTTP/2 用 http_v2_max_requests 控制
- 和 keepalive_timeout 是并列条件，谁先触发谁说了算，真实生命周期取两者最小值
按业务类型选起点值
别从默认的 100 开始试，它在现代前端场景里基本偏小。起点应贴合典型用户会话的请求数量：
- React/Vue 单页应用：首屏加载 + 路由切换 + API 调用 + 轮询，一个完整会话常达 50–200 次请求，建议起步值设 2000
- 高频轻量 API（如心跳、状态轮询）：每 2–5 秒一次，单连接可能撑几天，但为防状态老化，推荐 1000–3000，同时把 keepalive_timeout 缩短到 15–30 秒
- 后台管理类接口或低频页面：用户操作间隔长，连接容易空转，设 200–500 更稳妥
- 后端偶发卡顿或不稳定：适当调低至 200–500，加快异常连接退出，避免拖累整个连接池
必须同步调的配套项
单改 keepalive_requests 效果有限，这几项不配好，内存释放周期就无法平滑：
- keepalive_timeout：建议设为请求平均间隔的 1.5–2 倍。比如 API 平均每秒 20 次请求，平均间隔 50ms，timeout 可设 15–25 秒，留出足够休眠窗口
- upstream 长连接支持：proxy_pass 场景下，必须在 upstream 块中显式配置 keepalive、proxy_http_version 1.1 和 proxy_set_header Connection ""，否则后端连接仍为短连
- reset_timedout_connection on：开启后可强制重置已超时但未关闭的僵死连接，防止它们长期占内存和 fd
- 压缩与缓存协同：前端启用 Gzip/Brotli，静态资源设置强缓存（Cache-Control: max-age=31536000），否则重复请求压不下来，再高的请求数上限也意义不大
怎么验证调得是否合适
不能只看配置文件写了没，要观察真实行为：
- 用 nginx_stub_status 查 Active connections 中 Waiting 状态是否长期 > 500，若再叠加平均复用请求数 > 1000，说明连接太“老”了
- 通过 ss -tni | grep :端口 | awk '{print $3}' | sort | uniq -c | sort -nr 看各连接实际处理请求数分布（需内核支持 tcp_info）
- 接入 Prometheus + nginx-vts-exporter，监控 per-connection request count 的 P95/P99 分位数，若大量连接集中在阈值附近断开，说明值设得合理；若多数远低于阈值就断，说明 timeout 或其他机制提前干预了
