client_header_timeout是Nginx限制客户端发送完整HTTP请求头（至空行）的最大等待时间，超时返回408并断连；仅作用于请求头读取阶段，需配合client_body_timeout、keepalive_timeout等协同防护慢速攻击。

client_header_timeout 是 Nginx 中控制客户端发送 HTTP 请求头所允许的最长时间。若客户端在该时间内未完成请求行和全部请求头的发送，Nginx 会主动关闭连接，并返回 408 Request Timeout。合理调优这个值，能在保障兼容性的同时避免资源被慢速客户端长期占用。

理解 client_header_timeout 的作用范围

它仅影响请求头（request headers）的读取阶段，不包含请求体（如 POST body）、响应生成或后端转发过程。典型触发场景包括：

• 移动端弱网下 TCP 握手成功但首字节延迟到达
• 恶意客户端只发部分请求头后停滞（slowloris 类攻击）
• 代理或 SDK 实现异常，未按规范及时发送完整 header

默认值通常为 60 秒，对多数 Web 服务偏长；内网或 API 网关场景可降至 5–10 秒；面向公网的 HTML 页面建议保留 15–30 秒以兼容老旧设备或复杂中间链路。

结合实际流量调整阈值

先观察真实请求头传输耗时，再决策是否下调：

• 用 nginx -V 2>&1 | grep -o with-http-realip-module 确认模块可用后，在 log_format 中加入 $request_time 和 $upstream_connect_time 辅助定位
• 临时开启 debug 日志（error_log /path/to/debug.log debug;），过滤 "client timed out" "while reading client request headers" 关键字，确认是否真有超时发生
• 若日志中该错误极少且对应 IP 可信，说明当前值已足够；若高频出现且集中在某类客户端（如特定 App 版本），需优先排查客户端行为而非盲目调大

配合其他超时参数协同优化

单独调整 client_header_timeout 效果有限，需与关联参数保持逻辑一致：

• client_body_timeout：应 ≥ client_header_timeout，否则可能在头未读完时就因体超时中断（尤其含 Expect: 100-continue 的请求）
• send_timeout：控制响应发送间隔，一般设为 10–30 秒，避免长连接空等
• keepalive_timeout：建议略大于 client_header_timeout（如设为 75 秒），防止客户端复用连接时刚发完头就被断开

例如：设置 client_header_timeout 15s; 时，可同步设 client_body_timeout 20s;、keepalive_timeout 75s;。

灰度验证与回滚机制

变更后必须验证兼容性，尤其是第三方系统集成：

• 用 curl 模拟慢头：启动 nc 监听端口，手动分段发送 GET / HTTP/1.1 + Host + 换行，延迟几秒再补剩余 header，测试是否按预期 15 秒断连
• 检查监控中 408 状态码突增、上游 5xx 是否同步上升（可能因客户端重试引发雪崩）
• 配置文件中用注释标明调整原因与生效时间，便于快速回退：# [2024-06] reduce from 60s to 15s, after checking mobile SDK v2.3+ stable