nginx处理超大header需同时配置client_header_buffer_size和large_client_header_buffers，仅调前者无效；因单个header字段必须完整存入一个buffer，不可跨buffer拼接，且large_client_header_buffers的size是单buffer上限而非总和。
直接说结论：Nginx 处理超大 Header 不是调一个参数就能解决的事，必须同时配好 client_header_buffer_size 和 large_client_header_buffers，否则 400 或 414 错误会照常出现。
为什么只改 client_header_buffer_size 不行
Nginx 默认用 client_header_buffer_size（默认 1k）缓存请求头，但它只用于「常规大小」的请求。一旦请求行（比如 GET /xxx?aaa=...&bbb=...）或某个 Header 字段（比如 Authorization: Bearer xxxxx...、Cookie: a=1; b=2; ...）超出这个值，Nginx 就会放弃它，转而尝试从 large_client_header_buffers 分配新缓冲区——但前提是后者已配置且单个 buffer 足够大。
常见错误现象：
- 只把
client_header_buffer_size改成8k，但没动large_client_header_buffers，结果仍返回400 Bad Request - 日志里看到
"client sent too large request"或"excess request headers"，却误以为是 body 大小问题，去调client_max_body_size（这完全无关）
large_client_header_buffers 的 size 是单个 buffer 上限，不是总和
large_client_header_buffers 4 8k 的意思是：最多分配 4 个缓冲区，每个最大 8k；但关键限制是——单个请求行或单个 Header 字段必须能塞进一个 buffer 里。Nginx 不会拼接多个 buffer 来存一个字段。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
所以如果某条 Cookie 值长达 12k，哪怕你配了 large_client_header_buffers 10 8k，照样报 400，因为 12k > 8k。
实操建议：
- 先用
ngrep抓真实流量看 Header 长度分布：ngrep -W byline 'GET /' 'tcp and dst port 80' | awk -v RS='#+' -v FS='\n' '{print length()}' | sort -n | tail -5 - 若发现最大单字段接近 6k，就设
large_client_header_buffers 4 8k；若接近 14k，就得设16k，不能只堆number -
client_header_buffer_size建议设为常见请求头的 95 分位长度（比如 2k），避免小请求也触发大 buffer 分配
容易被忽略的配套检查项
光调缓冲区还不够，下面三个点不顺带处理，问题还会反复出现：
-
client_header_timeout：默认 60s，但如果缓冲区变大、客户端网络慢，可能在读完 header 前就超时断连，建议同步微调到120（单位秒） - 确认配置生效范围：这两个指令支持
http、server、location三级，但生产环境强烈建议只在http块统一配，避免某 virtual host 漏配 - reload 前必须
nginx -t：语法错会导致 reload 失败，而 Nginx 不会主动提示是哪个 buffer 参数写错了；典型错误如写成large_client_header_buffers 4k（漏了数字）或单位用错（8K大写 K 会失败）
真正麻烦的不是参数本身，而是 Header 超长往往来自前端 SDK 自动注入、网关透传、或老旧 WAP 客户端——它们不会告诉你发了多大的头。所以别指望一次配完就一劳永逸，得结合 $request_length 日志字段长期观察，再动态调整。
