431错误主因是HTTP/2下http2_max_field_size默认4KB限制被超长Cookie或Header突破，需同步调大http2_max_field_size（如16k）和http2_max_header_size（如64k），并检查Nginx配置生效位置、后端服务及CDN限制。
直接结论：当你的应用在 HTTP/2 下返回 431 Request Header Fields Too Large，或客户端连接被静默中断，大概率是 http2_max_field_size 挡住了超长 Cookie（比如含大量权限信息的 JWT）、自定义追踪 Header 或拼接式 Session 字段。它不是“可选优化项”，而是生产环境启用 HTTP/2 后必须校准的基础安全阈值。
为什么默认 4k 会出问题？
HTTP/2 压缩头部（HPACK）对单个字段长度有硬限制，默认 http2_max_field_size 4k。但现代前端框架 + SSO + 全链路追踪常导致单个 Cookie 轻松突破 8–16KB（尤其含未压缩 JWT payload）。此时 Nginx 在解帧阶段直接拒绝，不进日志、不转发、不报错——只断连。
- 现象：Chrome DevTools Network 标签页里请求状态为
(failed)或(canceled)，协议列为h2，但看不到响应码 - 验证方式：用
curl -v --http2 https://your.site/观察是否卡在 CONNECT 阶段，或返回HTTP/2 stream 1 was not closed cleanly - 注意：
client_header_buffer_size和large_client_header_buffers对 HTTP/2 无效，它们只管 HTTP/1.x
怎么设才安全又不过度放水？
不能无脑调大。HPACK 解压本身有 CPU 开销，且过大的单字段可能掩盖真实攻击（如恶意构造的超长 X-Forwarded-For）。建议按实际 token 结构测试后保守设定：
- 先抓取真实生产环境带完整 Cookie 的请求头（用浏览器开发者工具 → Copy as cURL），用
curl -H "Cookie: $(cat cookie.txt)" --http2 https://your.site/health复现 - 从
8k起步，逐步试到能通为止；多数 JWT 场景16k足够，极少需要超过32k - 必须同步调整
http2_max_header_size（总头大小），否则单字段达标但总长超限仍失败；常见配对是：http2_max_field_size 16k; http2_max_header_size 64k; - 若你用的是 Nginx ≥1.29.8，还要检查
max_headers（默认 1000 行），防“小 header 堆积”绕过单字段限制
容易被忽略的关联点
改完配置 ≠ 问题消失。以下三点漏掉任一，都可能白调：
-
nginx -t && nginx -s reload后，务必查error.log是否仍有http2 header field too large类报错（注意：它不会出现在 access.log） - 后端服务自身也有 header 限制：Node.js 需加
--max-http-header-size=32768；Java Spring Boot 默认 8KB，需改server.max-http-header-size；FastAPI/Uvicorn 默认不限，但若直连而非走 Nginx，仍可能被底层 ASGI server 拦截 - CDN 或前置 LB（如 AWS ALB、Cloudflare）可能有自己的 header 限制，且优先于 Nginx 生效——得确认它们也开了 HTTP/2 并调高对应参数
最麻烦的情况不是参数设小了，而是设大了却没生效：比如写在 http 块里，但实际流量走的是某个未覆盖的 server 块；或者用了 include 引入配置，但新指令被后面同名旧配置覆盖。真要排查，就用 nginx -T | grep http2_max_field_size 看最终生效位置。
