在云主机上跑采集任务的人常碰到一件事：账号和凭据都填对了，对端站点看到的来源还是这台机器自己的地址。原因不复杂，云主机开通时就带着一个固定的公网地址，机器上所有网络请求默认都用它。想让任务走另一条线路，得在机器里再配一层，代理IP在这种场景里扮演的正是这一层角色。
云主机自带的那个地址
云主机开通时，服务商从自己的地址段里划一个公网地址给这台机器。这个地址长期不变，机器重装系统之后往往还是它。所有从这台机器发起的请求，对端看到的都是同一个来源。带来的后果有两个：所有任务共享同一个来源，任务之间容易互相牵连；这个地址的归属长期固定，高频访问同一个目标更容易引起注意。
想让来源变一变，就得在机器里再配一层。
再加一层之后变成什么样
配好代理IP之后，云主机发出的请求先送到代理那一端，再由代理以自己的名义去访问目标。对端看到的换了人，机器自己的地址退到后面。这一层加在网络路径里，程序本身不必改动，只要它读取的是被改动的那一层设置。
配置放在哪一层
云主机上的配置可以放在三个地方，影响范围依次缩小。放在哪一层，要看希望多少程序跟着走。
- 系统层
- 改一处，机器上读系统设置的程序都跟随
- 脚本层
- 只影响这一个任务，同机的其他程序不受影响
- 进程层
- 随任务启动传入，跑完就失效，适合临时用
怎么选
整台机器都在跑同一类任务，配在系统层最省事，一次配置长期有效。机器上还有别的业务在跑，就配在脚本层，避免把无关流量也带过去。只做一次短任务，进程层最干净，用完不留痕迹。代理IP在机器上的配置分散在多处，先定层次再动手，后面的调整才有边界。
- 同一个任务长期跑，配在脚本层最稳
- 整机专用，配在系统层省事
- 临时验证，进程层用完即弃
- 不确定时先从脚本层试起，影响面最小
层次选对，改动才不会溢出到别的业务上。
配完记得验证一次。
在云主机上验证有一种省事的做法：另开一个不读脚本配置的程序，访问一个能显示来源的页面，看两边看到的地址是不是不一样。如果一样，说明配置没落在预期的那一层。先定层次、再动手、最后验证，这三步顺序不能颠倒，代理IP的配置只有落在对的那一层才会真正生效。层次定了，后面的调整才有边界。