keepalive_timeout合理性取决于匹配真实请求节奏、客户端行为和后端能力：设太短增握手开销，设太长致空闲连接堆积耗尽资源；需按业务类型分层设值（静态资源10–30秒、移动端API 5–15秒、常规Web 60–65秒、内网/长轮询60–300秒），并严格对齐上下游超时、启用keepalive_requests限制单连接请求数，结合ss、stub_status及error log等指标验证效果。
keepalive_timeout 的合理性不取决于“设多大”，而在于是否匹配真实请求节奏、客户端行为和后端能力。设太短，连接反复重建，增加握手开销；设太长，空闲连接堆积，耗尽文件描述符和内存。关键是要让连接“刚好够用，不多留”。
看业务类型定基础值
不同服务对连接复用的依赖程度差异很大：
- 静态资源站（如 CDN、图片/JS/CSS 服务）：用户通常一次加载多个资源，浏览器会快速复用连接，10～30 秒足够，过长反而占用连接池
- 移动端 API：App 请求常呈“爆发-休眠”模式，后台可能几秒内无新请求，5～15 秒更稳妥，避免大量僵尸连接滞留
- 常规 Web 站点（HTML + 资源混合）：兼顾浏览器默认策略（多数支持 60s），60～65 秒是较通用选择
- 内网服务或长轮询（SSE）、实时网关：客户端持续复用，且网络稳定，可设 60～300 秒，但必须确认后端 keep-alive timeout 更长
必须对齐上下游超时
单方面调大 Nginx 的 keepalive_timeout 没有意义，甚至引发 502 错误：
- 后端服务（如 Spring Boot、Node.js、Gunicorn）需显式启用并延长 keep-alive timeout，例如 Spring Boot 设
server.tomcat.keep-alive-timeout=75，Nginx 才能设为 60 - 响应头中应有
Connection: keep-alive，不能出现Connection: close；可用curl -v验证 - upstream 块中要配
keepalive 32;，并配合proxy_http_version 1.1;和proxy_set_header Connection '';
搭配 keepalive_requests 才算完整
只调 timeout 不够，还需限制单连接承载上限，防止单个连接长期霸占资源：
-
keepalive_requests 100;是较稳妥起点，适合多数 Web 场景 - 高吞吐 API 或内网服务可设为 1000～10000，前提是后端稳定支持 pipelining 或频繁复用
- 设为 0 表示不限制，易导致连接老化、被后端主动断开，引发 upstream prematurely closed connection
靠指标验证，不是靠猜测
改完配置后，要观察实际效果：
- 用
ss -tnpo | grep :80 | grep ESTAB | wc -l查当前活跃连接数，对比是否接近预期并发量 - 访问
/nginx_status（需启用 stub_status）看 Waiting 状态是否持续偏高——高说明大量连接空闲未释放 - 检查 error log 是否出现 Connection reset by peer 或 recv() failed，大概率是上下游超时未对齐
- 压测时监控 RSS 内存增长曲线，避免因连接堆积触发 OOM
