keepalive_timeout优化核心是让连接“够用但不积压”，即控制Nginx与客户端间空闲连接等待时长，需按场景分层设置：静态资源10–30秒、常规Web站点45–60秒、移动端API 15–30秒、长连接服务60–300秒，并协同keepalive_requests、proxy_http_version 1.1、upstream keepalive等参数联动调优。
keepalive_timeout 优化不是调大就快，而是让连接“够用但不积压”——它控制 Nginx 与客户端之间空闲连接的等待时长，直接影响并发承载力和资源利用率。设太短，频繁握手拖慢响应；设太长，空闲连接占满文件描述符，反致拒绝新请求。
按业务场景分层设置 timeout 值
不同访问模式对连接复用需求差异明显，不能一刀切：
- 静态资源服务（CDN/图片/JS/CSS）：用户连续加载密集，建议 10–30 秒。复用率高，但回收要快，避免大量空闲连接堆积
- 常规 Web 站点（浏览器访问）：页面内资源加载周期通常在 20–60 秒内，设为 45–60 秒较稳妥，匹配主流浏览器默认行为
- 移动端 API 或内网微服务调用：网络不稳定、客户端保活策略各异，推荐 15–30 秒；若对接 App 后端且存在休眠唤醒场景，可进一步下探至 5–15 秒
- 长连接服务（SSE、WebSocket 代理、实时推送）：需配合 proxy_read_timeout 使用，keepalive_timeout 可设为 60–300 秒，重点靠 keepalive_requests 和后端心跳维持
必须协同调整的配套参数
单独改 keepalive_timeout 效果有限，需与以下三项联动生效：
- keepalive_requests：设为 100–10000（推荐 1000 起步），限制单连接处理请求数。避免异常请求卡死连接，也防止连接因长期空闲被后端主动断开后仍被 Nginx 缓存
- proxy_http_version 1.1 + proxy_set_header Connection ''：仅面向客户端的 keepalive 不影响后端，若 Nginx 作反向代理，这两项才能让 upstream 连接真正复用
- upstream keepalive N：例如 keepalive 32，表示每个 worker 进程最多缓存 32 个空闲到同一后端的连接。该值应略小于后端单实例最大并发连接数（如 Tomcat maxConnections=200，则 upstream keepalive 设 120–160）
验证是否真正提升处理能力
别只看配置写了没，关键看指标变化：
- 用 ss -tnpo | grep :端口 | grep ESTAB | wc -l 观察活跃连接数趋势：稳定在 keepalive 设置值附近，说明复用已生效；若持续攀升或剧烈波动，说明复用未建立或超时失配
- 检查 nginx_stub_status 中 Waiting 连接占比：若 Waiting 高但 Writing 低，说明连接空闲多、复用率差，需缩短 timeout 或加大 keepalive_requests
- 关注 error log 是否出现 upstream prematurely closed connection 或 502 Bad Gateway：大概率是 Nginx keepalive_timeout > 后端 keep-alive timeout，导致连接被后端先关闭
注意中间链路与系统级限制
生产环境常被忽略的隐性瓶颈：
- 若上游有 LVS、云负载均衡（如 ALB/NLB）、K8s Ingress，其自身 keepalive 超时必须 ≥ Nginx 的 keepalive_timeout，否则连接会在中间层被静默断开
- Linux 内核 net.ipv4.tcp_fin_timeout 建议设为 30–60 秒（不能低于 RFC 规定的 60 秒），加快 TIME_WAIT 回收，配合 keepalive 减少端口耗尽风险
- worker_connections × worker_processes 总和必须大于 peak concurrent connections，否则即使 keepalive 优化到位，也会因连接数上限被拒
