client_header_timeout 是 nginx 防范 slowloris 类慢速头部攻击的核心参数，通过秒级超时断连释放资源，需配合 reset_timedout_connection、limit_conn 和缓冲区配置才能生效。
client_header_timeout 是 Nginx 防范 Slowloris 类慢速头部攻击（属于应用层 DDoS 的一种）最直接、最轻量的防线，但它本身不防传统流量型 DDoS（如 UDP Flood、SYN Flood），只针对“建连接后故意拖延发请求头”的资源耗尽型攻击。配置目标不是堵住所有攻击，而是让恶意连接在秒级内被识别并释放资源，保护 worker 进程、socket 句柄和内存缓冲区不被长期占用。
为什么这个参数能缓解 DDoS 影响
它从首字节到达开始计时，到完整收到 HTTP 请求头（以 \r\n\r\n 结尾）为止。超时即返回 408 Request Timeout 并断连——不进 upstream、不占后端资源、不记 access log 中的请求行、不触发业务逻辑。这意味着攻击者无法靠几百个半开连接拖垮你的服务。
典型攻击行为包括：
- 只发
GET /就停住，不补Host:或空行 - 每 10–30 秒追加一个伪造 header（如
User-Agent: a） - 利用默认 60 秒超时，持续占用连接槽位
按场景推荐 timeout 值（兼顾防御与兼容）
公网 Web 页面 / REST API：设为
7–10s
现代浏览器、curl、主流 SDK 通常 1–2 秒发完 header；10 秒可覆盖跨境延迟、CDN 中转抖动，又能拦截常见扫描器节奏含 JWT Token、多段 Cookie 或 SSO 鉴权头的网关：设为
10–15s
必须同步检查client_header_buffer_size和large_client_header_buffers是否足够，否则缓冲溢出会触发重试，反而延长等待内网直连 / Kubernetes Ingress 后置服务：压至
3–5s
链路稳定、无 NAT、无中间设备干扰，防御强度更高不建议低于 3 秒：老旧 IoT 设备、高丢包移动网络、合规终端可能出现合法头部延迟，过短易误杀
必须配套的三项关键配置（单设无效）
强制快速断连
reset_timedout_connection on;
超时后主动发 RST 包，跳过四次挥手，立即释放 socket 句柄和内核连接槽位，避免TIME_WAIT滞留-
限制单 IP 初始并发连接数
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;
若业务使用长 Token 或多段 Cookie，缓冲不足会导致解析失败或重试，反而延长连接生命周期
需协同调整的其他 timeout 参数
-
client_body_timeout应 ≥client_header_timeout（尤其含Expect: 100-continue的请求），避免 header 未收完就因 body 超时中断 -
keepalive_timeout建议略大于client_header_timeout（如设为75s），防止客户端复用连接时刚发完头就被断开 -
send_timeout控制响应发送间隔，一般设10–30s，防慢读响应拖住连接
验证是否真正生效（不能只 reload 就算完）
- 用 curl 模拟慢速头部：
curl -X GET http://your-domain.com/ --limit-rate 10 -m 30（限速 10 字节/秒） - 查 error.log 是否出现：
client timed out while reading client request headers - 查 access.log 中状态码是否为
408，且$request_time接近你设置的 timeout 值（如9.92s） - 运行
netstat -ant | grep :80 | grep SYN_RECV，确认慢速攻击连接数不再堆积
不复杂但容易忽略
