keepalive_requests控制nginx到upstream单连接最大请求数，需与keepalive、keepalive_timeout联动调优；http/1.1网关建议1000–3000，grpc可设5000–10000，并确保小于后端超时值。
要避免后端 RPC 服务因连接缓存溢出导致的资源耗尽、TIME_WAIT 堆积或延迟升高，keepalive_requests 必须与 upstream 连接池机制协同调优，而非孤立设置。它本质是“单连接生命周期的请求数上限”，设得过小会频繁断连重连，设得过大则可能让连接在空闲期被后端主动关闭，反而触发异常重置或缓存失效。
明确 keepalive_requests 的作用边界
该参数仅控制 Nginx worker 到 upstream（如 gRPC 后端、Dubbo 网关、Java 微服务）的单个长连接最多处理多少次请求——不是超时控制，也不影响客户端到 Nginx 的连接。若后端是 HTTP/1.1 接口，它直接决定复用效率；若后端是 gRPC（HTTP/2），其效果受流限制和连接保活策略双重约束。
- 默认值 100 在 RPC 场景下极易成为瓶颈：例如每秒 5 次调用，连接平均仅存活 20 秒，远低于典型后端 keepalive timeout（常为 60–120s）
- 超过 keepalive_requests 后，Nginx 主动发起 FIN，但不会等待 ACK，属于“优雅但非强制”的断开
- 若后端已提前关闭连接（如 Tomcat maxKeepAliveRequests=100 或 gRPC server 设置了 idle_timeout），而 Nginx 仍尝试复用，就会报
upstream prematurely closed connection
匹配后端能力设定合理范围
值不是越高越好，需参考后端服务的实际连接管理策略：
- 对 HTTP/1.1 RPC 网关（如 Spring Cloud Gateway）：设为 1000–3000，前提是后端
maxKeepAliveRequests≥ 3000 且keepAliveTimeout≥ 60s - 对 gRPC 服务（HTTP/2）：可设为 5000–10000，因多路复用更充分；但需同步检查服务端
max_concurrent_streams和客户端是否启用EnableMultipleHttp2Connections - 对 Dubbo HTTP 回滚层或老旧 Java 应用：建议保守设为 500–1000，并确认 Tomcat Connector 中
keepAliveTimeout> Nginx 的keepalive_timeout
必须配套调整 upstream keepalive 参数
单独调大 keepalive_requests 无效，需三者联动：
-
keepalive N：设为后端单实例稳定并发连接数的 60%–80%，例如后端能扛 300 并发，这里设 180–240，防止连接池挤占后端资源 -
keepalive_timeout：必须严格小于后端的空闲超时，例如后端设 75s，Nginx 最多设 60s；高频 RPC 场景推荐 30–45s，兼顾复用与及时释放 - 禁用不必要兼容：移除
keepalive_disable msie6类指令，避免误判现代 RPC 客户端
验证是否真正生效
不能只看配置，要通过运行时指标判断连接是否被有效复用：
- 开启
nginx_stub_status，观察Active connections与Writing数量比，若 Writing 长期接近 Active，说明连接未被复用 - 在 access log 中添加
$connection_requests字段，统计分布：若多数连接在 100–200 次请求就关闭，说明keepalive_requests仍偏低 - 抓包检查 upstream 流量：同一源端口连续发出多个请求，且无重复 SYN 包，即复用成功
