http2_max_field_size 仅对 http/2 生效，需与 http2_max_header_size 及后端限制协同配置，否则仍触发 431；其默认 4k 不足以容纳超长 cookie（如含 jwt 的 base64 字段），且校验发生在 hpack 压缩前，错误易被误判为连接失败。
http2_max_field_size 不是“调大就能解决 Cookie 超长”的万能开关，它只对 HTTP/2 连接生效，且必须和 http2_max_header_size、后端接收能力协同配置，否则仍会返回 431 或静默断连。
为什么超大 Cookie 在 HTTP/2 下容易触发 431 错误
HTTP/2 使用 HPACK 压缩头部，但压缩前仍需校验原始字段长度。默认 http2_max_field_size 是 4k，而某些 SDK（如老版本 Sentry、Auth0 JS SDK）或自定义鉴权 Header 会把 Base64 编码的 token、加密 payload 直接塞进 Cookie 字段，单个 Cookie 轻松突破 8k —— 此时 Nginx 在解析阶段就拒绝该请求，返回 431 Request Header Fields Too Large。
注意：这个错误和 HTTP/1.1 的 400 Bad Request（由 large_client_header_buffers 触发）不是一回事，日志里也看不到明显报错，浏览器 Network 面板只显示 “Failed” 或 “Canceled”，排查时容易误判为 TLS 握手或超时问题。
如何安全调大 http2_max_field_size
在启用 HTTP/2 的 server 块中直接设置，不要放在 http 或 location 块：
server {
listen 443 ssl http2;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
<pre class="brush:php;toolbar:false;">http2_max_field_size 64k;
http2_max_header_size 128k;
# 其他配置...}
-
http2_max_field_size建议设为64k：覆盖绝大多数含 JWT、加密 session 的 Cookie 场景，同时避免无限制放大带来的 DoS 风险 - 必须同步调大
http2_max_header_size：它控制整个请求头总长，若单个 Cookie 占 60k，但总头限制仍是默认 16k，照样失败 - 该指令仅在
listen ... http2的 server 中生效；HTTP/1.1 请求完全无视它，走的是client_header_buffer_size和large_client_header_buffers - 修改后必须
nginx -t && nginx -s reload，热重载不生效
容易被忽略的后端兼容性陷阱
Nginx 放行了大 Header，不代表后端应用能接住。常见断裂点：
- Node.js Express 默认用
raw-body解析，对超长Cookie字段可能抛RangeError: Invalid string length - Java Spring Boot 的
server.max-http-header-size（Tomcat）或jetty.http.request.header.size（Jetty）仍按 HTTP/1.1 逻辑限制，需显式调大 - Go 的
net/http默认限制MaxHeaderBytes为 1MB，看似宽松，但若启用了反向代理中间件（如gorilla/handlers），它可能自己做了二次校验 - gRPC-Web 客户端通过 Nginx 代理时，
grpc-encoding、grpc-encoding等自定义 Header 也可能撞上http2_max_field_size限制
验证是否真正生效的三步检查法
别只看 Nginx 配置文件有没有写错，要实测链路：
- 用
curl -v -H "Cookie: verylong=xxx..." https://yoursite.com发送一个构造好的超长 Cookie 请求，观察响应状态码和Connection头是否保持 alive - 在 Nginx error log 中加
error_log /var/log/nginx/error.log debug;，搜索http2 frame或header field too large关键字，确认拦截点是否消失 - 用 Chrome DevTools 的 Network → Headers 面板，检查请求是否真走 HTTP/2（Protocol 列显示
h2），避免因 ALPN 协商失败退化到 HTTP/1.1 导致配置白设
最麻烦的不是调参本身，而是 HTTP/2 的头部校验发生在连接早期、无明确上下文，一旦出错，连 access_log 都可能没记录 —— 所以验证环节不能跳过，也不能只信后端日志。
