很多刚接触的人会问：走代理IP之后，对方看到的地址是谁的？答案是转发点的。而请求里的内容、参数、请求头里的大部分字段，原样保留。理解这条「地址换、内容不换」的规则，就能推断出哪些做法可行、哪些注定失败。
替换发生在哪一环
- 本地程序按原样构造请求
- 请求发往转发点，目标由转发点再发出
- 转发点用自身地址建立到目标端的连接
- 目标端看到的是转发点的地址
四步里，内容始终由本地程序决定，转发点不改动它。所以依赖内容特征的判断不受影响，依赖来源地址的判断则会看到新的值。代理IP能改变的是后者，不是前者，这条界线在很多场景里直接决定了方案的可行性。
推论与用法
依赖地址还是依赖内容
由此可以推出一条实用规则：任何以来源地址为依据的机制，走代理IP之后判断结果都会变；任何以内容为依据的机制，则和原来一样。判断某个需求能不能做，先看它依赖哪一类，比直接上手试要快得多。
先分清依赖什么，再谈能不能做。
分段独立带来的好处
还有一层常被忽略：转发点与目标端之间的连接是独立的。这意味着连接层面的表现，比如握手耗时、复用情况，和本地到转发点这一段是分开的。代理IP的延迟与稳定性因此可以分段分析，而不是笼统地看一个总数字。
日志为什么对不上
地址替换还会影响日志的可用性。目标端记录的是转发点地址，本地日志记录的是目标地址，两边对不上是正常的，需要通过时间戳或其他字段来关联。代理IP的排查里，这个对不上的问题经常造成误判。
两边日志对不上，不等于出了问题。
地址替换是手段，不是目的；目的是让请求从预期的位置发出。把这句话放在心里，很多决策会简单很多：需要改变来源位置的场景适合用，不需要的场景就不必引入，省下来的复杂度是实打实的。
所以判断一个需求时，先问它依赖地址还是依赖内容。这个问题的答案，往往直接决定了方案要不要用代理IP，也决定了后面的一系列配置该怎么定。