同一个网址，新用户能打开，老用户却收到 431 或 400；无痕窗口正常，登录一段时间后又开始失败。这类故障值得先查请求头，尤其是浏览器自动携带的 Cookie。接入 CDN 后，请求多经过了一道入口，原来勉强能通过的请求可能在更前面被拒绝。
HTTP 431 表示服务器不愿处理过大的请求头，原因可以是某一个字段，也可以是所有字段合计过大。不同产品不一定都返回 431：例如 Nginx 对超过指定缓冲区大小的单个请求头字段返回 400，对过长请求行返回 414。[1][2] 因此，不能只凭状态码确定故障层级。
本文面向网站与 API 运维，提供排查示例，未在你的生产环境实测。不要把上传文件过大、URL 过长和请求头过大混为一谈，它们可能受不同限制控制。
先确定哪一层拒绝了请求
记录失败时间、域名、路径、状态码和可用的请求 ID，再关联 CDN、负载均衡、反向代理与应用日志。错误页样式、响应头可以提供线索，但可能被代理改写，不能单独作为结论。
若 CDN 记录了请求而源站访问日志没有对应记录，应继续核对边缘拒绝原因、WAF 事件和前置负载均衡日志。源站没有访问日志，也可能是请求在写入常规访问日志之前就被解析器拒绝，需同时查看错误日志。
对比三个受控场景通常更有帮助：同一账号在普通窗口和无痕窗口访问；同一路径在登录前后访问；只携带必要认证信息与携带完整 Cookie 时访问。无痕窗口正常只是线索，扩展程序、代理和账号状态不同也可能影响结果。
不要让用户直接把完整 HAR 或“复制为 curl”的内容发到公开工单。它们可能包含 Cookie、Authorization、个人信息和带签名的 URL。排查记录尽量只保留字段名称、长度与脱敏后的结构。
看单个字段，也看整个请求头
逐项核对当前产品文档：请求头总大小、单字段上限、字段数量、URL 或请求行限制，以及这些值是否可调整。HTTP/2、HTTP/3 的头部压缩不能被当作绕过限制的办法；产品可能按解压后的字段或自身定义的请求大小计数。
CloudFront 的配额文档就分别列出了请求大小和 URL 长度等限制，不能把 Nginx 的配置值套到边缘入口。[3] 最终可通过的请求受整条链路中最先触发的限制约束；只调源站并不能修复已经被 CDN 拦截的请求。
Cookie 值、Bearer 令牌、追踪头和转发链都值得关注。多个应用把大块用户资料写进 Cookie，或把不断增长的权限列表放进 JWT，会让每次访问都背上这笔开销。某一个 Cookie 字段很大时，增加缓冲区数量也未必有用。
Cookie 为什么会越用越大
检查是否把 Cookie 的 Domain 设得过宽，导致多个子域的业务 Cookie 一起发送；再检查 Path 是否覆盖了不需要登录态的静态资源路径。同名 Cookie 若分属不同 Domain 或 Path，也可能同时出现在请求里。
浏览器会按作用域自动发送 Cookie。前端发起请求时，单纯不在 JavaScript 中显式设置 Cookie，并不代表浏览器不会带上它。修改跨源凭证选项还会影响登录逻辑，不能作为通用修复。
常见的长期修复是把会话主体放在服务端，浏览器只保存必要的会话标识；控制令牌声明规模；停止重复写入实验、追踪或历史状态；为不需要认证的资源设计合适的域名和 Cookie 作用域。
清理旧 Cookie 必须匹配其原来的名称、Domain 和 Path，否则浏览器里可能留下旧副本。变更前先列出实际作用域，评估退出登录、跨子域单点登录和灰度回滚的影响。HttpOnly、Secure 和 SameSite 等安全属性不应为了减少字节数而删除。
用不含凭据的请求建立基线
在授权环境中，对一个小型、只读的测试资源执行 GET。以下 Bash 示例不会附带浏览器 Cookie，也不会自动跟随重定向：
curl -sS --max-time 20 \ -D response-headers.txt \ -o response-body.bin \ 'https://example.com/health-check'
请替换成自己有权测试的地址。确认响应是否实际来自预期服务，而不是登录跳转、WAF 页面或应用自己的错误页。使用 GET 是为了避免 HEAD 与 GET 路由行为不同造成误判；不要对生产写接口反复重放请求。
然后在浏览器开发者工具里比较正常与失败请求的头字段。若必须使用带认证的测试请求，使用专用账号和短期凭据，通过受控工具处理，不把真实令牌放进命令历史、脚本仓库或共享日志。诊断响应文件也可能包含敏感内容，需限制访问并及时清理。
不要在生产环境反复放大请求头去寻找精确阈值。需要确认边界时，在预发布环境按小步长测试，限制并发，并记录单字段长度与合计大小；无效请求在认证前也可能消耗资源。
Nginx 调整要区分请求头与请求体
Nginx 的 client_header_buffer_size 与 large_client_header_buffers 用于客户端请求头读取。client_max_body_size 控制请求体，改它通常解决不了 Cookie 过大；proxy_buffer_size 面向上游响应读取，也不是浏览器请求头限制的同义配置。[2]
对确实需要较大请求头的业务，可在预发布环境评估类似配置：
# 示例值，并非所有站点都应采用 # 放在对应的 http 或 server 配置上下文中 client_header_buffer_size 2k; large_client_header_buffers 4 16k;
官方文档说明，请求行不能超过一个大缓冲区；单个请求头字段也不能超过一个大缓冲区。4 16k 不代表任意一个字段都可以达到四个缓冲区合计大小。[2] 同样，不应把这个示例解释成对所有协议、版本和前置服务的统一保证。
修改前备份配置，确认实际生效的虚拟主机、Nginx 版本及前置代理。先进行语法检查，再按部署方式受控重载；容器、托管平台与系统服务的操作方式不同，不要照搬重启命令。
如果边缘限制不可调整，应缩小浏览器请求，而不是持续增加源站缓冲。扩大上限也会扩大异常请求的资源消耗面，需要一起评估并发、连接限制和监控。
转发链异常增长，也会挤占头部空间
Cookie 正常时，继续查 X-Forwarded-For、Forwarded、追踪信息和自定义调试字段。代理回环或重复追加可能让字段越来越长。不要直接清空转发头来“压缩”，否则可能破坏真实访客 IP、审计和访问控制。
应按可信代理边界整理转发规则：公网客户端提交的同名字段不能被无条件信任，每一跳只按既定契约处理。若发现回环，先修复路由，不要用提高请求头上限掩盖它。
验收需要保留老用户场景
修复后至少覆盖已有 Cookie 的用户、新会话、跨子域登录、较大但合法的令牌，以及异常超限请求。合法请求应恢复，异常请求仍应被受控拒绝；同时核对登录态没有串用、静态资源请求没有多带无关 Cookie。
清理 Cookie 可以帮助受影响用户恢复访问，但它不是根因修复。若旧 Cookie 仍会被重复写入，故障会再次出现。灰度阶段关注 400、431、414 的变化、拒绝层级、会话失效率和入口资源消耗，不在监控中记录原始凭据。
出现兼容性问题时，恢复已备份的代理配置与 Cookie 策略；已经删除的客户端 Cookie 通常不能靠服务器配置回滚自动恢复，可能需要重新登录。将这一点写进变更说明，再安排清理操作。
最终应能回答：哪一层先拒绝、超的是单字段还是总量、哪些信息不该随请求发送。把这些问题解决，再决定是否真的需要放大缓冲区。
参考资料
资料核验日期：2026 年 11 月 2 日。产品限制与版本行为以实际使用版本及当前文档为准。
