http2_max_field_size 默认4kb，超长header导致400错误；http/2需完整读入原始字段再压缩，限制为硬性边界；调大时须结合client_header_buffer_size与large_client_header_buffers协同配置，并端到端验证。
在 HTTP/2 场景下，http2_max_field_size 是控制单个请求头字段长度的关键参数，默认值为 4KB。当应用依赖超长 Cookie、自定义认证 Token（如 JWT）、或携带大量调试信息的 Header 时，容易触发 400 Bad Request 错误——Nginx 拒绝解析超出该限制的字段。
为什么 HTTP/2 下更容易遇到这个问题
HTTP/2 使用 HPACK 头部压缩，但压缩前仍需完整读入原始字段。若某个 Cookie 达到 8KB，而 http2_max_field_size 保持默认 4KB，Nginx 就会在解帧阶段直接中断连接，不进入后续路由或代理逻辑。这和 HTTP/1.x 的 client_header_buffer_size + large_client_header_buffers 分级缓冲机制不同，HTTP/2 的字段大小限制是硬性边界，不可绕过。
如何安全调大 http2_max_field_size
调整需兼顾兼容性与安全性，不建议盲目设为 64K 或更高：
- 先确认真实需求：用
curl -v -H "X-Debug: $(python3 -c 'print(\"A\"*12000)')" https://yoursite.com模拟长字段，观察是否返回 400 - 典型场景参考值：
– 含 Base64 编码 JWT 的 Authorization 头 → 建议设为 8k
– 多段分隔的 tracking Cookie（如广告平台注入）→ 建议设为 12k
– 内部调试系统带全量上下文的 X-Request-Context → 可设为 16k - 必须同步检查 TLS 层：某些旧版 OpenSSL 或负载均衡器（如 ALB）对 HTTP/2 SETTINGS 帧有隐式限制，单独调大 Nginx 参数可能无效，需端到端验证
配合 client_header_buffer_size 和 large_client_header_buffers 使用
虽然 http2_max_field_size 管 HTTP/2 解帧，但 Nginx 在接收原始字节流时仍依赖传统 header 缓冲配置。若超长字段同时导致初始读取失败，会提前报错，跳过 HTTP/2 协议识别：
-
client_header_buffer_size 2k：满足大多数普通请求 -
large_client_header_buffers 4 16k：确保能容纳 16KB 内的任意单字段（含 Cookie），且最多分配 4 组 - 二者需协同：比如设
http2_max_field_size 12k，则large_client_header_buffers的单 buffer 至少 ≥12k，否则字段根本进不到 HTTP/2 解析阶段
验证是否生效
仅看响应状态码不够，要确认协议层真正处理成功：
- Chrome DevTools → Network → 右键表头勾选 Protocol，确认该请求显示
h2 - 抓包验证：Wireshark 过滤
http2.headers，查看对应流中是否完整收到长字段，无FRAME_SIZE_ERROR或连接中断 - Nginx error log 中不应出现
client sent too large header或invalid http2 frame类日志
