client_header_timeout是Nginx控制客户端发送请求头超时时间的指令，从接收首字节起计算，超时返回408；仅作用于请求头读取阶段，不影响请求体传输，可在http/server/location块中配置，需reload生效。
client_header_timeout 是 Nginx 防御慢速头攻击（Slow Headers）的第一道防线。它不控制整个请求耗时，而是限定客户端发送完整 HTTP 请求头（即从 TCP 连接建立到收到 \r\n\r\n 分隔符）所允许的最长时间。超时即断连并返回 408，不进入后续处理流程。
慢速头攻击如何利用默认配置
攻击者建立大量 TCP 连接后，每 10–30 秒只发一个请求头字段（如 User-Agent: 或 Cookie:），故意拖延至完整头部收齐。Nginx 默认 client_header_timeout 为 60 秒（部分版本为 65 秒），意味着每个连接会持续占用 worker 进程、socket 句柄和内存缓冲区近一分钟——几百个此类连接即可打满并发上限，造成真实用户无法建连。
合理取值需兼顾业务与防御强度
- 普通 Web 页面/API：设为 5–10 秒。现代浏览器或标准 SDK 在 TLS 握手完成后，通常 1–3 秒内即可发出完整头部
- 含大量 Cookie 或自定义头的管理后台：可放宽至 15 秒，但需同步检查
client_header_buffer_size和large_client_header_buffers是否足够，避免因缓冲不足触发额外错误 - 不建议低于 3 秒：高延迟链路（如跨境访问、弱网移动设备）可能出现合法头部传输延迟，过短易误杀
必须配合的关键配置项
- reset_timedout_connection on：强制发送 RST 包中断连接，跳过四次挥手，立即释放系统资源
-
client_header_buffer_size 和 large_client_header_buffers：确保缓冲能力匹配实际头部大小。例如，若业务使用长 JWT Token 或多段 Cookie，建议设为
client_header_buffer_size 4k; large_client_header_buffers 4 16k; -
limit_conn：在超时生效前限制单 IP 连接数，防止攻击者用不同 IP 绕过。例如：
limit_conn_zone $binary_remote_addr zone=perip:10m;+limit_conn perip 15; -
log_format 中加入
$request_time和$status，便于在 access log 中识别长期卡在 header 阶段的请求（status=408且request_time接近 timeout 值）
验证是否生效的实操方式
用 curl 模拟慢速头部发送：
curl -X POST http://your-gateway.com/api --header "X-Test: $(printf 'a%.0s' {1..8000})" --limit-rate 50 -m 30
该命令以 50 字节/秒速率发送超长 header，并设置客户端总超时为 30 秒。若 Nginx 在 10 秒内返回 408 且 error log 出现 client timed out，说明配置已起效。同时观察 netstat -ant | grep :80 | grep SYN_RECV，慢速攻击连接应无法长期堆积。
