client_header_timeout是nginx用于限制客户端发送完整http请求头（至空行\r\n\r\n）的最大等待时间，建议生产环境设为5～15秒，并需配合client_body_timeout、keepalive_timeout等参数协同防护慢速http攻击。
在面对慢速 HTTP 扫描器（如 Slowloris、R-U-Dead-Yet）或恶意长连接探测时，client_header_timeout 是 Nginx 中一道关键但常被低估的防线。它不负责处理已建立连接后的慢速请求体（那是 client_body_timeout 的职责），而是专门控制“客户端在发送完整请求头”阶段的最大等待时间。合理调低该值，可快速识别并中断那些故意拖延、迟迟不发完 GET / HTTP/1.1\r\nHost:... 的扫描连接，显著降低 worker 进程被无效连接占满的风险。
理解 client_header_timeout 的真实作用边界
这个指令仅作用于 TCP 连接建立后、Nginx 收到第一个字节起，到完整解析完 HTTP 请求头（即遇到空行 \r\n\r\n）之间的等待窗口。一旦请求头收齐，该计时立即停止，后续请求体传输、后端转发、响应生成等均不再受其影响。因此：
- 它对正常浏览器、curl 或 Postman 发起的请求几乎无感——现代客户端通常在毫秒级内完成请求头发包；
- 它对 Slowloris 类攻击极其敏感：攻击者只发
GET /就停住，或每 10 秒补一个随机 header 字符，靠超长等待耗尽连接槽； - 它无法防御已成功发完请求头、但后续故意缓慢发送 body 的攻击（需配合
client_body_timeout和client_max_body_size）。
推荐配置值与线上验证方法
默认值为 60 秒，对防御扫描器来说过长。生产环境建议设为 5～15 秒，兼顾兼容性与安全性：
-
保守场景（老旧 IoT 设备、定制客户端较多）：设为
10s； -
标准 Web 服务（含 API）：设为
7s； -
高防需求或已知存在扫描压力：可压至
5s，同时确保error_log级别为warn或更高，便于观察误杀。
验证是否生效：用 telnet your-site.com 80 连接后，只输入 GET / 回车，不发 Host 或空行，等待超时后应看到连接被服务器主动关闭（非客户端超时）。也可用 nginx -t && nginx -s reload 后观察 error.log 中是否出现 client timed out (110: Connection timed out) while reading client request headers 日志条目。
必须配套的关键配置项
单靠 client_header_timeout 不足以构建完整防护，需同步收紧以下参数：
-
client_body_timeout 10s：防止攻击者发完 header 后，用极慢速度传 body 占坑； -
keepalive_timeout 15s：缩短空闲长连接存活时间，避免被复用为扫描通道； -
limit_conn addr 10（配合limit_conn_zone $binary_remote_addr zone=addr:10m）：从 IP 维度硬限并发连接数，直接堵住高频扫描源； -
reset_timedout_connection on：让 Nginx 在超时后主动发送 RST 包断连，比 FIN 更快释放内核连接状态。
警惕误伤与灰度上线策略
过激调低可能影响部分弱网络环境下的合法用户（如高丢包率的移动网络、卫星链路），表现为偶发 408 Request Timeout。上线前务必：
- 先在测试集群或小流量节点开启
error_log /var/log/nginx/timeout_debug.log warn，收集 24 小时超时日志，分析来源 IP 是否集中、User-Agent 是否异常； - 使用
log_format在 access log 中加入$request_time和$upstream_response_time，区分是 header 超时还是后端响应慢； - 首次调整建议从 10s 开始，观察 3 天无异常再降至 7s，避免一步到位引发批量超时投诉。
