同一网站在无痕窗口能打开，常用浏览器却返回431；删除该站点Cookie后恢复。这个现象通常与请求头累积有关，但“让用户清Cookie”只是应急动作，重复设置、作用域过宽或令牌设计没有修复，问题还会回来。
431表示什么
HTTP 431 Request Header Fields Too Large表示服务器不愿处理过大的请求头。可能是某一个字段特别长，也可能是全部请求头总量超过限制。它与413请求体过大、414 URL过长不是同一个问题。
哪些头最容易膨胀
| 字段 | 膨胀原因 | 风险 |
|---|---|---|
| Cookie | 重复会话、追踪值、旧版本未清理 | 每次请求都携带，持续增加带宽 |
| Authorization | JWT声明过多或令牌链过长 | 敏感凭据暴露面增大 |
| X-Forwarded-For | 多层代理重复追加或循环 | 日志和真实IP判断失真 |
| 自定义头 | 上下文、权限或调试数据塞入头中 | 代理兼容性与泄露风险 |
为什么无痕窗口常能打开
无痕窗口没有旧Cookie，发送的请求头更小。它是很好的对照证据，但不能证明浏览器损坏。应导出正常与故障请求的头名称和长度对比，值本身要脱敏，尤其不能把完整会话Cookie或Authorization粘到工单。
Cookie作用域决定发送范围
Domain设置过宽会让多个子域都收到Cookie，Path设为根路径会随几乎所有请求发送。旧Cookie若名称相同但Path或Domain不同，浏览器可能同时携带。应用迁移域名或登录系统后，应明确删除旧作用域，而不是只覆盖一个新值。
多层限制为何表现不一致
CDN、WAF、负载均衡、Nginx和应用服务器各自有请求头限制。外层允许、内层拒绝时，错误页可能由反向代理生成；不同节点配置不一致还会造成随机431。检查每层总量、单字段和请求行限制，并统一到有明确余量的范围。
调大缓冲区的代价
更大请求头缓冲会增加并发连接的内存压力，也可能放大Header Bomb类滥用。合理业务确实需要时可小幅调整，但同时应限制请求速率、总头大小和异常字段，并删除不应进入每次请求的数据。
JWT为什么不宜无限塞声明
把完整用户资料、菜单、多个角色和长权限列表都放入JWT，会让Authorization快速增长。令牌还会出现在每个API请求中。更适合保留必要标识、发行方、受众与有限授权信息，动态权限在服务端或受控缓存查询。
X-Forwarded-For循环怎样发生
代理既保留客户端传来的XFF，又错误地把整条链重复追加，经过内部重试或回环后头部越来越长。只信任已知代理来源，进入边界时清理外部伪造头，再按规范追加。真实IP信任链可参考多层代理的Forwarded与X-Forwarded-For。
清理Cookie要注意什么
应提供只清理本站数据的操作，避免要求用户删除所有浏览器数据。服务端可通过Set-Cookie给出相同Domain和Path并设置过期时间来删除旧Cookie。登录Cookie失效会让用户退出，应提前说明并避免影响其他子域。
排查顺序
- 用无痕窗口和新浏览器配置做对照；
- 统计请求行、单个头和所有头的字节数；
- 识别Cookie、JWT、转发头或自定义头的主要贡献；
- 定位实际返回431的CDN、代理或应用节点；
- 修复重复写入与过宽作用域，再合理调整上限；
- 验证长时间登录、子域跳转和多层代理不会再次累积。
结论
HTTP 431通常是请求头设计或代理边界长期累积后的结果。清Cookie可恢复用户访问，但真正修复要落在Cookie作用域、令牌内容、可信转发头和各层限制的一致性上。
