如何通过 keepalive_requests 调优在高频 API 场景下降低 TCP 握手频繁损耗-Nginx-PHP中文网

keepalive_requests 是高频 api 场景下控制单连接最大请求数的关键参数，需设为1000–5000并配合缩短 keepalive_timeout 至15–30秒、确保客户端支持及上下游长连接配置，以平衡复用效率与资源稳定性。

如何通过 keepalive_requests 调优在高频 api 场景下降低 tcp 握手频繁损耗

在高频 API 场景（如每秒多次调用、客户端定时心跳、微服务间密集通信）下，keepalive_requests 是直接影响 TCP 握手开销的关键参数。它不控制连接存活时长，而是限制单个长连接最多处理多少次请求——超过即主动断开，哪怕连接仍在空闲期内。合理调高该值，能显著减少重复建连次数，把“握手成本”摊薄到更多请求上。

为什么高频场景下默认值（100）容易成为瓶颈

默认 100 次请求就关闭连接，在低频接口中足够；但在每秒发起 5–10 次请求的客户端场景中，一个连接平均仅能维持 10–20 秒。频繁新建连接会触发大量三次握手 + TLS 握手（若启用 HTTPS），实测单次完整建连耗时常达 100–300ms。10 次请求若全走新连接，光握手就可能吃掉 1–3 秒。

高频短周期请求的推荐配置策略

针对心跳类、轮询类、gRPC/HTTP/2 网关后端等典型高频场景：

将 keepalive_requests 提升至 1000–5000：覆盖数分钟内的请求量，让连接真正“复用起来”。例如每 2 秒一次心跳，1000 次 = 支撑约 33 分钟，远超实际空闲窗口。
同步缩短 keepalive_timeout 至 15–30 秒：避免连接长期空占资源；高频请求本就不会空闲太久，超时设太长反而延迟释放无效连接。
确保客户端也支持并启用 Keep-Alive：HTTP/1.1 客户端默认开启，但需确认未显式发送 Connection: close；Python requests、curl、OkHttp 等主流库默认行为均符合要求。

配合 Nginx 其他相关指令协同生效

单独调大 keepalive_requests 不足以发挥全部效果，还需检查配套设置：

禁用对老旧客户端的兼容性降级：确认未启用 keepalive_disable msie6 等指令，避免误判现代客户端为不支持 Keep-Alive 的旧浏览器。
下游服务也要开启长连接：若 Nginx 作为反向代理，需同时配置 proxy_http_version 1.1 和 proxy_set_header Connection ''，确保上游服务也能复用连接。
监控连接复用率验证效果：通过 nginx_stub_status 查看 Active connections 与 Reading/Writing/Waiting 分布，或统计日志中 $connection_requests 字段，确认多数连接确实在 500+ 请求后才关闭。