tcp keepalive是传输层死连接检测机制，通过空闲超时后发送探测包（默认7200秒）、间隔重试（默认75秒）、达上限关闭（默认9次）来释放无效连接；需显式启用so_keepalive并调优参数适配场景。
keepalive 本身不是防御手段，而是资源复用机制；真正防慢连接攻击，靠的是对 keepalive 生命周期的主动管控——既要让它复用得上，又要让它退得果断。核心是把空闲等待变成可预测、可中断、可强制回收的过程。
keepalive_timeout 要设得“够短又够用”
默认 75 秒太宽松，攻击者只需每 60 秒发一个字节，就能让连接长期卡在空闲状态。生产环境建议：
- 公网 API 或高风险入口：设为 5–10 秒，配合 reset_timedout_connection on 立即释放 socket
- 常规 Web 页面或 SPA 应用：设为 15–30 秒，覆盖一次完整页面加载（通常 10–20 秒），又不给慢速连接留温床
- 内网服务或流式响应（SSE）：可放宽至 60–300 秒，但必须确认后端和中间设备（如 CDN、WAF）的 keep-alive 超时 ≥ 此值，否则会引发重试风暴
必须开启 reset_timedout_connection on
只调小 keepalive_timeout 不够——超时后若只发 FIN，连接会进入 TIME_WAIT 状态，socket 仍被内核占用约 60 秒，攻击者正利用这个窗口维持半死连接。启用后：
- Nginx 超时直接发送 RST 包，跳过四次挥手
- 内核立刻回收 socket 和文件描述符，避免 “Too many open files”
- 配置位置：放在 http 或 server 块中即可生效
搭配 keepalive_requests 形成双退出机制
单靠时间维度防不住“低频活跃”恶意连接（比如每 25 秒发一次请求）。keepalive_requests 是计数维度的强制轮换：
- 公网 API 网关、登录页等高风险入口：设为 50–100
- 常规 Web 服务：设为 1000–2000
- 两者任一条件满足即断连：要么空闲超时，要么请求数用完，不留空转缝隙
同步收紧其他关键超时参数
慢连接攻击常分阶段实施，需全链路协同防护：
- client_header_timeout：设为 5–10 秒，拦住 Slowloris 类“只连不发头”的连接
- client_body_timeout 和 send_timeout：均建议 5–10 秒，分别控制请求体接收与响应发送的空闲间隔
- proxy_read_timeout（如使用 upstream）：设为 15–30 秒，防止后端响应慢拖垮上游连接
避开常见误配陷阱
这些操作看似加强防护，实则削弱效果甚至引入新问题：
- 不要设
keepalive_timeout 0：等于禁用 keepalive，导致每个请求新建 TCP 连接，加剧 TIME_WAIT 和 TLS 握手开销 - 别忽略客户端行为：确认前端未加
Connection: close，CDN/WAF 没覆盖 Keep-Alive 响应头 - 别孤立调参：需同步检查
client_header_buffer_size和large_client_header_buffers，确保能容纳合法大 header，避免因缓冲不足触发异常等待
