keepalive_timeout 是空闲连接保持时长而非长连接开关，需 HTTP/1.1、客户端及中间设备支持才能生效；按业务设合理值：静态资源60–120秒，移动端API 15–30秒，微服务5–15秒，内网后台60–300秒，HTTP/2可设0或5秒。
keepalive_timeout 不是用来“开启”长连接的开关，而是决定空闲连接能挂多久。它真正起作用的前提是：HTTP/1.1 已启用、客户端支持 keep-alive、中间设备（如 WAF 或云 LB）不主动中断——满足这些，调对这个值才能让复用真实发生、资源不被浪费。
按业务类型设合理区间
不同请求节奏决定不同等待时间：
- 静态资源服务（CDN、图片/JS/CSS）：用户连续加载行为密集，复用窗口长 → 推荐 60–120 秒
- 移动端 API 或 WebApp 后端：弱网、切后台、保活策略严苛 → 推荐 15–30 秒
- 微服务间高频调用（含健康检查）：连接数易成瓶颈 → 推荐 5–15 秒，并配合 keepalive_requests 限制单连接请求数
- 内网管理后台或 SSE 流式服务：连接稳定、客户端持续活跃 → 可设 60–300 秒
- 启用 HTTP/2 的服务：连接生命周期由客户端主导 → keepalive_timeout 可设为 0 或 5 秒，Nginx 不必强留
必须同步调整的关键配置
单独改 keepalive_timeout 效果有限，以下几项需联动生效：
- keepalive_requests：默认 100，建议与 timeout 缩放匹配（如 timeout=15s 时设为 50），防止单连接被异常客户端长期霸占
- client_header_timeout 和 client_body_timeout：必须 ≤ keepalive_timeout，否则可能因读取超时提前断连，造成“假空闲”误判
- upstream keepalive：若用 proxy_pass，必须在 upstream 块中显式配置 keepalive 32;，并确保后端也支持长连接（如 Spring Boot 需设 server.tomcat.keep-alive-timeout）
- 系统级限制：检查 ulimit -n（文件描述符上限）和 net.core.somaxconn（连接队列长度），确保支撑预期长连接数
验证是否真起效
上线后不能只看配置是否写对，要观察真实连接行为：
- 用 curl -I https://your.site/ 查响应头，确认含 Connection: keep-alive 和 Keep-Alive: timeout=XX
- 用 ss -tnpo | grep :80 | grep ESTAB | wc -l 查当前 ESTABLISHED 连接数，对比 upstream keepalive 设置是否被充分利用
- 监控 nginx_stub_status 中 Active connections 与 Waiting 状态比例 —— Waiting 高但 Writing 低，说明复用率低
- 检查 error log 是否出现 upstream prematurely closed connection，这往往意味着上下游 keepalive 超时不匹配
安全与稳定性增强手段
防止慢速攻击或僵尸连接长期占资源：
- reset_timedout_connection on;：放在 http 或 server 块中，超时后发 RST 直接回收 socket，跳过 TIME_WAIT
- 搭配 keepalive_requests 形成“时间 + 次数”双退出机制，任一条件满足即关闭连接
- 弱网场景下，适当调高 client_header_timeout（如上传大图设 30 秒）和 send_timeout（如生成大文件响应设 60 秒），避免传输中途被误杀
