很多人以为代理收到请求后就是原样转发，顶多改一下头字段。实际上，大部分代理在转发前会先对请求做一轮”整理”——把不合规的写法纠正过来、把重复的信息合并掉、把可能引起歧义的地方统一起来。这一步肉眼看不见，却直接影响请求能不能被目标站正常接收，也解释了不少”同一份请求，直连没问题、走代理就报错”的怪现象。
整理分四步，顺序是固定的
先做格式检查。请求行和头字段都有严格的语法约定，多余的空格、不规范的换行、非法字符都要在入口处拦截或修正，避免带病请求一路走到目标站。接着是合并重复项。同一字段出现多次时，按规则取最后一个或合并成一组，不同代理取舍略有差异，这也是为什么换代理后个别请求行为会变。然后是补全缺失项。缺了必需的字段就补上约定值，比如没有指定连接方式时补一个默认项。最后是长度与格式的边界检查，超限的请求直接拒绝，而不是转发出去让对方报错。
两个容易被忽略的细节
第一是主机名的处理。请求里写的主机名与实际连接的目标不一致时，代理以哪个为准，各实现有自己的约定，规范化的结果会影响目标站看到的是哪个站点。第二是方法名的归一。大小写、写法差异会被统一成标准形式，转发出去的请求是规整过的，而不是客户端原始的样子。
这些整理动作还有一个更实际的作用：把客户端原始的、五花八门的写法统一成标准形态，目标站收到的请求更”干净”，被识别为异常的概率反而更低。这也是为什么同一个站点，规整的请求走代理通常比零散的请求更顺畅——不是代理变快了，是它把请求整理得更像正常访问了。
这种整理还有一个容易被忽略的副作用：它会悄悄改变请求的”外貌”。同一份内容，客户端原始写法和规范化后的写法，在目标站的访问日志里看起来可能完全不同。于是就有了这样的现象——请求确实是同一个，直连时目标站记录的是一个形态，走代理后记录的是另一个形态。多数情况下这种差异无害，但在需要精确复现请求场景的调试里，它常常是”对不上”的根源。理解这一步，遇到”直连正常、代理异常”时就能多一个排查方向：先对比请求在两端被记录下来的样子，而不是急着怀疑代理把数据改坏了。
小结：代理在转发前做的整理，让每个请求都以标准形态到达目标站。用代理IP时如果遇到怪异的报错，先想想这一步——问题往往不在线路，而在请求本身带着不规范的内容。