keepalive_timeout的核心目标是平衡连接复用与资源释放，需按业务类型设不同值：静态资源10–30秒、常规Web站点45–60秒、移动端API 5–15秒、长连接场景60–300秒、高并发网关≤5秒；必须配对设置timeout与header_timeout，并同步配置keepalive_requests、upstream keepalive及HTTP/1.1头部支持。
keepalive_timeout 的核心目标不是“保持越久越好”，而是让连接在用户真正需要复用时还活着，又不在空闲时白白占着资源。设太短，浏览器加载多个资源要反复握手；设太长，成千上万空闲连接会吃光文件描述符，新请求直接被拒。
按业务类型选基础值
不同访问模式对连接复用的依赖程度差异很大，不能全局统一设 60 秒：
- 静态资源服务（CDN、图床、JS/CSS/图片）：用户连续请求密集，但页面加载完就基本空闲，建议 10–30 秒
- 常规 Web 站点（PC 浏览器访问 HTML + 小资源）：匹配 Chrome/Firefox 默认行为，推荐 45–60 秒
- 移动端 API（App 后端、网络不稳定、常切后台）：受 NAT 或运营商网关静默断连影响大，建议 5–15 秒
- 长连接场景（SSE、WebSocket 升级前代理、内网微服务调用）：需上下游保活协同，可设 60–300 秒，但必须确认后端超时更长
-
高并发低延迟网关（如消息中台、实时推送）：连接数敏感，建议 ≤5 秒，并启用
reset_timedout_connection on
两个数值都要配对理解
语法是 keepalive_timeout timeout [header_timeout];：
- 第一个值（必填）：Nginx 主动关闭空闲连接的等待时长（秒），决定实际资源释放时机
-
第二个值（可选）：写入响应头
Keep-Alive: timeout=N的提示值，仅作客户端参考，建议比第一个值小 5–10 秒
例如：keepalive_timeout 60 55; 表示服务端最多等 60 秒，同时告诉浏览器“你按 55 秒来复用”。
必须同步配齐的三项
只改 keepalive_timeout 效果有限，以下配置缺一不可：
- keepalive_requests：限制单连接最大请求数，防止单个慢请求卡死连接。API 场景建议 200–500，静态服务可设 1000–5000
-
upstream keepalive：若用
proxy_pass，必须在upstream块中显式启用，如keepalive 32;。该值应为后端单实例并发能力的 60%～80% -
协议与头部支持：location 中必须有
proxy_http_version 1.1;和proxy_set_header Connection '';，否则后端无法复用连接
上线后验证是否真生效
不能只看配置写了没，要观测真实指标：
- 用
curl -I https://your.site/查响应头，确认含Connection: keep-alive和Keep-Alive: timeout=XX - 用
ss -tnpo | grep :端口 | grep ESTAB | wc -l观察 ESTABLISHED 连接数趋势：稳定在合理区间（比如设 60 秒，连接数应在几百到一两千浮动，而非持续攀升） - 检查
nginx_stub_status中 Waiting 连接占比：过高说明空闲连接积压，复用率差 - 关注 error log 是否出现
upstream prematurely closed connection或 502 错误，这往往意味着上下游超时不匹配
