keepalive_timeout优化需平衡连接复用与资源释放，设太短增握手开销，设太长致空闲连接堆积；须协同upstream keepalive、proxy_http_version 1.1及后端配置，按业务场景设5–300秒并监控复用效果。
keepalive_timeout 优化不是调一个数字的事，而是直接影响连接复用效率、资源占用和稳定性。设得太短，握手开销压垮延迟和 CPU；设得太长，空闲连接吃光文件描述符和内存，导致新请求被拒。
影响连接复用率与网络开销
这个参数决定空闲连接能“等多久才关”。客户端发完一个请求后若在 timeout 内发第二个，就能复用同一 TCP 连接：
- TCP 三次握手 + 四次挥手频率大幅下降，尤其在弱网（如移动、跨地域）中延迟明显降低
- HTTPS 场景下，TLS 握手（尤其是非会话复用时）不再每次重来，CPU 和首字节时间（TTFB）显著改善
- 浏览器、App 或小程序批量加载资源（HTML → JS/CSS/图片）时，复用率高则整体页面加载更快
直接关系到系统资源水位
每个 keep-alive 连接都占一个文件描述符（fd）和内存（socket 结构、缓冲区、SSL 上下文等）：
- timeout 设为 300 秒，而实际请求间隔平均 2 秒，大量连接长期空闲挂起，fd 很快触达 worker_connections 或 ulimit -n 上限
- nginx 状态页中 Waiting 状态连接数持续高位，说明连接“挂着但没人用”，属无效驻留
- 内存 RSS 持续爬升，极端时触发 OOM，尤其在容器或低配云主机上更敏感
必须协同 upstream 才有效
Nginx 和后端之间是独立的连接池，client 端的 keepalive_timeout 对 upstream 无影响：
- 只调大 client 端 timeout，但 upstream 没开 keepalive 或设了 10 秒超时，Nginx 复用连接发请求时仍可能遭遇 502 或 “upstream prematurely closed connection”
- 正确做法：upstream 块配 keepalive 32;，location 中启用 proxy_http_version 1.1; 和 proxy_set_header Connection '';，且 Nginx 的 keepalive_timeout 要略小于 upstream 的 keep-alive timeout（如上游设 60s，Nginx 设 55s）
- 用 ss -tnpo | grep :80 | grep ESTAB | wc -l 查当前 ESTABLISHED 连接数，对比 upstream keepalive 设置是否被真正复用
不同业务场景推荐值差异明显
没有通用最优值，关键看请求节奏和客户端行为：
- 静态资源服务（CDN、图床）：用户密集并发加载，空闲期短 → 推荐 10–30 秒
- 移动端 API：App 请求后常休眠几秒，中间设备（NAT、WAF）回收更激进 → 推荐 5–15 秒
- 内网后台或 SSE 长连接：客户端有心跳且链路透传 → 可设 60–300 秒，但需实测验证
- 高并发网关或实时推送：连接周转快，fd 极其宝贵 → 建议 ≤ 5 秒，并开启 reset_timedout_connection on;
