keepalive_timeout是nginx中控制响应后空闲等待时长的关键参数，影响连接复用效率与资源水位；设太长易耗尽文件描述符，太短则增加tcp/ssl重连开销；需按业务类型设定合理值，并联动调整keepalive_requests、upstream keepalive及客户端兼容性配置。
keepalive_timeout 是 Nginx 中直接影响连接复用效率与资源水位的关键参数。它不控制连接总寿命，只决定响应发完后、等待下一个请求的空闲等待时长（单位：秒）。设太长，大量空闲连接堆积，耗尽 worker 进程的文件描述符和内存；设太短，客户端频繁重连，加重 TCP 握手、SSL 重建开销，尤其对 HTTPS 和移动端影响明显。
按业务类型设定合理超时值
静态资源服务（如 CDN、图床、前端静态站）：用户通常并行加载 HTML 后的 JS/CSS/图片，后续空闲时间短，推荐 30–45 秒；
API 接口服务（尤其是 App 或小程序后端）：移动网络易中断，长连接常被中间设备（NAT、防火墙）静默回收，推荐 15–30 秒；
后台管理系统或低活跃度内网页：用户操作间隔长、连接复用率低，可压至 10–20 秒；
长轮询、SSE 或 WebSocket 升级前场景：需确认客户端持续复用，且无中间代理截断，可设 60–300 秒，但务必同步检查客户端行为。
必须联动调整的配套配置
仅调 keepalive_timeout 效果有限，以下三项需同步审视：
- keepalive_requests：限制单个连接最多处理请求数，默认 100。建议设为 50–100，防止单连接无限累积请求导致异常长连接滞留；
-
upstream keepalive（在 upstream 块中）：控制与后端（如 PHP-FPM、Java 应用）的长连接池大小，例如
keepalive 32;，需搭配proxy_http_version 1.1;和proxy_set_header Connection '';才生效； - 客户端与中间链路兼容性：现代浏览器默认启用 Keep-Alive，但企业网关、LVS 或某些 CDN 可能强制关闭长连接，此时 Nginx 端设再长也无效，需协同排查。
验证是否真正优化到位
不能只看配置生效，要结合运行指标判断：
- 用
ss -tn | grep :443 | grep ESTAB | wc -l观察 ESTABLISHED 连接数趋势，调低后应明显回落； - 监控 Nginx stub_status 中的 Waiting 状态数，过高说明空闲 keepalive 连接积压；
- 开启日志变量
$connection_requests和$request_time，分析单连接平均承载请求数与请求间隔分布； - 压测时对比不同 timeout 下的进程 RSS 内存增长曲线，避免因连接堆积触发 OOM。
特别注意的边界情况
反向代理到慢速上游（如老旧 PHP-FPM）时，若 upstream 处理一个请求耗时接近或超过 keepalive_timeout，Nginx 可能误判为空闲而提前关闭连接，导致 502；此时应适当延长 timeout，或优先优化后端响应速度。
另外，keepalive_timeout 0 表示彻底禁用 HTTP/1.1 keep-alive，所有连接响应后立即关闭，仅适用于极特殊调试或强制短连接场景。
