一个容易被忽略的事实：请求头不是免费的。它跟着每一个请求走一遍代理IP链路，每一跳都要被解析、处理、重新生成。头部长了，这套动作的成本就跟着涨。
单看一次请求，多几十个字节根本感觉不到。但放到批量任务上，一天几十万次请求，每一笔都多带几十字节，累积出来的流量和耗时就不容忽视了。
头是怎么一点点变长的
变长的第一个来源是追加。前面说过，代理IP转发时会在头部添几行说明，标注原始出口、标注第几跳。单级转发添一两行，多级转发每跳都添，链路一长，这几行就能堆成一小段。
第二个来源是累积。有些字段不是被覆盖，而是被不停往后面追加新值。每经过一跳就在原来的值后面补一段，跳数越多这串值越长。到终点时，原本短短一个字段可能已经变成一长串。
第三个来源是业务自己。追踪标识、来源标记、任务批次号，这些自定义字段加的时候很顺手，加着加着头部就比请求体还长。这种情况在对接了多个系统的业务里相当常见。
三个来源叠在一起，一个原本几百字节的头部，跑到链路末端时翻上几倍并不稀奇。
需要说明的是，头变长不等于出错。多数时候它只是悄悄变长，直到某一天碰到限制才暴露出来。
长度限制卡在哪一环
限制不是某一环独有的。客户端、中间的代理IP转发环节、目标站的接入层，各自都有自己的上限。三者里最小的那个，才是你真正的天花板。
常见误区是只盯着目标站。实际上中间环节的限制往往更严格——它们要同时服务大量请求，对单请求的资源占用控制得更紧。头部超了，中间环节会直接拒绝，请求根本到不了目标站。
被拒绝时的表现也很有迷惑性。多数情况下返回的是一个含义笼统的错误，看起来像服务端出了问题，实际是头部太长被拦。不了解这一层的人，容易把排查方向带偏。
另一种表现更隐蔽：不报错，但明显变慢。头部越大，每一跳解析和重建的耗时越长，请求数一上来，这部分开销就会被放大成可感知的延迟。
- 先量一量实际长度：抓一个真实请求，把头部完整复制出来数一数字节，别凭感觉判断
- 找出重复和冗余：同类字段重复出现、业务标识堆叠、过期标记没清理，这三类最常见
- 把能搬走的信息搬走：标识类信息放请求体或者查询参数，头部只留必须让中间环节读到的
- 检查链路跳数：每多一跳就多一批追加，能减少环节就减少，不能减少就定期清理累积值
- 给头设个上限：在业务侧做长度检查，超过阈值就告警，别等到被中间环节拒绝才发现
先把长度量出来：多数时候量完就知道问题出在哪，后面几步不必一次做完，代理IP链路上的头部问题往往一量就现形。
代理IP服务商这一侧也值得问一句：转发时会不会对头部长度做限制，会不会清理累积值。同样长的头部，在不同服务商的代理IP链路上，命运可能完全不同。
还有个省事的做法：定期清理业务侧自己加的字段。很多字段是某次对接时加的，对接早已下线，字段还跟着每个请求跑。清掉它们，头部能短一大截，而且没有任何副作用。
把头部当成要计费的资源来管理，代理IP出口这一层的很多问题就不会发生了。
头部管顺之后，收益是实实在在的：批量任务的耗时降下来，被中间环节莫名拒绝的情况减少，链路的可预期性也明显提高。对依赖代理IP链路跑业务的团队来说，这笔账值得提前算。