keepalive_timeout无统一最优值，需按业务类型设定：静态资源10–30秒、普通网站45–65秒、移动端API 5–15秒、长轮询60–300秒、高并发网关≤5秒；首值为服务端等待时长，次值为响应头提示值（建议小5–10秒）；须同步配置keepalive_requests、upstream keepalive及后端keep-alive支持。
keepalive_timeout 的数值没有统一“最合适”的值，关键看你的业务类型、客户端行为和后端服务能力。设太小会增加 TCP 重连开销；设太大则空闲连接堆积，占用文件描述符和内存。
按常见场景推荐取值
– 静态资源服务（CDN、图片/JS/CSS 站点）：10～30 秒
– 普通 Web 网站（含 HTML + 小资源）：45～65 秒（默认 75 秒偏长，可下调）
– 移动端 API 接口（App 请求间隔不规律、常休眠）：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_requests：建议设为 100～1000，防止单连接无限承载请求导致内存缓慢增长
– 如果是反向代理，upstream keepalive（如 keepalive 32;）和 proxy_http_version 1.1 必须启用，否则客户端长连接没意义
– 后端服务（Spring Boot / Node.js / Gunicorn）要真正支持 keep-alive，否则 Nginx 设再大也会被上游主动断连，引发 502 或 “upstream prematurely closed” 错误
怎么验证是否调对了
– 用 curl -I 查响应头是否有 Connection: keep-alive 和 Keep-Alive: timeout=XX
– 用 ss -s 或 netstat -an | grep ESTAB | wc -l 观察活跃连接数变化趋势
– 看 nginx_stub_status 中 Waiting 连接占比：过高说明大量空闲连接滞留，可能 timeout 设太长或后端未复用
– 检查 error log 是否频繁出现 Connection reset by peer 或 upstream sent too big header，这些往往是上下游超时不匹配的信号
