client_header_timeout 是 Nginx 防御慢速头部攻击的底层超时机制，仅限制请求头接收时间（从首字节到\r\n\r\n），超时即返回408并中断连接；它不控制请求体、总耗时、内容校验或响应读取，推荐值为3–15秒，需配合 reset_timedout_connection、连接限速及缓冲区配置形成闭环防护。
client_header_timeout 是 Nginx 防御慢速头部攻击（Slow Headers）最直接、最底层的一道防线。它不判断内容是否恶意，只严格计时——从 TCP 连接建立后收到第一个字节起，到完整接收到 HTTP 请求头（以 \r\n\r\n 结尾）为止，若超时即刻中断连接，返回 408 状态码，且不进入后续任何处理流程（不转发、不缓存、不记录 access log 中的完整请求行）。
它防的是什么行为
专门针对“建了连、发一点、就停住”的头部拖延行为：
- 攻击者只发送
GET /后长期不补Host:或空行，让 Nginx 卡在解析头阶段 - 每 10–30 秒才追加一个伪造 header 字段（如
User-Agent: a），人为拉长头部接收过程 - 利用默认 60 秒超时，使单个 worker 进程被数百个半开连接占满，真实用户无法建连
它不防什么，避免误用
明确边界有助于合理配置：
- 不控制请求体（body）传输速度——那是
client_body_timeout的职责 - 不限制整个请求耗时（比如大文件上传总时间），也不影响响应生成或后端交互
- 不校验 header 内容合法性（如 SQL 注入、XSS），那是 WAF 或应用层的事
- 不处理客户端缓慢读取响应的行为（Slow Read），需靠
send_timeout和 TCP 层配合
推荐配置值与业务适配逻辑
不能一刀切，要结合真实链路延迟和头部复杂度：
- 标准 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），避免因缓冲溢出导致反复重试、变相延长等待 - 日志中加入
$request_time和$status：便于从 access log 快速识别status=408且request_time接近 timeout 值的请求，确认攻击是否被有效拦截
