keepalive_timeout核心作用是控制Nginx与客户端空闲连接关闭时机，目标是在复用收益与资源占用间平衡；需按业务场景设合理值（如静态资源30–45秒、移动端15–25秒、常规Web站点60–75秒），并联动调整keepalive_requests、upstream keepalive及协议头部配置，结合运行指标验证效果。
keepalive_timeout 不是越大越好，也不是越小越省资源——它的核心作用是控制 Nginx 与客户端之间连接空闲多久后关闭，目标是在复用收益和资源占用间取得平衡。
按业务场景设合理值
不同流量特征决定不同超时策略：
- 静态资源服务（CDN、图床、前端静态站）：用户连续加载行为密集，但单次页面交互后空闲快，建议设为 30–45 秒
- 移动端 API 接口：网络不稳定、App 常切后台、中间 NAT 易静默断连，推荐 15–25 秒；混合站点（含 JS/CSS/图片）可压到 5–10 秒
- 常规 Web 站点（PC 浏览器访问）：适配浏览器默认行为，60–75 秒较稳妥
- 长连接场景（SSE、内网微服务调用）：需客户端持续保活，且无中间设备干扰，可设 60–300 秒，但必须同步确认后端 keep-alive 超时更长
必须配套调整的三项配置
单独改 keepalive_timeout 效果有限，以下三项需联动设置：
- keepalive_requests：默认 100，建议设为 50–100。防止单连接无限承载请求导致异常滞留或内存泄漏
- upstream keepalive：在 upstream 块中启用连接池，例如 keepalive 32;。值建议为后端单实例并发能力的 60%～80%，如 Tomcat maxConnections=200，则设 120–160
- 协议与头部控制：location 中必须有 proxy_http_version 1.1; 和 proxy_set_header Connection '';，否则上游无法复用连接
验证是否真正生效
不能只看配置文件，要通过运行指标判断优化效果：
- 用 ss -tn | grep :443 | wc -l 观察 ESTABLISHED 连接数趋势：调低后应明显回落，但不应引发大量重连
- 检查 nginx_stub_status 中的 Waiting 状态数：过高说明空闲连接积压，复用率低
- 抓包或 curl -v 查响应头，确认返回 Connection: keep-alive 且无 Connection: close
- 关注 error log 是否出现 upstream prematurely closed connection 或 502 Bad Gateway，这往往意味着上下游超时不匹配
特别注意边界情况
某些真实环境容易踩坑：
- 反向代理到慢速后端（如老旧 PHP-FPM）时，若单个请求处理时间接近 keepalive_timeout，Nginx 可能误判为空闲而提前关连，导致 502；此时应适当延长 timeout 或调高 proxy_read_timeout
- 若上游有 LVS、云负载均衡器或 CDN，它们的 keepalive 超时必须 ≥ Nginx 的 keepalive_timeout，否则连接会在中间层被强制断开
- HTTP/2 场景下，keepalive_timeout 可设为 0 或极短（如 5 秒），因多路复用已由协议层接管，Nginx 不必强留连接
