keepalive_timeout仅控制客户端到nginx的空闲超时，需与upstream连接池、业务模式协同优化；应按场景设为10–30秒并配keepalive_requests双机制，同时确保后端及中间设备超时更长，并启用reset_timedout_connection加速释放。
keepalive_timeout 在反向代理场景中，不直接控制 upstream 连接复用，只管理客户端到 Nginx 这一段的空闲等待时间。但它却是整个连接复用链路的起点——若这一端过早断开，后端再怎么配也白搭。优化关键在于：让 client→Nginx 的超时节奏，与 Nginx→upstream 的连接池行为、业务请求模式、中间链路特性形成协同。
客户端到 Nginx 的 keepalive_timeout 要匹配真实请求间隔
它不是越长越好，而是要覆盖“用户连续操作或资源批量加载”的自然空闲窗口：
- 静态资源密集页（HTML + JS/CSS/图片）：设为
30 25—— 30 秒服务端等待，25 秒写入响应头提示浏览器，足够撑过首屏资源加载间隙 - 移动端 API 或小程序后端：设为
15–30—— 避免被运营商 NAT 或企业防火墙提前回收（常见超时为 2–5 分钟，但客户端心跳不稳定） - 后台管理系统或低频操作界面：设为
10–20—— 操作间隔长，留太久只是占着 fd，反而挤占高并发连接槽位
注意第二个值（如
30 25中的 25）会生成Keep-Alive: timeout=25响应头，影响浏览器行为；Chrome 尊重该值，IE 则常硬性截断在 60 秒。
必须和 keepalive_requests 组成双退出机制
单靠 timeout 防不住“低频活跃”连接（比如每 28 秒发一次请求，永远卡在超时前）。加请求数限制才能堵住空转：
- 公网入口（登录、注册）：
keepalive_requests 100—— 防慢速攻击，避免单连接长期占用 - SPA 页面或常规 Web 应用：
keepalive_requests 1000–2000—— 匹配页面内多资源加载+后续 AJAX 行为 - 两者任一触发即断连：要么空闲超时，要么请求数用完
确保 upstream 连接池不被“上游先断”拖垮
Nginx 的 keepalive_timeout 再合理，如果后端（如 Tomcat、Node.js）或中间设备（WAF、云 LB）更早关闭连接，复用就中断：
- 检查后端
connectionTimeout（Tomcat）或keepAliveTimeout（Express）是否 ≥ Nginx 的proxy_read_timeout，且至少比keepalive_timeout多留 5–10 秒缓冲 - 确认 CDN/WAF 的空闲超时 ≥ Nginx 的
keepalive_timeout，否则连接在半路就被回收，浏览器看到的是“连接重置”而非正常复用 - 用
curl -v https://domain.com观察* Connection #0 to host domain.com left intact是否频繁出现；若总是新建连接，大概率是中间层干扰
配合 reset_timedout_connection 加速资源释放
超时后默认发 FIN，连接卡在 TIME_WAIT，socket 无法立即复用：
- 在
http或server块中启用reset_timedout_connection on; - 启用后，Nginx 直接发 RST，内核立刻回收 socket，对慢速攻击和异常断连特别有效
- 这不改变复用逻辑，但让“该断的连接断得干净”，腾出资源给新连接
不复杂但容易忽略
