很多人以为，字段是自己加的、名字是自己起的，自然想带什么就带什么，一路带到目标站不成问题。实际用代理IP转发起来才发现，有些自定义头到了对面踪影全无，有些则被改得面目全非。
误区出在对「自定义」三个字的理解上。自定义指的是字段名不由标准规定，不代表转发环节必须对它们网开一面。代理IP转发请求时，对这类字段的处理有自己的一套判断。
自定义头到底指什么
HTTP 协议留了一个口子：字段名以 X- 开头的属于私有扩展，谁都可以定义，用来传递业务自己的标识信息。后来这个约定放宽了，不少不带 X- 前缀的业务字段也被归入这一类。
它们的共同点是标准不规定含义，收发双方自己约定。代理IP请求头里出现这类字段，通常是业务用来标记来源、传递追踪标识，或者告诉后端这次请求属于哪个任务批次。
为什么有的能过去，有的过不去
关键在代理的处理策略。按默认行为，不认识的字段一般原样带过去——代理没有理由去动一个它看不懂的字段。这是大多数情况下自定义头能顺利抵达的原因。
但有三种情况会改变结果。第一种是字段被列入了逐跳名单，代理按规则摘掉。第二种是代理启用了字段白名单或者精简策略，只放行它认可的字段，其余一律去掉。第三种是字段本身触发了长度或者字符限制，在转发时被截断。
还有一种容易忽略的情况：多级链路。每一跳都按自己的策略处理一遍，第一跳放行的字段，第二跳未必放行。代理IP链路上环节越多，自定义头半路消失的概率越高。
怎么确认自己的字段有没有到
最直接的办法是让目标站回显。找一个能返回请求头内容的回显地址，带上有问题的字段发一次请求，看返回的清单里有没有它。一次对比就能定位是发出去的环节没带，还是中间被摘了。
第二个办法是分段对比。先直连发一次确认字段确实发出去了，再走代理发一次对比差异。差异出在中间的哪一跳，就逐跳验证。代理IP配置支持多级时，这个办法最省事。
第三个办法是看代理侧的日志。多数代理IP服务商会记录转发前后的头部变化，拿到日志直接对比，比在外面猜要准得多。日志拿不到时，回显法依然是最可靠的兜底。
要用自定义头，怎么安排更稳
字段值尽量短。头部是每跳都要重新处理的东西，值越长越容易在某一环触发长度限制，也越容易被精简策略误伤。标识类的信息用短码，完整信息放请求体里更稳。
字段名避开已被占用的常见名。和标准字段或者逐跳字段撞名，会被当成那一类处理，结果往往不是你想要的。起名字时加上业务前缀，冲突概率会低很多。
别把关键逻辑压在自定义头上。既然存在消失的可能，重试、兜底这些机制最好不要依赖它。字段能到是加分项，到不了也不该让主流程崩掉。
关键信息尽量别放在头部：需要传递的内容放进请求体或者约定的查询参数里更稳，这两处的传递规则比头部简单得多，代理IP转发时改动它们的动机也小得多。
需要说明的是，自定义头被摘掉通常不是故障，只是某一环按自己的规则做了处理。定位到是哪一环之后，多半是调整配置就能解决的事，不必怀疑字段本身写得不对。
真正麻烦的是那种时好时坏的情况。同一份配置，有的请求字段在、有的不在，这种往往和链路调度有关——不同请求被分到了不同的转发环节，各环节的精简策略不一致。
落到选型上
如果业务确实依赖自定义头传递信息，选代理IP服务商时可以多问一句：转发时会不会删字段，能不能配置白名单。答案越具体，后面踩坑的概率越低。
Support 给不出明确答复的，用回显法自己验一遍也就几分钟的事。提前花这几分钟，比上线之后排查要划算得多。