keepalive_requests不能消灭HTTPS长连接过早失效，但能通过请求计数归零强制轮换连接，规避静默断连、TLS过期等问题；需配合keepalive_timeout、proxy_socket_keepalive及客户端配置协同优化。
调整 keepalive_requests 本身不能“消灭”HTTPS长连接过早失效，但它能有效切断老化连接、强制健康轮换，从而规避因连接长期复用引发的静默断连、TLS会话过期、中间设备回收等导致的“看似可用实则失效”问题。
先搞清“过早失效”的真实原因
HTTPS连接在Nginx侧明明配置了 keep-alive，客户端却频繁重连，常见根源不是Nginx主动关掉，而是：
- 后端服务（如Java网关、gRPC server）提前关闭空闲连接，但Nginx仍尝试复用 → 报
upstream prematurely closed connection - 企业防火墙/NAT网关强制回收空闲超过5分钟的TCP连接，而Nginx未探测或探测太晚
- TLS会话ticket过期或OCSP Stapling延迟，导致二次握手失败，客户端放弃复用
- 客户端（如浏览器、requests库）自身 idle timeout 比服务端短，先断连
keepalive_requests 的正确作用方式
它不延长连接寿命，而是用“请求计数归零”实现可控刷新：
- 每建立一个keepalive连接，Nginx内部计数器从0开始累加
- 达到设定值（如1000）后，该连接响应完当前请求即关闭，不进入keepalive池
- 下一次请求必然新建连接 → 天然绕过老化状态、证书续期失败、TIME_WAIT残留等问题
- 配合
keepalive_timeout（建议设为15–30秒），形成“双保险”：既防请求稀疏时连接空占，也防高频下连接过老
匹配场景的推荐值与配套动作
不要盲目拉高，要让数值覆盖典型业务周期内的请求数：
- React/Vue单页应用（含首屏+轮询）：设为2000，覆盖10–30分钟内全部资源和API调用
- 高频心跳类API（如每2秒一次）：设为1000–3000，支撑16–100分钟，远超实际空闲窗口
- 含SSE或长轮询的服务：保守设为10–50，防止单连接长期霸占又无法及时感知断连
- 务必同步检查：客户端是否发送
Connection: keep-alive；Nginx upstream是否启用proxy_http_version 1.1和proxy_set_header Connection ''
必须同步做的三件事
单改 keepalive_requests 效果有限，以下缺一不可：
-
缩短
keepalive_timeout至15–30秒：高频场景下连接本就不易空闲，设60秒以上反而堆积无效连接 -
开启
proxy_socket_keepalive并显式调小参数（如on 240s 10s 3）：主动探测防火墙前的连接存活，避免请求落到已断链路上 -
确认客户端连接池行为：Python requests需调大
pool_maxsize；浏览器需检查network.http.max-persistent-connections-per-server是否足够
