调低 keepalive_timeout 是减少空闲连接最直接有效的方式，但需结合业务类型设合理值（如移动端15–30秒、静态资源30–45秒、后台管理10–20秒、sse/websocket 60–120秒），并同步优化 keepalive_requests、reset_timedout_connection 及上游超时一致性，同时通过 ss 命令、stub_status 和日志验证效果，https 场景建议采用 15–25 秒以降低内存开销。
调低 keepalive_timeout 是减少空闲连接最直接有效的方式，但它不是孤立生效的参数——必须结合业务节奏、客户端行为和配套机制一起调整，否则容易引发重连风暴或资源滞留。
按业务类型设合理值
默认 65 秒对多数现代服务偏长，应根据实际请求间隔压缩：
- 移动端 API 或微服务间调用：设为 15–30 秒。App 请求常呈“爆发-休眠”模式，超时设太长会堆积大量无复用价值的空闲连接
- 静态资源（JS/CSS/图片）服务：可设 30–45 秒，覆盖页面内资源加载周期，兼顾复用与及时释放
- 后台管理类低频页面：压至 10–20 秒 即可，用户操作间隔长，长连接基本不被复用
- 含 SSE 或 WebSocket 升级前握手的场景：需设 60–120 秒，但要确认客户端确实持续发送心跳，否则仍是无效驻留
必须同步调优的配套配置
只改 keepalive_timeout 效果有限，以下三项需一并检查：
-
启用
keepalive_requests：设为 50–100，限制单连接最大请求数。防止异常请求卡住连接，掩盖 timeout 设置效果 -
开启
reset_timedout_connection on：对已超时但未正常关闭的连接（如客户端崩溃），立即发 RST 而非等待 FIN，加快资源回收 - 检查上游链路超时一致性：若前面有 LVS、云负载均衡或 CDN，其 keepalive 超时必须 ≥ Nginx 值，否则连接会在中间层被提前切断，Nginx 设置失效
验证是否真在释放空闲连接
不能只看配置写了没，要用运行态指标判断：
- 用
ss -tn state established | grep :443 | wc -l观察 ESTABLISHED 连接数趋势，调低后应明显回落 - 监控 Nginx stub_status 中的 Waiting 状态数——它代表空闲 keepalive 连接。持续高于 Active connections 的 50%，说明连接在“空转”而非复用
- 查日志变量
$connection_requests和$request_time，分析单连接平均承载请求数与请求间隔分布。若平均间隔远大于 timeout 值，说明设得仍偏长
注意 HTTPS 场景的额外开销
HTTPS 下每个空闲连接内存占用是 HTTP 的 3–5 倍（含 SSL 上下文、密钥材料等）。实测显示：keepalive_timeout 从 15 秒升至 300 秒，在 5000 并发连接下，worker 进程 RSS 内存平均多占 120–180MB。因此对 HTTPS 服务，更建议采用 15–25 秒 的保守值，并优先保障 keepalive_requests 和 upstream keepalive 配合到位。
