接口调试时偶尔会碰到一种怪问题：明明请求体不大，服务器却回 413 或 431，翻来覆去找不到原因。其实卡点很可能不在服务器，而在你和服务器之间的代理上——HTTP 头的大小，是这条链路上每个环节都可能设限的地方。
头大小限制卡在哪一环
HTTP 头承载了 User-Agent、Cookie、Authorization、自定义业务字段等信息。客户端、代理、服务器对头的大小各有容忍上限，任何一个环节超限，请求就会被拦下。多数时候问题发生在代理上：它既要解析转发你的头，又要附加自己的头（如 X-Forwarded-For），留给业务的余量就变小了。
| 环节 | 常见上限 | 超限表现 |
|---|---|---|
| 客户端/浏览器 | 随实现不同 | 请求直接发不出去 |
| 代理 | 多为 8KB-16KB | 回 431 或 502 |
| 目标服务器 | Nginx 默认 8KB | 回 431 或 413 |
413 和 431 怎么区分
413 Request Entity Too Large 表示”请求体太大”，通常和上传文件、超长 Body 有关；431 Request Header Fields Too Large 专指”请求头太大”。看到 431 时，优先怀疑头字段超限；看到 413 时，先看是代理拒绝还是服务器拒绝，两者处理方式不同。
排查按这个顺序来
- 先直连对比：不走代理直接请求，若正常则问题在代理侧
- 精简头字段：去掉冗余 Cookie 和自定义头，看是否恢复
- 压缩大字段：把大的业务数据放进请求体或压缩传输
- 换通道验证：换一个对头限制更宽松的代理服务对比测试
代理不只是”转发一下”，它要先读懂你的头，才有资格决定要不要转发。
与 IP 代理的关系：代理服务的头大小限制直接影响业务请求能否完整送达，选择头处理完善、限制明确的服务，能减少”莫名其妙 431″这类问题；理解这条链路上的限制分布，也是用好代理出口的基本功。所有使用都应遵循平台规则与法律法规，用于正当业务目的。