client_header_timeout是Nginx防御Slowloris慢速头部攻击的底层防线，严格限制请求头接收超时并立即断连返回408；它专防“建连后拖延发头”行为，不防body传输、全请求耗时、内容攻击或慢读响应。
client_header_timeout 是 Nginx 防御 Slowloris 类慢速头部攻击最直接、最底层的防线。它不分析请求内容，只严格计时：从 TCP 连接建立后收到第一个字节起，到完整接收 HTTP 请求头（以 \r\n\r\n 结尾）为止。超时即刻断连、返回 408 状态码，且不进入 upstream 转发、不记录完整 access log、不占用后端资源。
它防什么？专治“建了连、发一点、就停住”
Slowloris 攻击的核心手法是故意拖延请求头发送节奏：
- 只发
GET / HTTP/1.1\r\n后长期不补Host:或空行 - 每 10–30 秒追加一个伪造 header（如
User-Agent: a），人为拉长头部接收过程 - 利用默认 60 秒超时，让单个 worker 进程被数百个半开连接占满，真实用户无法建连
它不防什么？避免配置误用
明确边界才能合理调优：
- 不管请求体（body）传输速度——那是
client_body_timeout的职责 - 不限制整个请求耗时（如大文件上传总时间），也不影响响应生成或后端交互
- 不校验 header 内容合法性（如 SQL 注入、XSS），需由 WAF 或应用层处理
- 不处理客户端缓慢读取响应的行为（Slow Read），需靠
send_timeout和 TCP 层配合
推荐值要匹配业务链路真实延迟
不能一刀切，需结合 P99 头部接收耗时与网络环境：
- 标准 Web 页面与 REST API：设为 7–10 秒。现代浏览器 TLS 握手后通常 1–2 秒内发完全部 header，10 秒足以覆盖跨境或弱网场景
- 含 JWT Token、多段 Cookie 或自定义鉴权头的后台系统：可放宽至 15 秒，但必须同步检查
client_header_buffer_size和large_client_header_buffers是否足够，否则缓冲不足会触发重试，反而延长等待 - 内网直连或可信网关后置服务：可压至 3–5 秒，链路稳定、无 NAT 和中间设备干扰，防御强度更高
- 不建议低于 3 秒：部分合规终端、老旧 IoT 设备或高丢包移动网络可能出现合法延迟，易误杀
必须配套的关键配置项
单设 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;：确保缓冲能力匹配实际头部大小，尤其在使用长 Token 或多段 Cookie 时 - 在
log_format中加入$request_time和$status，便于在 access log 中识别长期卡在 header 阶段的请求（status=408且request_time接近 timeout 值）
