keepalive_timeout本身不防攻击，但设为15–30秒可快速清理空闲连接，须搭配reset_timedout_connection on发rst立即回收socket，并与keepalive_requests形成“时间+次数”双退出机制防慢速攻击。
keepalive_timeout 本身不是安全指令，但设得不合理会直接放大慢速连接攻击（如 Slowloris）的风险——空闲连接长期不释放，快速耗尽 worker_connections 和文件描述符，导致服务拒绝。
超时过长：给慢速攻击留出“温床”
默认 75 秒太宽松。攻击者只需建立数百个 TCP 连接，每 60 秒发一个字节，就能让连接长期处于空闲状态却不超时。这些连接持续占用 socket、内存和连接槽位，最终触发 Too many open files 或 503 Service Unavailable。
- 生产环境不建议超过 30 秒；高频接口可压到 15 秒
- 若设为 60 秒以上，必须确认上游负载均衡器（如 AWS ALB、SLB）或 CDN 的 keep-alive 超时 ≥ Nginx 值，否则中间设备先断连，反而引发重试风暴
仅设 timeout 不够：缺少 RST 强制回收会失效
keepalive_timeout 超时后默认发送 FIN，进入 TIME_WAIT 状态，socket 仍被内核占用约 60 秒，无法立即复用。攻击者正是利用这个窗口维持大量半死连接。
- 必须搭配 reset_timedout_connection on;（放在 http 或 server 块）
- 启用后，超时直接发 RST，跳过四次挥手，内核立刻回收 socket
- 这是防 Slowloris 类攻击最关键的一步，单靠调小 timeout 无效
忽略客户端与中间层行为：策略形同虚设
即使 Nginx 配置合理，若前端或中间设备破坏 keep-alive 协议，实际连接仍无法复用，反而因频繁重建加剧压力。
- 检查客户端是否主动加了 Connection: close（如某些旧版 SDK 或手动配置的 Axios）
- 确认 CDN/WAF/云 LB 没覆盖或强制改写 Keep-Alive 响应头
- 避免在 location 中对 API 接口误配 proxy_set_header Connection "close"
未配合计数限制：防不住“低频活跃”恶意连接
攻击者可控制节奏，比如每 25 秒发一次请求，永远卡在 keepalive_timeout 临界点前，让连接永不超时。此时仅靠时间维度无法切断。
- 必须启用 keepalive_requests，形成“时间 + 次数”双退出机制
- 公网入口、登录页等高风险路径建议设为 50–100
- 常规 Web 页面可设 1000–2000，任一条件满足即断连
不复杂但容易忽略：安全效果不取决于单个参数多大，而在于 timeout、reset_timedout_connection、keepalive_requests 三者协同，再叠加 client_header_timeout（建议 ≤30s）和 send_timeout（建议 15–30s）共同收口。
