keepalive_requests用于限制单个客户端长连接最多处理N个请求后强制关闭，防止单个连接长期驻留、资源僵死或内存缓慢增长；它与keepalive_timeout协同工作，任一条件满足即断连，需根据典型会话请求数合理设置（如React应用建议2000），且仅作用于客户端到Nginx段。
keepalive_requests 放在 http 块中，是用来限制每个客户端长连接最多处理多少个请求后就必须关闭的。它不直接控制“时间”，但能有效防止单个连接长期驻留、资源僵死或内存缓慢增长——尤其当用户行为异常（如页面打开后闲置、爬虫持续复用连接、前端未正确断连）时。
它怎么防“占用过久”
这个参数强制连接在处理完 N 个请求后主动断开，不管此时是否还在 keepalive_timeout 的空闲窗口内。相当于给连接加了一道“请求数上限保险”，避免以下情况：
- 用户打开页面后挂机 10 分钟，连接一直空闲却没被回收（
keepalive_timeout还没到），worker 进程里堆着大量低效连接； - 某个恶意客户端循环发请求但间隔极长，连接始终不超时，悄悄吃掉连接槽位；
- 前端 JS 错误导致轮询逻辑失控，单连接不断发新请求，却始终不释放。
合理设置建议
关键不是“设多大”，而是让 N ≈ 一个典型会话周期内的总请求数：
- React/Vue 单页应用：首屏 + 路由切换 + API 轮询 + 微前端资源加载，通常 30–60 个请求/会话 → 建议
keepalive_requests 2000（留足余量，覆盖多次交互）； - 纯 JSON API 接口（如移动端后端）：单次操作 1–3 个请求，QPS 高且请求密集 → 可设
1000–3000； - 内部管理后台或低频工具类页面：用户操作稀疏，连接易闲置 → 可降到
500，加快轮转； - 若后端偶发卡顿或连接不稳定（如数据库抖动），可进一步压到
200–500，让连接更快释放重试。
配合其他配置才真正生效
- 必须搭配
keepalive_timeout（比如65s），否则只有限制请求数，空闲连接仍可能堆积； - 前端需支持 HTTP/1.1 并默认发送
Connection: keep-alive（现代浏览器都满足）； - 不要设为
0（不限制）：这等于放弃该层保护，连接可能无限复用，掩盖真实问题； - 如果用了 CDN 或负载均衡器，确认它们没主动改写或清除
Connection头，否则 Nginx 的设置无效。
不复杂但容易忽略的是，它只管“客户端到 Nginx”这一段。若你同时做反向代理，还得单独配 upstream keepalive 和 proxy_http_version 1.1，否则后端照样收不到复用连接。
