同样经过一个中间环节，请求头往目标站走，响应头往回走，方向正好相反。不少人默认代理IP转发两侧时的规则是对称的，于是排查时照着一边的经验去套另一边，越查越乱。
它们并不对称。请求头是你要什么、你是谁，响应头是对方给什么、怎么给的。代理IP转发两侧时的角色也不一样，规矩自然不同。
两侧处理的出发点完全不同
请求方向，代理IP扮演的是「代发人」：它替你发起连接，要按目标站能接受的方式组织好请求头，该加的加、该摘的摘。响应方向，代理IP扮演的是「代收人」：它把目标站的回应带回来，重点是原样传递，让客户端能正确解析。
出发点的差异带来一个直接结果：请求侧的处理更主动，追加和重写都发生在这一侧；响应侧的处理更保守，多数时候只是照搬。你在请求头里看到的代理IP痕迹，通常比响应头里明显。
| 对比项 | 请求头（上行） | 响应头（下行） |
|---|---|---|
| 代理的角色 | 代发人，替客户端组织请求 | 代收人，把结果带回客户端 |
| 常见处理 | 原样带过、追加、重写、摘除 | 多数原样回传，少量按需调整 |
| 留下的痕迹 | 代理写的字段较多 | 痕迹相对较少 |
| 排查关注点 | 字段是否被摘、是否被改写 | 内容是否被转码、长度信息是否一致 |
| 出问题的影响 | 目标站可能拒绝或返回错误内容 | 客户端可能解析失败或渲染异常 |
响应侧也有自己的讲究
说响应侧保守，不代表它什么都不做。内容编码类的字段就常在回程被调整——上游声明的压缩方式，中间环节解压之后再决定是否重新压缩，字段值也跟着改。客户端如果按原值去解析，就会得到一堆乱码。
长度类的字段同理。内容一旦被中间环节重新分块或者重新压缩，长度信息就得跟着改。改得不及时或者改错，客户端就会一直等一个永远等不到结束的响应。
还有一类是缓存相关的字段。中间环节如果自己有缓存逻辑，回程时会按缓存状态调整这些字段，让客户端知道这份内容是从缓存拿的还是刚取回来的。这类调整属于正常行为，不是异常，代理IP链路上的缓存环节尤其常见。
代理IP出口这一层带来的变化，在两侧的表现也不一样：请求侧看到的是出口地址被替换，响应侧看到的则是内容按新链路返回。同一个出口，两侧的影响面并不重合。
把这些差异记住，排查时就不会拿一边的规律去硬套另一边。
先看症状落在哪一侧：请求侧出问题，目标站多半不认或者返回内容不对；响应侧出问题，客户端多半解析不了或者一直等待。方向定准了，代理IP链路上的排查路径会短很多。
还有个实用的判断习惯：遇到说不清的头部问题，先在客户端抓一次、再在目标站侧记一次，两份对比着看。差异出现在哪一段，问题就出在哪一段，比凭经验猜测靠谱。
代理IP链路越长，两侧各自被处理的次数越多。多级转发时，请求侧每跳都可能追加，响应侧每跳都可能调整编码，累积下来的差异往往比单级明显得多。
说到底，两侧都是同一条链路上的事，只是方向不同、角色不同，处理的分寸也就不一样。
那排查时到底该从哪一侧下手？看症状落在哪里就够了：目标站收到的信息不对，顺着请求侧查；客户端拿到的内容不对，顺着响应侧查。方向一对，剩下的是体力活。