1. 题目与适用场景
登录后页面经 CDN、负载均衡和服务网格访问 API，部分用户收到 431 Request Header Fields Too Large；无痕窗口和 curl 正常。请说明 431 的语义、逐层定位方法、修复策略和上线验证。假设请求可能使用 HTTP/1.1 或 HTTP/2，且日志不能记录完整 Cookie 或 Authorization。
2. 面试官考察点
- 是否区分总请求头过大与单个字段过大，并知道 431 属于请求处理前的客户端错误。
- 是否能沿 CDN、网关、代理到应用逐层测量，而不是只修改应用服务器配置。
- 是否识别 Cookie 膨胀、重复 Set-Cookie、超长令牌和转发头为主要来源。
- 是否会在保留安全性的前提下压缩状态、轮换凭据并建立大小监控。
3. 回答前需要澄清的问题
- 431 是哪一跳生成的？响应头、服务器标识和边缘日志能否定位节点？
- 失败请求的请求头总字节数、最大字段和协议版本分别是多少？
- 浏览器是否携带多个旧 Cookie、跨子域 Cookie 或不断增长的会话数据？
- 各层限制是总头块、单字段、请求行还是缓冲区，是否存在 HTTP/2 解码限制？
4. 30 秒回答框架
431 表示服务器拒绝处理请求，因为请求头总量或某个字段超过了允许范围；RFC 6585 不规定固定字节上限。先从客户端、边缘、网关、代理到应用记录脱敏后的总量和最大字段，找出首次返回 431 的层。浏览器独有时优先检查 Cookie、重复 Set-Cookie 和 Authorization，而不是先调大上限。修复应减少客户端状态、缩短或改为服务端会话引用，清理旧 Cookie，并让所有层的预算一致；调大限制只作为经过容量和 DoS 评估的短期措施。
5. 分步骤深入解答
第一步：确认状态码和生成位置
记录请求经过的节点、协议、响应头和关联 ID。用最小复现请求分别直连源站、绕过 CDN、经过网关和使用浏览器导出的脱敏头部，比较首次出现 431 的位置。某些代理使用 400 或厂商自定义 494 表达同类限制，因此不能只依赖状态码；要结合节点日志和配置确认拒绝原因。
第二步：按字节测量头部
对每个字段计算编码后的字节数，并同时记录总请求头、请求行、最大单字段和字段数量。不要把字符数当作字节数，也不要把压缩后的 HTTP/2 头块大小等同于解码后的字段总量。日志只保留字段名、长度、哈希前缀和请求 ID，禁止记录 Cookie 值、Bearer 令牌或完整 Referer。
第三步：定位浏览器特有来源
Cookie 通常是首要嫌疑：多个路径或子域设置同名 Cookie、把用户资料放进 Cookie、每次响应追加新版本，都会让后续请求持续膨胀。检查 Set-Cookie 的 Domain、Path、过期时间和删除逻辑；确认旧名称真的被过期，而不是只覆盖当前路径。Authorization 令牌应保持短小，刷新令牌放在受控的服务端会话或安全存储中，不要把可变业务数据塞进令牌。
第四步：处理代理链和 HTTP/2
每一层可能有不同的总量、单字段和缓冲区限制，转发时还会新增 X-Forwarded-*、追踪和认证头。把预算写成配置契约，并用最小值作为客户端设计上限。HTTP/2 使用 HPACK 压缩传输，但端点仍需解码头字段并执行限制；不要用压缩率证明业务头部安全。若网关拒绝而应用未收到请求，应在网关指标中报警。
第五步：选择修复与防御
优先删除重复 Cookie、缩小会话内容、把状态移到服务端并只传不可猜的短引用。对令牌设置最大长度、轮换和撤销策略；对未知或异常大的自定义头直接拒绝。只有在确认内存、连接并发和解析成本后才提高限制，并为不同租户或路由设置合理预算，避免把 DoS 面扩大。
6. 高质量示范回答
我会先找出返回 431 的第一跳，再对失败请求做脱敏测量：总头字节数、最大字段、请求行、字段数量和 HTTP 版本。浏览器正常而 curl 正常，优先检查重复或跨子域 Cookie、膨胀的会话数据和 Authorization 长度；不能只调大应用服务器上限，因为 CDN、负载均衡或服务网格可能更早拒绝。修复包括删除旧 Cookie、缩小客户端状态、改用服务端会话引用和统一各层预算。HTTP/2 的压缩传输不等于解码后没有限制。上线后监控按节点和字段名聚合的大小分位数，日志只保留长度和哈希前缀，不记录凭据。
7. 常见错误
- 只清浏览器 Cookie： 可能暂时恢复，但没有修复重复
Set-Cookie的根因；应追踪设置者、Domain、Path 和过期逻辑。 - 把 431 当成固定 8 KB： RFC 没有规定统一上限；应读取每层实际配置并按字节测量。
- 只提高源站限制： CDN 或网关仍可能先拒绝，且解析成本和 DoS 风险上升；应先统一预算和容量评估。
- 记录完整请求头排查： 会泄露 Cookie 和令牌；只记录字段名、长度、哈希前缀和关联 ID。
- 认为 HTTP/2 压缩消除了限制： 端点仍要解码字段并执行限制；应分别测试压缩传输和解码后的大小。
8. 追问及应对
追问一：为什么 curl 正常而浏览器失败？
浏览器会自动携带该域名匹配的全部 Cookie、认证和追踪头；curl 的请求通常更小。导出浏览器请求后逐个删除字段做二分实验，再在每一跳测量，能区分客户端来源和代理限制。
追问二：能否把 JWT 放进 Cookie？
可以，但每次请求都会承担令牌字节成本，且多个 Cookie 叠加可能触发限制。只放短引用或最小声明，把可变资料和撤销状态放在服务端，并设置长度预算和轮换策略。
追问三：什么时候可以调大上限？
只有在确认业务确实需要、所有层都能承受解析内存和并发成本，并完成容量、超时和 DoS 测试后才调整。发布时同时保留大小监控、限流和回滚配置，不能把上限提升当作唯一修复。