keepalive_timeout优化核心在于让空闲连接“该走时走、该留时留”，需结合客户端行为与业务节奏设定30–60秒等差异化值，并同步配置upstream keepalive、proxy_http_version 1.1及keepalive_requests等参数，辅以ss和stub_status监控验证。
keepalive_timeout 优化系统稳定性，关键不是设大或设小，而是让空闲连接“该走时走，该留时留”，避免资源卡死或反复建连。
匹配客户端行为和业务节奏
浏览器加载一个页面通常在几秒内发出多个请求（HTML、JS、CSS、图片），之后可能空闲几十秒。设为 30–60 秒，能覆盖这个窗口，复用连接；但移动端 App 请求往往批量发出后就休眠，设太长反而堆积空闲连接。API 类服务建议 5–15 秒，静态资源服务可放宽到 10–30 秒。
- 用户连续操作密集（如后台管理系统）：45–60 秒较稳妥
- 高并发低延迟网关（如实时推送）：≤ 5 秒，并配合 reset_timedout_connection on
- 内网微服务调用：若确认客户端稳定复用，可设 60–120 秒，但必须同步检查上游超时
与 upstream keepalive 协同防断连
只调 client 端 keepalive_timeout 没用，后端连接池不启用，Nginx 仍会为每个请求新建连接。必须同步配置：
- upstream 块中加 keepalive 32;（值按后端并发能力的 1/4～1/2 设）
- location 中启用 HTTP/1.1：proxy_http_version 1.1;
- 清除干扰头：proxy_set_header Connection '';
- Nginx 的 keepalive_timeout 值要略小于后端 keep-alive timeout（例如后端设 60s，Nginx 设 55s）
搭配 keepalive_requests 防异常累积
单靠 timeout 控制不够——如果某个连接因异常请求卡住，一直不发新请求，timeout 不触发，它就一直挂着。加入请求数限制更可靠：
- keepalive_requests 100; 是常用起点，高稳定场景可设 1000
- 设为 0 表示不限制，易导致连接长期滞留
- 设过小（如 10）会频繁断连重连，抵消 keepalive 效果
监控连接状态而非只看配置
改完配置不验证，等于没调。重点看三类指标：
- 用 ss -s 观察 TIME_WAIT 是否突增，过多说明客户端未正常关闭或超时失衡
- 用 ss -tnpo | grep :80 | grep ESTAB | wc -l 查当前活跃连接数，是否远超预期（如 keepalive 设 32，却看到 200+ ESTABLISHED）
- 看 Nginx stub_status 中 Waiting 状态占比，持续高于 70% 说明大量连接空闲未被复用
不复杂但容易忽略：调优是闭环动作，不是改个数字就结束。从场景出发、协同上下游、配好配套参数、再用真实指标验证，系统稳定性才能真正落地。
