keepalive_timeout本身不解决“重连慢”，它控制连接空闲多久后关闭；重连慢的根源是设值不合理或未配合proxy_http_version 1.1、proxy_set_header connection ''和upstream keepalive等关键配置。
keepalive_timeout 本身不解决“重连慢”，它控制的是连接空闲多久后被关闭。所谓“重连慢”，其实是连接被过早关闭、或根本没复用上，导致客户端不得不反复建连——根源在于 keepalive_timeout 设得不合理，或没配合其他关键配置。
先确认是不是真在复用连接
很多问题不是 timeout 太短，而是连接压根没复用起来：
- 用 curl -I https://your-site.com 查响应头：必须看到 Connection: keep-alive，且有 Keep-Alive: timeout=XX
- 浏览器开发者工具 Network 标签页，看多个请求是否共用同一个 connection ID（Chrome 中显示为 “reused”）
- 别忽略前端行为：JS fetch/AJAX 默认带 Connection: keep-alive，但某些 SDK 或旧版库可能手动设了 close
设对值：不是越长越好，也不是越短越快
默认 75 秒太宽泛，容易堆积空闲连接；设成 0 又彻底禁用复用，每次请求都三次握手+TLS，反而更慢。推荐按场景选：
- 常规 Web 页面（含 HTML/JS/CSS）：20–30 秒 —— 足够加载整页资源，又不拖住连接
- API 接口服务（移动端、App 后端）：45–60 秒 —— 请求间隔较稳定，复用收益高
- 后台管理页或上传页面：可局部提高，比如 location /admin { keepalive_timeout 120; }，但需搭配 upstream 长连接
必须配套的关键配置
单调 keepalive_timeout 没用，下面三项缺一不可：
- proxy_http_version 1.1; —— HTTP/1.0 不支持默认长连接，必须显式升级
- proxy_set_header Connection ''; —— 清掉客户端传来的 Connection: close，否则会透传给后端，断掉复用链路
- upstream 块里加 keepalive N; —— 比如 keepalive 32;，让 Nginx 自己也跟后端保持连接池，否则前端复用了，Nginx 却频繁重连后端，照样慢
防慢速干扰，让复用更干净
恶意或异常客户端可能只建连不发请求，占着连接不让别人用。加这两行能快速回收：
- reset_timedout_connection on; —— 超时直接发 RST，跳过 TIME_WAIT，socket 立刻释放
- keepalive_requests 1000; —— 单连接最多处理 1000 次请求，防“低频但不死”的连接长期霸占资源
