Nginx 中 keepalive_timeout 连接复用策略优化

keepalive_timeout 仅为连接复用提供时间窗口，需结合业务节奏、客户端特性分层配置，并配合 keepalive_requests 和链路协同才能有效复用。

keepalive_timeout 本身不“优化”复用，而是为复用提供时间窗口——设得合理，连接才可能被复用；设得失当，复用就无从发生。它只管 Nginx 与客户端之间空闲连接能等多久，不干预 TLS 握手、HTTP/2 多路复用，也不影响 upstream 连接。真正起效，必须匹配业务节奏、客户端行为和链路环境。

按流量特征分层设置 timeout 值

统一设一个值容易顾此失彼。建议根据请求类型和终端特性差异化配置：

• 面向浏览器的静态资源（JS/CSS/图片）：用户连续加载密集，空闲期短 → 设 30–45 秒
• 移动端 API 或小程序后端：弱网常见、中间设备（如运营商 NAT）超时多在 2–5 分钟 → 设 15–30 秒更稳妥
• 后台管理系统或内网低频服务：操作间隔长，复用率天然低 → 可设 10–20 秒，避免无效驻留
• 长轮询或 SSE 接口：需确认客户端持续心跳且链路透传 keep-alive → 可设 60–120 秒，但务必验证客户端是否真在用

配合 keepalive_requests 形成双退出机制

单靠 timeout 防不住“低频活跃”的连接（比如每 25 秒发一次请求）。加上请求数限制，才能堵住空转缝隙：

• 公网高风险入口（登录页、注册接口）：keepalive_requests 50–100
• 常规 Web 页面或 SPA 应用：keepalive_requests 1000–2000
• 两者任一条件满足即断连：要么空闲超时，要么请求数用完

确保客户端与中间链路不打断复用

服务端配再好，若链路中某环主动断连，复用也白搭：

• 用 curl -I 检查响应头：必须含 Connection: keep-alive，且无 Connection: close
• 确认 CDN、WAF、企业防火墙或云 LB 的空闲超时 ≥ Nginx 的 keepalive_timeout，否则连接在中间层就被回收
• 移动端 SDK（如 OkHttp、Retrofit）默认支持 keep-alive，但需检查是否显式设置了过短的 idleTimeout

启用 reset_timedout_connection 加速资源回收

仅设 timeout 不够——超时后若只发 FIN，连接仍卡在 TIME_WAIT，socket 无法立即释放：

• 在 http 或 server 块中添加 reset_timedout_connection on;
• 启用后，Nginx 超时直接发 RST，跳过四次挥手，内核立刻回收 socket
• 这对 Slowloris 类慢速攻击特别有效，也能缓解因客户端异常断连导致的僵尸连接堆积