client_header_timeout 是 nginx 在请求头解析阶段的超时控制，仅作用于 tcp/tls 完成后、完整 http 头（\r\n\r\n）接收前，超时返回 408 并释放连接资源，需配合 reset_timedout_connection、连接限速和缓冲区配置协同生效。
client_header_timeout 是 Nginx 在请求头读取阶段“秒级止损”的关键开关。它不提升单次请求速度，但能快速释放被卡住的连接资源，从而显著提升并发吞吐效率。配置时核心不是盲目压低数值，而是让超时阈值紧贴真实头部传输耗时，同时避免误杀合法弱网请求。
明确 client_header_timeout 的作用边界
它只在 TCP 连接建立、TLS 握手完成之后启动计时，从收到第一个 HTTP 字节起，到完整解析出请求头（即遇到 \r\n\r\n）为止。超时即返回 408 并断连，不进 upstream、不占后端、不记完整 access log。
它防的是：
- 慢速头攻击（如 Slowloris：只发
GET /就停住） - 中间代理分段转发导致头部延迟到达
- 客户端异常退出后 socket 半开
它不防：
- TLS 握手慢（需用
ssl_handshake_timeout） - 请求体上传慢（由
client_body_timeout控制） - 响应发送慢或客户端读得慢（由
send_timeout管理）
按业务场景设合理阈值
默认 60 秒对防护毫无意义，必须下调。推荐值基于真实流量 P99 头部传输耗时，并留出安全余量：
- 面向公网的标准 Web 页面或 REST API：设为 7–10 秒
- 含 JWT Token、多段 Cookie 或 SSO 头的鉴权网关：设为 10–15 秒（需同步检查缓冲区是否足够）
- 内网直连服务（如 k8s Pod 间调用）：可设为 3–5 秒
- 移动端或老旧 IoT 设备接入接口：若已知冷启动延迟高，可临时放宽至 30 秒，但须配合日志监控异常增长
不建议低于 3 秒——Linux 协议栈、TLS 解密、Nginx 缓冲拷贝等基础开销，在高负载下可能逼近该临界值。
必须配套的三项协同配置
单设 client_header_timeout 效果有限，需在事件循环层面闭环释放资源：
-
reset_timedout_connection on;：超时后直接发 RST 包，跳过四次挥手，立即回收 socket 句柄和内核连接槽位 -
limit_conn_zone $binary_remote_addr zone=perip:10m;+limit_conn perip 10;：防止攻击者用多个 IP 绕过单连接超时 -
client_header_buffer_size 4k; large_client_header_buffers 4 16k;：确保缓冲能力匹配实际头部大小，避免因缓冲不足触发重试或额外错误
验证配置是否生效
- 用
telnet your-domain.com 80连接后，仅输入GET / HTTP/1.1回车，不发Host:也不发空行，等待约设定秒数后应看到连接被服务器主动关闭 - 查看 error log：
grep "client timed out.*reading client request headers" /var/log/nginx/error.log，确认超时日志出现且时间点与配置值基本一致 - 模拟慢速头部：
curl -X POST http://your-api.com --header "X-Foo: $(printf 'a%.0s' {1..10000})" --limit-rate 20 -m 30，观察是否在client_header_timeout设定时间内返回 408
不复杂但容易忽略
