client_header_timeout的核心目标是秒级识别并切断恶意拖延的请求头连接，防止worker进程、socket句柄和内存被长期占用；它仅控制从首个http字节到\r\n\r\n解析完成的耗时，防slowloris类攻击，不防body慢传、响应慢读、tls握手慢或header内容恶意。
合理配置 client_header_timeout 的核心目标，是让 Nginx 在请求头接收阶段就快速识别并切断恶意拖延连接，避免 worker 进程、socket 句柄和内存缓冲区被长期占用。它不依赖后端配合，也不等待业务逻辑，纯在事件循环内完成“秒级裁决”——超时即返回 408 并断连，不进 upstream、不占后端资源、不记完整请求行。
明确它防什么、不防什么
这个参数只管一件事：从 TCP 连接收到第一个字节（含 TLS 握手完成后的首个 HTTP 字节）起，到完整解析出请求头（以 \r\n\r\n 结尾）为止的总耗时。
- ✅ 防“建了连、发 GET /、就停住”，或每 10–30 秒补一个
User-Agent:的 Slowloris 类攻击 - ✅ 防攻击者用小包分段发送 header，人为拉长接收时间，挤占并发连接池
- ❌ 不防请求体（body）传输慢 → 应由
client_body_timeout控制 - ❌ 不防客户端缓慢读响应 → 属
send_timeout范畴 - ❌ 不防 TLS 握手慢 → 必须用
ssl_handshake_timeout - ❌ 不校验 header 内容是否含恶意字段 → 属 WAF 或应用层职责
按业务链路设合理阈值
不能统一设成 3 秒或 60 秒，需结合真实流量中请求头传输的 P99 耗时设定，而非拍脑袋。
- 标准公网 Web 页面或 REST API：设为 7–10 秒。主流浏览器、curl 和 SDK 通常在 1–2 秒内发完全部 header；10 秒可覆盖跨境抖动、CDN 中转延迟，又能拦截每 10 秒才补字段的扫描器
-
含 JWT Token、多段 Cookie 或 SSO 鉴权头的网关：建议 10–15 秒。但必须同步检查
client_header_buffer_size和large_client_header_buffers是否足够，否则缓冲区溢出会触发重试，反而延长等待 - 内网反代或 Kubernetes Ingress 后置服务：可压至 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;：确保能容纳常见大 header（如长 Token、多段 Cookie），避免因缓冲不足导致异常等待或重试
验证是否真正生效
不能只看 reload 成功，要实测行为：
- 用 curl 模拟慢速头部发送：
curl -X GET http://your-domain.com/ --limit-rate 10 -m 30（限速 10 字节/秒，总超时 30 秒） - 检查 Nginx
error.log是否出现client timed out while reading client request headers - 观察 access log 中状态码是否为 408，且
$request_time接近你设置的 timeout 值（如 6.98s），说明配置已起效 - 运行
netstat -ant | grep :80 | grep SYN_RECV，确认慢速攻击连接未在半开状态持续堆积
