keepalive_timeout优化需按业务类型设定合理区间并联动三项关键参数：静态资源30–45秒、移动端15–30秒、高并发网关5–15秒、内网后台45–60秒；须同步校准keepalive_requests、reset_timedout_connection和client_header_timeout/send_timeout，并验证连接数、waiting状态及上下游兼容性。
keepalive_timeout 优化的核心是让连接“该复用时复用，该退出时果断退出”，不是单纯调大或调小，而是根据实际流量特征和资源水位动态匹配。
按业务类型设定合理区间
不同请求模式对连接复用的需求差异很大：
- 静态资源服务（如 CDN、图片/JS/CSS）：用户常批量加载，复用率高 → 推荐 30–45 秒
- 移动端 API 或小程序后端：网络不稳定、App 可能休眠 → 推荐 15–30 秒，避免空闲连接长期滞留
- 高并发网关或微服务间调用：连接数压力大，需快速轮转 → 可设为 5–15 秒，并搭配 keepalive_requests 50–100
- 内网管理后台或低频系统：资源压力小、用户操作稀疏 → 可放宽至 45–60 秒，复用更稳
必须联动配置的三项关键参数
单改 keepalive_timeout 效果有限，以下三者要同步校准：
- keepalive_requests：限制单连接最大请求数，默认 100。设为 50–100 可防止单个异常连接长期霸占资源，与 timeout 形成“时间+次数”双退出机制
- reset_timedout_connection on：启用后，超时直接发 RST 而非 FIN，跳过 TIME_WAIT，内核立刻回收 socket，对慢速连接攻击特别有效
- client_header_timeout 和 send_timeout：这两个值必须 ≤ keepalive_timeout，否则可能因读写超时提前断连，导致“假空闲”误判
验证是否真正节省了资源
不能只看配置生效，要观察真实指标：
- 用 ss -tn | grep :443 | grep ESTAB | wc -l 查看 ESTABLISHED 连接数趋势，调优后应明显回落
- 监控 nginx_stub_status 中的 Waiting 状态数，过高说明空闲连接积压
- 检查 error log 是否频繁出现 upstream prematurely closed connection，提示上游未配合开启长连接
- 压测时对比进程 RSS 内存增长曲线，避免连接堆积触发 OOM
别忽略链路两端的兼容性
前端或中间设备不支持，Nginx 端再怎么调也白搭：
- 用 curl -v https://your.site/ 查响应头，确认含 Connection: keep-alive 和 Keep-Alive: timeout=XX
- 若上游有 LVS、云负载均衡器或 WAF，必须确保其 keepalive 超时 ≥ Nginx 设置，否则连接会在中间层被静默切断
- 后端服务（如 Spring Boot、Node.js）需显式启用 keep-alive，例如 Spring Boot 配置 server.tomcat.keep-alive-timeout=60，且 Nginx 的 keepalive_timeout 应略小于它（如设 55）
