“Request Header Too Large”是Nginx主动拦截恶意请求的保护机制，源于client_header_buffer_size和large_client_header_buffers缓冲区限制，超限即返400；需配合client_header_timeout、client_max_body_size等参数协同防御慢速头攻击与头泛洪。
“Request Header Too Large”不是偶然报错，而是Nginx主动拦截恶意或异常请求的保护行为。它背后反映的是缓冲区溢出风险——攻击者通过构造超长 User-Agent、巨量 Cookie、嵌套的 Authorization 或自定义追踪头（如 traceparent），可能耗尽 worker 进程内存、触发崩溃，甚至为远程代码执行埋下伏笔。
为什么会返回 400 错误？关键看这两个缓冲区配置
Nginx 不是“算错长度”才拒绝，而是严格按内存分配逻辑做判断：
- client_header_buffer_size：每个请求默认只分配一块小缓冲区（如 1k）。普通 GET 请求够用，但带 JWT Token（常 >2KB）或多个域名 Cookie 就容易溢出
-
large_client_header_buffers：当小缓冲装不下时，Nginx 启用备用池。格式是
large_client_header_buffers 4 8k，表示最多用 4 块 8KB 缓冲区 → 总上限 32KB。只要请求头总长超过这个值，立刻返回 400，并在 error.log 记录request header or cookie too large
光调大缓冲区不够，必须配合超时与体大小控制
攻击者可能不拼长度，而拼“慢”——逐字节发头字段，拖住连接不释放。这时仅调大缓冲毫无意义：
-
client_header_timeout：建议设为
5s或10s。超时即断连，防慢速头攻击（Slow HTTP Header Attack） -
client_max_body_size：和头攻击常组合使用（比如伪造超长头+空 body 混淆检测），设为合理值如
10m，避免绕过头限制 -
underscores_in_headers off：禁用下划线，防止某些框架将
X-Api-Key解析为x_api_key引发歧义或绕过校验
网关场景下的特殊考量
当 Nginx 充当 API 网关时，真实风险更高：
- 微服务常用长 JWT、OpenTelemetry 的
tracestate、多级网关追加的X-Forwarded-For链，都推高头体积 - 后端服务响应头也可能过大（如 Spring Cloud Gateway 返回冗余调试头），导致
upstream sent too big header—— 此时要调proxy_buffer_size，而非 client 相关参数 - 若日志中频繁出现 400 且来源集中，建议结合
limit_req限流（如每 IP 每秒 5 次），防头泛洪类 DoS
生产推荐配置（API 网关典型值）
以下配置平衡安全性与兼容性，适用于多数云原生网关部署：
http {
client_header_buffer_size 2k;
large_client_header_buffers 4 8k; # 总上限 32KB
client_max_body_size 10m;
client_header_timeout 10;
underscores_in_headers off;
<pre class='brush:php;toolbar:false;'># 可选增强
limit_req_zone $binary_remote_addr zone=hdr_flood:10m rate=10r/s;
server {
location / {
limit_req zone=hdr_flood burst=20 nodelay;
proxy_pass http://backend;
}
}}
