client_header_timeout是防范slowloris类慢速头部攻击最直接有效的配置，从首字节起计时至\r\n\r\n结束，超时返回408并秒级断连；公网设7秒、网关10–15秒、内网3–5秒，须配套reset_timedout_connection on、limit_conn和缓冲区调优。
client_header_timeout 是 Nginx 防范 Slowloris 类慢速头部攻击最直接有效的配置项，它从客户端发来第一个 HTTP 字节起计时，到完整收到 \r\n\r\n（空行）为止；超时即返回 408 并立即断连，不进 upstream、不占后端资源、不触发业务逻辑。
在 server 块中直接设置 timeout 值
该参数支持在 http、server 或 location 块中配置。推荐优先放在 server 块内，实现按服务粒度差异化防护：
- 公网 Web 页面或标准 API 接口：设为
7s - 含 JWT Token、多段 Cookie 或 SSO 鉴权头的网关服务：设为
10–15s，但需先观察真实流量的 P99 头部接收耗时再加缓冲 - 内网反代或 Kubernetes Ingress 后置服务：可设为
3–5s，链路稳定且无中间设备干扰
必须配套的三项关键配置
单设 client_header_timeout 效果有限，需与以下配置协同生效，形成事件循环级闭环防护：
-
reset_timedout_connection on;：超时后主动发送 RST 包中断连接，跳过四次挥手，秒级释放 socket 句柄和内核连接槽位，避免 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（如长 Token、多段 Cookie），避免因缓冲不足触发重试或异常等待，反而延长连接占用时间
验证是否真正生效
不能仅靠 nginx -s reload 成功就认为配置起效，需实测模拟慢速行为：
- 用 curl 模拟慢速头部发送：
curl -X GET http://your-domain.com/ --limit-rate 10 -m 30（限速 10 字节/秒，总超时 30 秒） - 观察是否在设定值（如 7 秒）内返回
408 Request Timeout，并检查 error log 是否出现client timed out日志 - 在 access log 中加入
$request_time和$status，筛选出status=408且request_time接近 timeout 值的请求，确认是头部阶段被拦截
明确它防什么、不防什么
这个参数只控制请求头接收阶段，有明确边界：
- ✅ 防“建了连、发 GET /、就停住”，或每 10–30 秒补一个字段的 Slowloris 类攻击
- ❌ 不防请求体（body）传输慢 → 应由
client_body_timeout控制 - ❌ 不防客户端缓慢读响应 → 属
send_timeout范畴 - ❌ 不防 TLS 握手慢 → 必须用
ssl_handshake_timeout - ❌ 不校验 header 内容是否含恶意字段 → 属 WAF 或应用层职责
