合理配置 client_header_timeout（5–12秒）和 client_body_timeout（10–20秒）是防御slow headers/body类慢速攻击的基础防线，需联动 reset_timedout_connection、limit_conn 和缓冲区参数协同生效。
将 client_header_timeout 和 client_body_timeout 合理联动配置，是防御 DDoS/CC 类慢速攻击（尤其是 Slow Headers 和 Slow Body）最基础也最关键的防线。它们不依赖复杂规则或第三方模块，直接在连接建立初期就切断恶意拖延行为，避免资源被长期占用。
client_header_timeout：专治“只发半截头”的冻结连接
这个参数只管一件事：从 TCP 连接建立成功起，到收到完整 HTTP 请求头（即连续两个 \r\n）为止的总耗时。它不管内容是否合法、是否含恶意字段，只看时间。
- 默认 60 秒太宽松——攻击者每 59 秒补一个
User-Agent: x就能让连接永远卡住 - 设为 5–10 秒 是实战平衡点：覆盖绝大多数真实终端（含弱网、跨境、带 JWT/多 Cookie 的后台），又足够快地释放被占 worker 进程和 socket 句柄
- 超时后返回 408 并立即断连，不进 upstream、不记 access log 中的请求行，真正零后端开销
client_body_timeout：堵住“大包小传”的体部拖延
当请求头已收全、且是 POST/PUT 等含 body 的方法时，该参数开始计时——从收到最后一个 header 后，到收完全部 request body 所允许的最大等待时间。
- 典型攻击手法：声明
Content-Length: 1000000，但每 20 秒只发 1 字节，让连接持续数小时 - 建议设为 10–20 秒：比 header 超时略宽（因 body 可能确实较大），但仍远低于默认 60 秒
- 需同步检查
client_max_body_size是否合理——若业务无需上传大文件，设为100k或1m可提前拦截伪造大包
必须配套的三项联动动作
单设两个 timeout 不足以形成闭环，以下三项配置缺一不可：
- reset_timedout_connection on;：超时后主动发 RST 包，跳过四次挥手，避免 TIME_WAIT 占用端口和内存
- limit_conn_zone $binary_remote_addr zone=perip:10m; + limit_conn perip 10;：限制单 IP 初始并发连接数，防攻击者用多个地址绕过 timeout
- client_header_buffer_size 4k; + large_client_header_buffers 4 16k;：确保缓冲区能容纳常见长 header（如 JWT、多段 Cookie），否则缓冲溢出会触发重试，反而延长等待
不同场景下的推荐组合值
不能一刀切，要结合链路质量与业务特征调整：
- 公网 Web 页面 / REST API：client_header_timeout 7s，client_body_timeout 15s
- 内网微服务（Nginx 做网关）：client_header_timeout 3–5s，client_body_timeout 10s（链路稳定，可更激进）
- 含长 Token 或多鉴权头的管理后台：client_header_timeout 12s，client_body_timeout 20s，同时确认 large_client_header_buffers 足够
