client_header_timeout是Nginx控制客户端发送完整HTTP请求头（至空行）的最大等待时间，超时返回408并断连；仅作用于请求头读取阶段，需配合client_body_timeout、keepalive_timeout等协同防护慢速攻击。
client_header_timeout 是 Nginx 中控制客户端发送请求头阶段等待时间的关键参数。它不作用于整个请求，只约束从 TCP 连接建立完成到 Nginx 收到完整请求行和请求头（即 GET / HTTP/1.1 及后续所有 headers）之间的最大时长。调优该值，核心目标是：在保障弱网、移动设备或代理转发等真实场景下正常建连的前提下，快速释放被恶意慢速攻击或异常中断连接长期占用的 worker 进程资源。
理解 client_header_timeout 的实际触发时机
这个超时不是从用户点击开始计，而是从 Nginx 完成三次握手、拿到一个可用 socket 后才启动倒计时。常见触发场景包括：
- 客户端网络极差（如信号断续的 4G 环境），发完 SYN/ACK 后迟迟无法把 GET 行传全
- 中间存在不规范代理（如某些老旧负载均衡器），在转发请求头时人为引入延迟或分片
- 攻击者使用 slowloris 类工具，仅发送部分请求行（如只发
GET /），然后停住不动 - 客户端程序 bug，建立连接后忘记写请求头，或因异常退出导致 socket 半开
合理设置 timeout 值的参考依据
默认值通常为 60 秒，对大多数 Web 服务偏长。调整需兼顾业务特性和基础设施现状：
- 纯内网 API 服务（如 k8s Pod 间调用）：可设为 5–10 秒，因链路稳定、延迟低
- 面向公网的 Web 站点（含移动端）：建议 15–30 秒，覆盖高延迟蜂窝网络与跨运营商链路
- 集成第三方 SDK 或嵌入式设备接入的接口：若已知对方启动慢（如某些 IoT 模组冷启动后才发 HTTP），可临时放宽至 45 秒，但需配合日志监控异常增长
- 不建议低于 5 秒——即便在理想网络下，Linux 协议栈、Nginx 缓冲区拷贝、TLS 握手耗时叠加也可能接近临界值
配合其他参数协同防御慢速攻击
单靠 client_header_timeout 不足以应对完整慢速攻击链，需组合配置：
- client_body_timeout：控制请求体（如 POST 数据）上传超时，应与 header 超时保持同量级，避免 header 过了但 body 卡住
- client_max_body_size：限制最大请求体大小，防止攻击者用超大 payload 消耗内存
- reset_timedout_connection on：开启后，超时时直接发送 RST 包中断连接，比 FIN 更快释放 socket 和相关内核结构
- log_format 中加入 $status 和 $request_length：便于通过日志识别大量 408（Request Timeout）是否集中于某类 User-Agent 或 IP 段
验证与观测要点
调优后务必通过真实链路验证，而非仅本地 curl：
- 用
tcpdump抓包观察三次握手完成到第一个 HTTP 请求行到达的时间差 - 在 access_log 中添加
$request_time和$upstream_response_time，对比分析超时是否真由 header 阶段引发 - 检查 error_log 中是否有频繁出现的
client timed out (110: Connection timed out) while reading client request headers - 若发现合法用户触发超时，优先排查上游代理是否缓存/修改了请求头，而非盲目加长 timeout
