client_header_timeout用于防御慢速头部攻击，设为5–8秒可兼顾安全与可用，需配合reset_timedout_connection on使用，并通过curl限速模拟验证。
client_header_timeout 控制 Nginx 等待客户端发送完整 HTTP 请求头的最长时间。它不判断内容是否合法，而是识别“迟迟不发完头”的连接——这正是慢速头部攻击（Slow Headers）的核心特征。
它真正起作用的场景
攻击者建立 TCP 连接后，只发 GET / HTTP/1.1\r\nHost: example.com\r\n，故意卡住不发结尾的 \r\n\r\n。Nginx 会一直等，直到超时才断开。默认值通常是 60 秒，足够让几十个恶意连接把 worker 占满。
- 正常浏览器或 App 在 DNS、TLS 握手完成后，一般 1–3 秒内就能发完全部 header
- 弱网下的合法请求（如高延迟移动网络）可能拖到 8–12 秒，但极少超过 15 秒
- 攻击者若每 10 秒只发一个 header 字段，设为 5 秒即可立即中断
合理取值要兼顾安全与可用
不能一刀切设成 1 秒（误杀率高），也不能维持默认 60 秒（防御失效）。应按业务链路稳定性分级设置：
- 面向公网的 API 网关或登录页：建议 5–8 秒。这类接口对首字节延迟敏感，且客户端环境相对可控
- 企业内网管理后台（如运维平台）：可放宽至 15 秒，因中间可能经过多层代理或老旧防火墙
- 面向 IoT 设备或定制终端的接口：若设备固件协议栈较旧，可设 20 秒，但需同步监控异常长连接
必须配合 reset_timedout_connection 使用
仅设 client_header_timeout 不够。超时后若只是关闭连接，TCP 连接可能滞留在 TIME_WAIT 状态，仍占用端口和资源。务必启用：
该指令会让 Nginx 主动发送 RST 包重置连接，快速释放内核连接槽位，避免被慢连接缓慢填满。
验证是否生效的实操方式
用 curl 模拟攻击行为最直接：
-
--limit-rate 10限制发送速率为 10 字节/秒，模拟慢速 header 分段发送 -
-m 30是客户端总超时，确保测试能结束 - 检查 Nginx error log 是否出现
client timed out (XX: Connection timed out) - 观察 access log 中状态码是否为
408 Request Time-out，且$request_time接近你设置的 timeout 值
