如何合理配置 client_header_timeout：防止慢速恶意攻击占用安全请求头导致常规路径响应时间大幅拉长

client_header_timeout的核心目标是秒级识别并切断恶意拖延的请求头连接，防止worker进程、socket句柄和内存被长期占用；它仅控制从首个HTTP字节到rnrn解析完成的耗时，防Slowloris类攻击，不防body慢传、响应慢读、TLS握手慢或header内容恶意。

合理配置 client_header_timeout 的核心目标，是让 Nginx 在请求头接收阶段就快速识别并切断恶意拖延连接，避免 worker 进程、socket 句柄和内存缓冲区被长期占用。它不依赖后端配合，也不等待业务逻辑，纯在事件循环内完成“秒级裁决”——超时即返回 408 并断连，不进 upstream、不占后端资源、不记完整请求行。

明确它防什么、不防什么

这个参数只管一件事：从 TCP 连接收到第一个字节（含 TLS 握手完成后的首个 HTTP 字节）起，到完整解析出请求头（以 rnrn 结尾）为止的总耗时。

• ✅ 防“建了连、发 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，确认慢速攻击连接未在半开状态持续堆积