keepalive_timeout 通过优化连接复用率间接提升QPS：设太短导致频繁重建连接，设太长则耗尽连接资源；需结合keepalive_requests、超时参数及系统限制协同调优。
keepalive_timeout 本身不直接“提升请求量”，但它能显著减少连接重建开销，让单位时间内可处理的有效请求数变多——也就是间接提升系统吞吐量。关键不是设得越大越好，而是让空闲连接既足够复用，又及时释放。
keepalive_timeout 怎么影响请求处理效率
它控制 Nginx 与客户端之间空闲 HTTP 连接的等待时长。设得太短（如 2 秒），浏览器加载一个页面要发 20 个请求（JS/CSS/图片），可能每个都得重新建连，三次握手 + TLS 协商反复发生，CPU 和延迟双双上升；设得太长（如 300 秒），几千个空闲连接卡在 ESTABLISHED 状态，耗尽 worker_connections 和文件描述符，新请求直接被拒绝。
真正起作用的是：连接复用率升高 → 单位时间完成更多请求 → 实际 QPS 上升。
按场景选对值，复用才稳定
-
静态资源服务（CDN、图片站）：用户常批量请求，复用价值高 → 设
keepalive_timeout 30;或60; -
移动端 API 后端：App 请求集中爆发后进入休眠，长连接易成僵尸 → 推荐
15–30; -
高频微服务调用（如健康检查+业务混合）：需快速轮转连接 →
5–15;，并必须配keepalive_requests 100; -
内网长轮询或 SSE 场景：客户端持续保活 → 可设
120;，但要确认客户端真会复用
示例：某 App 接口原设
75s，高峰期大量空闲连接堆积，ss -s | grep "tcp.*established"显示 ESTAB 超 8000；调至20s后，活跃连接回落到 2500 左右，P95 延迟下降 18%，相同机器承载 QPS 提升约 22%。
必须同步打开的配套配置
单改 keepalive_timeout 效果有限，以下几项缺一不可：
keepalive_requests 100;
防止单连接被异常请求长期占用，达到次数就断连，比超时更可控client_header_timeout 12;和client_body_timeout 12;
这两个值必须 ≤keepalive_timeout，否则连接可能因读取超时提前关闭，造成“假空闲”worker_connections 10240;且系统ulimit -n ≥ worker_processes × worker_connections
否则连接数撑到上限后，新请求会在 accept 阶段被丢弃若用反向代理，
upstream块中还要加keepalive 32;并配proxy_http_version 1.1;
否则前端复用再好，到后端仍是短连，握手开销没省下来
验证是否真的提升了请求承载能力
别只看配置，要看真实指标：
-
curl -I https://your.site/查响应头：必须有Connection: keep-alive和Keep-Alive: timeout=XX -
nginx_stub_status中观察Waiting状态数：过高说明空闲连接积压，复用未生效 -
ss -tnpo | grep :443 | grep ESTAB | wc -l对比调整前后连接数趋势 - 压测时对比相同并发下的成功率、平均延迟和 5xx 错误率（尤其 502/503）
不复杂但容易忽略
