keepalive_timeout推荐设为15–30秒，兼顾复用与清理，需搭配reset_timedout_connection on实现RST快速回收，并与keepalive_requests形成“时间+次数”双退出机制，防慢速攻击。
keepalive_timeout 本身不防攻击，但设得合理，能快速清理空闲连接，配合其他策略一起堵住慢速连接对套接字的长期占用。关键不是让它“更长”来容忍异常，而是“够短又够用”，让连接该复用时复用，该退出时果断退出。
设为 15–30 秒，兼顾复用与清理
默认 75 秒太松，攻击者可维持大量空闲连接占满 worker_connections；设为 0 又太激进，引发大量 TIME_WAIT 和 TLS 握手开销。生产环境推荐统一设为 15–30 秒：
- 现代浏览器、主流 HTTP 客户端（如 curl、OkHttp、requests）均支持 30 秒 keep-alive，兼容性无问题
- 一次完整页面加载或 API 会话通常在 10–20 秒内完成多请求，30 秒足够覆盖，又不会让连接“睡太久”
- 若业务明确高频短请求（如心跳、轮询），可压到 15 秒；若含少量弱网用户，不建议低于 10 秒
必须搭配 reset_timedout_connection on
只设 timeout 不够——超时后若只发 FIN，连接仍处于 TIME_WAIT 状态，socket 无法立即回收。加这一行才能真正释放资源：
- 启用后，Nginx 超时直接发 RST 中断连接，跳过四次挥手，内核立刻回收 socket
- 这对 Slowloris 类攻击尤其有效：攻击者建一堆连接却不发新请求，RST 能快速清掉它们
- 配置示例：reset_timedout_connection on; 放在 http 或 server 块中即可生效
和 keepalive_requests 形成双退出机制
单靠空闲超时防不住“低频活跃”的恶意连接（比如每 20 秒发一个请求）。keepalive_requests 是主动计数器，强制连接干完活就退场：
- 公网接口、登录页等高风险入口，设 keepalive_requests 50–100
- 常规 Web 页面或 SPA 应用，设 keepalive_requests 1000–2000
- 两者任一条件满足即断连：要么空闲超时，要么请求数用完，不留空转缝隙
避开常见误配陷阱
这些操作看似加强防护，实则削弱效果甚至引入新问题：
- 不要设 keepalive_timeout 0：这不是“强制关闭长连接”，而是禁用 keepalive，导致每个请求新建 TCP 连接，加剧 TIME_WAIT 和 CPU 压力
- 别忽略客户端行为：确认前端没加 Connection: close，CDN/WAF 没覆盖 Keep-Alive 头
- 别孤立调参：需同步收紧 client_header_timeout（建议 8–30s）、send_timeout（建议 15–30s），并开启 proxy_buffering off（流式响应场景）
