设为1000是兼顾复用与稳定的经验值，因在典型高并发接口中可支撑2–6分钟请求流，降低握手开销约90%，实测qps提升15%–30%，但需同步调整keepalive_timeout至15–30秒并确保客户端启用keep-alive。

将 keepalive_requests 设为 1000 是高频 API 场景下提升吞吐量的有效手段，但关键在于它必须和请求节奏、空闲行为、上下游配置协同生效——不是单纯调大就提速。

为什么 1000 是一个兼顾复用与稳定的经验值

在典型高并发接口中（如每秒 3–8 次调用的微服务间通信或客户端轮询），设为 1000 意味着单连接可支撑约 2–6 分钟的持续请求流。例如：

• 每 2 秒一次心跳 → 1000 次 = 约 33 分钟，远超实际空闲窗口
• 单次页面加载触发 40+ 请求 → 1000 次 ≈ 支撑 20+ 次交互，大幅减少建连频次
• 相比默认 100，握手开销降低约 90%，实测 QPS 提升 15%–30%

必须同步调整的两个配套参数

keepalive_requests 单独调高无效，需与以下两项联动：

• keepalive_timeout 缩短至 15–30 秒：高频请求本就不易空闲太久，设太长反而让“热连接”卡在 worker_connections 中占位；15 秒既能覆盖大多数请求间隙，又可及时释放异常挂起的连接
• 确保客户端启用 Keep-Alive：HTTP/1.1 默认开启，但需检查是否被显式关闭（如代码里写了 Connection: close）；Python requests、OkHttp、curl 等主流库默认合规，无需额外设置

避免常见误配导致的反效果

设成 1000 后若仍无改善，可能踩了这些坑：

• 后端服务（如上游 Tomcat、Spring Boot）未开启长连接，Nginx 的 keepalive 实际无法复用到底层
• 负载均衡器或云厂商 SLB 层存在更短的空闲超时（如 60 秒），提前切断连接，使 Nginx 配置失效
• 客户端使用短连接模式发起请求（如某些旧版 SDK 或测试脚本），每次请求都新建 TCP 连接
• 未限制单个 client_max_body_size 或超时参数，导致大请求阻塞连接，变相缩短可用请求数

验证是否真正生效的方法

不要只看配置，要观测真实连接行为：

• 用 ss -tan | grep :443 | wc -l 查看 ESTABLISHED 连接数变化趋势，正常应比调小前更平稳、峰值更低
• Nginx 日志中添加 $connection_requests 变量，统计每个连接处理的请求数分布，确认多数落在 800–1000 区间
• 对比调优前后 netstat -s | grep -i "segments retransmited"，重传率下降说明握手更稳定

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！