登录后出现431或请求头过大：怎样定位Cookie与代理限制

游客能打开网站，登录后却出现431或“请求头过大”，通常需要先比较登录前后的请求内容。清除浏览器数据可能让症状暂时消失，但如果应用继续累积Cookie，问题仍会回来。排查目标是找出增长来源以及实际拒绝请求的组件。

状态码能说明什么

RFC 6585定义431为请求头过大，既可能是总量问题，也可能是某一个字段过大；规范同时要求该响应不被缓存。不同组件不一定都使用431，所以还应结合错误页面和日志确认原因。

不要从“接入CDN后才出现”直接推断边缘有故障。新增代理层可能暴露原有的超大请求头，也可能存在头部重复追加或各跳限制不一致，需要逐项验证。

采集大小和字段名，不采集会话秘密

使用测试账号，保存字段名称、长度和必要的脱敏特征即可。不要把完整Cookie、Authorization或浏览器导出的含凭据记录发到公开工单；单纯把中间几位打码，也未必足够消除风险。

确定拒绝发生在哪一跳

记录时间、请求标识、返回状态及错误页面特征，再查边缘、反向代理和应用记录。若源站完全没有收到该请求，应继续查上游连接与规则；若源站记录明确拒绝，则检查源站限制及实际收到的头部。

代理可能增加转发信息，应用实际收到的大小不一定等于浏览器最初发送的大小。多级代理重复追加字段时，需要核对每一跳的职责，不能仅把最外层的限制调大。

优先修复增长原因

检查是否把大量业务状态放进Cookie、是否反复创建新名称的Cookie，以及历史功能下线后是否留下旧状态。应用可以考虑将不适合客户端携带的大状态保存在受控服务端，并用必要的短标识关联，但仍需设计过期、权限和故障处理。

调整请求头限制前，先确认业务确实需要这个大小，并评估内存和并发影响。各跳都应有明确边界；无限放大限制既不能解释异常增长，也可能增加资源压力。

修复后的验证不能只测一个干净浏览器

准备一个新会话和一个带历史状态的测试会话，重复登录、浏览关键功能与退出，观察字段是否稳定。检查受控清理是否影响必要偏好或登录状态，并提供可理解的用户恢复说明。

最后确认错误响应没有进入共享缓存，正常页面也没有因临时排障规则而放宽访问限制。若问题涉及多级SCDN与源站代理，可结合可信代理链检查整理路径，把每跳的字段变化和限制提交给支持团队。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。