keepalive_timeout不是设得越大越好，而是需平衡连接复用与资源释放：静态资源推荐60–120秒，移动端api建议15–30秒，微服务间调用宜5–15秒，并须联动keepalive_requests、upstream keepalive及后端配置协同调优。
keepalive_timeout 不是“设得越大越好”，而是要让连接在真正需要复用时保持打开，在空闲时及时释放。它控制的是 Nginx 与客户端之间空闲连接的最长等待时间，核心目标是减少重复建连开销，同时避免文件描述符和内存被长期占用。
按业务类型设定合理区间
不同流量特征决定不同取值逻辑：
- 静态资源服务（CDN、图片/JS/CSS）：用户常连续请求，复用价值高 → 推荐 60–120 秒
- 移动端 API 或 WebApp 后端：网络不稳定、请求间隔不规律 → 推荐 15–30 秒
- 微服务间高频调用（如健康检查+业务请求）：连接数易成瓶颈 → 推荐 5–15 秒，并配合 keepalive_requests 限制单连接请求数
- 内网管理后台或低频系统：资源压力小，可放宽至 45–60 秒
必须同步调整的关键配置
单独改 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）
- worker_connections 与系统限制：检查 ulimit -n 和 net.core.somaxconn 是否足够支撑预期长连接数
验证是否生效的实用方法
上线后不能只看配置，要观测真实行为：
- 用 curl -I https://your.site/ 查响应头，确认含 Connection: keep-alive 和 Keep-Alive: timeout=XX
- 监控 nginx_stub_status 中 Active connections 与 Waiting 状态比例，Waiting 高但 Writing 低说明复用率低
- 用 ss -tnpo | grep :80 | grep ESTAB | wc -l 查当前 ESTABLISHED 连接数，对比 upstream keepalive 设置是否被充分利用
- 检查 error log 是否出现 upstream prematurely closed connection，这往往意味着上下游 keepalive 超时不匹配
安全与稳定性增强手段
防止慢速攻击或僵尸连接长期占资源：
- reset_timedout_connection on;：放在 http 或 server 块中，超时后发 RST 直接回收 socket，跳过 TIME_WAIT
- 搭配 keepalive_requests 形成“时间 + 次数”双退出机制，任一条件满足即断连
- 收紧 send_timeout（建议 10–15 秒）和 client_header_timeout（建议 8–12 秒），堵住慢速发包漏洞
