请求头太长被服务端直接拒绝时，先收 Cookie 还是先收自定义头

请求头太长被服务端直接拒绝时，先收 Cookie 还是先收自定义头？先归因、再收量：第一步要分清服务端拒绝的是请求头总量超标还是单个字段超标，这两种情况对应同一种客户端错误状态码 431；归因之后，收量顺序一般是先收 Cookie 这类最容易膨胀的字段，再看自定义头与网关追加项，因为在多数场景里 Cookie 是体积涨得最快、又最容易安全缩减的部分。

服务端拒绝时返回的是什么？

按 MDN 的定义，431 这个状态码表示服务端拒绝处理请求，原因是请求的 HTTP 头过长，缩小请求头体积之后可以重发。这个状态码有两种用法：请求头总量过大，或者单个头字段过大。MDN 建议服务端在响应体里说明属于哪一种，理想情况下还应指出哪些头过大，这样客户端才知道该清 Cookie 还是该让调用方改代码。如果响应体只有一句”请求头过大”，排查成本就全部压到了客户端一侧。

请求头为什么会越涨越大？

常见来源有三类。一是跟踪类 Cookie：广告与统计组件不断往 Cookie 里写标识，多次访问累积下来，单域 Cookie 可能膨胀到相当可观的体积。二是第三方脚本追加的自定义头：埋点、实验平台、链路追踪各自要加字段，叠加起来总量就上去了。三是代理与网关的追加：转发链上每经过一层都可能加转接头。三类来源日常都无感，只有当某个用户带着大 Cookie 撞上限制时才集中暴露，而且往往表现为”同一个接口，有的用户正常有的报错”。

排查顺序应该怎么排？

先归因：让服务端把错误响应的响应体写清楚是总量还是单字段超标，这一步决定后面找谁改。再复现：从出问题的用户环境里导出请求头，与正常用户请求同一路径的头做对比，多出来的部分就是膨胀源。然后收量：总量超标先清 Cookie，尤其是跟踪类字段；单字段超标直接处理那个字段，拆分或者缩短。收完观察一段时间，确认不再复发，再把改动固化到配置或代码里。

为什么先收 Cookie？

Cookie 有三个特点让它排在收量顺序的最前面：它由浏览器在每次请求里自动携带，用户自己感知不到也清理不动；它常年累积，写入组件早已下线而遗留字段还在；它的缩减动作完全在服务端可控，下发更短的 Cookie、拆分域、设置合理有效期即可见效。自定义头则不同，改它要协调写入手一个一个来，周期长。所以先收 Cookie 是成本最低的路径，不是因为自定义头不重要，而是因为改起来最快、影响面最清楚。

常见问题

问：431 和 413 有什么区别？ 答：413 针对请求体过大，431 针对请求头过长；文件上传报错看前者，带大量 Cookie 的接口报错看后者。

问：用户侧临时怎么自救？ 答：清掉对应站点的 Cookie 后重试即可恢复访问；但根因通常是服务端写入的 Cookie 过多，清理只是临时缓解。

问：网关层的头大小限制能直接调大吗？ 答：可以调，但只建议作为缓冲。头体积持续增长说明有组件在往头里塞东西，先归因收量，再谈调整限额。