keepalive_requests用于主动切断upstream后端长连接，防止请求上下文、buffer和变量引用持续堆积导致Worker内存缓慢爬升；它仅作用于proxy_pass后端连接，需配合keepalive指令，按成功处理请求数计数，达限即关连，不等超时，建议20–50起步压测，并须协同keepalive_timeout等配置。
核心是用 keepalive_requests 主动切断老连接，避免请求上下文、buffer 和变量引用持续堆积，从而抑制 Worker 进程内存缓慢爬升。
明确作用对象和生效条件
这个指令只对 upstream 中的后端长连接有效，必须配合 keepalive 指令使用。它不控制客户端直连，也不影响空闲时长——只按“成功处理的请求数”计数。每完成一个请求，计数器加 1；达到设定值后，连接在响应发完立刻关闭，不等超时。
- 默认值 100 对多数场景偏保守，高吞吐小包接口（如 API 网关）建议从 20–50 起步压测
- 设为 0 或极大值会放大内存滑坡风险，设为 1 则失去复用意义，退化成短连接
- 计数器独立维护，新建连接自动归零，不会跨连接累积
合理设置数值并观察效果
数值不能拍脑袋定，要结合实际负载特征和内存水位来调。重点看单连接平均处理请求数是否接近你设的阈值，以及 Worker RSS 内存曲线是否由缓升变锯齿波动。
- 用
$connection_requests变量记录日志，统计分布：若大量连接集中在设定值附近断开，说明生效 - 通过
nginx_stub_status观察 Active connections 中 keepalive 连接数是否周期性回落 - 配合 Prometheus + nginx-vts-exporter 监控 per-connection request count 的 90% 分位值
必须协同的关键配置
单独调 keepalive_requests 效果有限，需和几个机制联动才能真正防住内存滑坡：
-
keepalive_timeout必须设为合理值（比如 60s），作为兜底机制，防止异常连接永久驻留 -
reset_timedout_connection on强制重置已超时但未关闭的僵死连接 - 在 OpenResty 场景下，可在
log_by_lua*中主动检测高复用连接，用ngx.exit(444)提前终止 - 后端也要匹配：Tomcat 的
connectionTimeout应略大于 Nginx 的proxy_read_timeout
验证是否真正起效
生效不是看配置写了没，而是看行为是否符合预期：
- 抓包或查 access log，确认响应头含
Connection: close出现在设定请求数之后 - 用
ss -tni | grep :port查各连接的已传输请求数（需内核支持 tcp_info） - 对比开启前后，
ps aux --sort=-%mem | grep nginx中 Worker 进程 RSS 是否明显更稳定
