给代理IP配请求头时，两种写法看起来一模一样，结果却不同：有人按规范写字段名，程序跑得好好的；有人从别处复制了一段配置，字段名大小写不一样，同样的逻辑就失效了。头字段这一层，规范和实现之间隔着一段现实距离。
按规范的说法，字段名不区分大小写，同名头可以出现多次，接收方按规则合并。落实到具体实现，各家处理得并不完全一致，尤其是在代理转发这一段。
- 字段名按小写统一，还是保持原样转发
- 同名头合并成一条，还是保留多条
- 合并时顺序按出现先后，还是按固定次序
- 自定义字段是否被列入放行范围
字段名大小写的实际影响
规范层面不区分大小写，但很多程序在比对时按字符串来，一旦大小写对不上就认不出来。这类问题在直连场景里很少见，因为两端用的是同一套库；到了代理链路上，中间环节可能重写字段名，也可能原样保留，取决于实现。排查时最省事的办法是把链路两端的头各打一份出来，逐字段比对，差异一目了然。
字段名怎么统一，取决于链路两端谁在比对。只要有一端按字符串严格匹配，就要保证这一端看到的形式是固定的。
重复出现的同名头
同一个字段名出现两次并不罕见，尤其是转发链路上，每经过一层就可能追加一次。规范给出的做法是合并成一条，值之间用逗号分开。但有些字段天生不适合合并，合并之后语义会变。这就解释了一个常见现象：直连时正常，走了中间环节之后某些字段失效，多半是合并方式与接收方的预期不一致。
转发时会不会重排顺序
多数实现不会特意打乱顺序，但也不保证保持原样。如果业务对字段顺序有依赖，这本身就是个脆弱的假设。更稳的做法是不依赖顺序，让每个字段的意义都能独立判断。
落到配置上怎么看
给代理配置时值得确认三件事：转发环节是统一转小写还是保持原样；同名头是合并还是各自保留；自定义字段在不在放行范围里。这三点在多数工具里都能查证，但默认值往往藏在文档深处，不主动确认就只能等出问题时再回头找。
记录与复核
把这三点的实际取值记下来，随配置一起归档。链路调整或者升级之后复查一遍，能省下不少临时排查的时间。这种记录看起来琐碎，真正用到的时候价值很高。
字段名的比对方式是配置的一部分，不是实现细节，最好写成文档。
这些规则平时用不到，踩到了还要一层层猜吗？先把口径写下来，就不用猜。