寄快递时包裹外面贴着一张面单，写着寄件人、收件人、物品类型和运送要求，中转站扫一眼就知道往哪送、怎么处理。HTTP 请求也有这么一张面单，叫请求头；代理IP转发请求时，干的主要就是处理这张面单的活。
先说结论：转发不是把面单原封不动递下去。代理IP按规则会对头部做四件事——原样带过去、追加新行、改掉重写、扣下不发。多数人只想到第一种，所以看到两端的头部对不上时容易误判。
这篇把四个动作逐一拆开，顺带说明为什么你在本地抓到的请求头，和目标站日志里记下的那一版，本来就不该长得一模一样。
代理IP转发请求时，动的是面单不是包裹
一次 HTTP 请求分两块：请求头和请求体。请求体是真正要寄的东西，比如表单内容、上传的文件；请求头是贴在包裹外的面单，写着目标主机、浏览器标识、能接受什么格式、要不要保持连接这些信息。代理IP转发时，请求体基本原样搬运，动手脚的地方集中在头部。
为什么偏偏是头部？因为头部是写给中间环节看的说明书。目标站在哪、连接怎么维持、内容怎么解压，这些事都记在头部里。代理作为中间环节必须先读懂这些信息才能正确转发，读懂之后顺手改两笔也就成了常态。
这也解释了一个常见现象：换了代理IP出口之后，网页内容本身没变，但有些站点的反应变了。变的是面单上的信息，包裹里的东西并没有动。
认清楚这一点，后面所有差异都能找到出处。
四个动作，代理IP每次都可能挑着用
第一个动作是原样带过去。目标主机、接受的语言、接受的内容类型这类字段，代理一般不碰，因为目标站要靠它们决定返回什么。这部分占头部的大多数，也是转发最省事的部分。
第二个动作是追加新行。代理往往会在头部里添几行说明，比如标注原始出口、标注自己是第几跳。这些行是代理自己写上去的，目标站看得到，而你发出请求时并没有——这是同一份头部在两端对不上的头号原因。
第三个动作是改掉重写。某些字段的值会被替换成本环节的真实情况，最典型的是连接控制类字段，它们描述的是相邻两段连接的状态，换一段连接就得换一次值。原样带过去反而会出错。
第四个动作是扣下不发。有一小批字段天生只在相邻两个环节之间有效，代理读完自己处理掉，不会转给下一环。这类字段目标站从来没见过，也永远不会见到。
知道四个动作有什么用
最直接的作用是解释差异。本地抓到的请求头和代理IP链路另一端记录的那一份，本来就不该完全相同——中间隔着一个会加、会改、会删的环节。看到差异先别急着判定异常，按四个动作逐条对照，多数情况都能对上号。
第二个作用是排查更有方向。如果目标站说缺了某个字段，先分清它是被扣下了，还是压根没发出去；如果对方记录到的地区信息和预期不符，问题多半出在追加或重写的那几行，而不是地址本身。改代理IP配置之前，先确认变动落在哪个动作上。
第三个作用是理解代理IP这一层的能力边界。它能调整的是面单，改不了包裹里的东西；能替换的是出口地址这一层，账号信息、登录凭据仍按原本方式交互。把边界认清，期望才不会跑偏。
原样带过去的是目标站赖以判断的字段，比如目标主机、内容类型、语言偏好，代理动它们没有任何好处，只会让目标站返回错误的东西。
追加和重写是两端差异的主要来源，同一份请求头在你这边和在对面长得不一样，绝大多数情况都能在这两个动作里找到解释。
扣下不发是协议设计的结果，不是代理IP服务商偷偷做了什么。这类字段本来就只在相邻环节之间有效，真传到目标站反而会造成误解。
把四个动作记牢，再看代理IP链路上的请求头就有了参照系：哪几行该在、哪几行会变、哪几行注定到不了，心里都有数，排查时按图索骥即可。