502错误需在location块设proxy_buffer_size，400/414错误才在http块配client_header_buffer_size和large_client_header_buffers；HTTP/2还需server块中设http2_max_header_size与http2_max_field_size。
处理后端返回超长 Header 导致的 502 错误，关键不在 http 块里直接配 proxy_buffer_size——它**不允许出现在 http 块顶层**，必须放在 server 或 location 块中生效。但 http 块确实要承担另一类关键缓冲配置：针对客户端发来的超长请求头（比如含巨量 Cookie 或长 JWT 的请求），防止出现 400、414 等错误。
先分清方向：是响应头还是请求头？
后端返回的 Header 属于「响应头」，由反向代理链路中的 proxy_buffer_size 控制；而客户端发起的请求头（如浏览器带的 Cookie、Authorization）属于「请求头」，由 client_header_buffer_size 和 large_client_header_buffers 控制。两者完全独立，不能混用。
- 如果你看到 502 Bad Gateway + 日志提示 "upstream sent too big header" → 是后端响应头太长 → 需在
location中设proxy_buffer_size - 如果你看到 400 Bad Request + 日志提示 "client sent too large header" 或 "request header or cookie too large" → 是客户端请求头太长 → 才该动 http 块
http 块必须配的两个请求头缓冲参数
若确认问题是客户端请求头过大（例如单条 Cookie 超过默认 1k），需在 nginx.conf 的 http { ... } 块内靠前位置添加：
-
client_header_buffer_size 8k;：设初始缓冲区为 8KB，能覆盖绝大多数含 Token 或多域 Cookie 的合法请求 -
large_client_header_buffers 4 16k;：当首缓冲不够时，最多启用 4 个 16KB 缓冲区；注意单行请求头（如整条 Cookie 行）不能超过 16KB，否则仍会报 400 或 414
这两项必须同时设置，且语法严格：number size，不能写成 16k; 单值，否则 nginx -t 直接失败。
Nginx是一款高性能的开源软件，由俄罗斯开发者Igor Sysoev于2004年创建。它最初设计为高效的HTTP Web服务器，现已成为最受欢迎的Web服务器之一。Nginx以事件驱动、非阻塞I/O架构著称，能以极低内存占用处理数万并发连接，特别适合高流量场景。它同时担任反向代理、负载均衡器、HTTP缓存、TCP/UDP代理等多重角色，常用于静态文件服务、SSL终止、请求转发、API网关和微服务
HTTP/2 场景下还需额外配置
如果启用了 HTTPS + HTTP/2（如通过 Let’s Encrypt 自动配置），上面两个参数对请求头无效。HTTP/2 使用 HPACK 压缩，有自己的头部限制：
- 在带
http2标志的server块中（如listen 443 ssl http2;），添加：http2_max_header_size 32k;（控制整个请求头解压后总长）http2_max_field_size 8k;（控制单个字段，如单个 Cookie 或 Authorization 解压后长度） - 这两行不能放在
location或if块里，否则静默不生效
别漏掉 proxy 场景的协同配置
即使你在 http 块调大了请求头缓冲，若 Nginx 同时作为反向代理（比如把请求转给 PHP-FPM 或 Java 微服务），后端返回的响应头仍可能触发 502。此时必须在对应 location 块中补充：
-
proxy_buffer_size 16k;（核心，必须 ≥ 后端最长单行响应头，如一条 Set-Cookie） -
proxy_buffers 8 16k;（响应体缓冲，size 建议与 proxy_buffer_size 对齐） -
proxy_busy_buffers_size 32k;（建议为 proxy_buffers 总大小的一半以上）
所有修改后，务必执行 nginx -t && nginx -s reload 生效，不要用 restart。
