同一套环境里开多个实例，想让它们在外部看来是不同来源，能切的只有网络这一层。代理IP能提供的粒度到「一条连接一个地址」为止，再往下走，就要靠别的手段了，这一点先记住。先弄清这条线能切多细，方案才不会设计到做不到的地方。
能切的都在连接层，切不动的都在设备和行为层。
先看粒度能切到哪里，再决定投多少成本，顺序别反。
- 连接粒度
- 一条连接一个地址，最细也就到这里
- 会话粒度
- 登录状态、缓存可以各自独立，属于应用层
- 设备粒度
- 同一台机器的硬件信息一致，无法切分
- 行为粒度
- 操作节奏可以调整，靠的是使用方式，工具帮不上忙
三个层次的实际效果
连接层分开之后，外部看到的来源地址不同，这是最直接的效果。会话层分开之后，登录状态互不影响，一个实例退出不会牵动另一个。行为层的差异最难做，因为要改变的是操作习惯，工具帮不上忙，只能靠流程设计。
切太细的代价
每条连接一个地址听起来彻底，实际用起来成本很高。线路数量翻倍，管理复杂度跟着翻倍，核对一遍要花的时间也翻倍。而收益在超过某个点之后就不明显了：外部看到的差异，到了「来源不同」这一步已经足够，再细也不会带来更多区分度。
什么时候需要切到最细
同时跑的任务数量大、彼此之间不能有任何关联时，才值得切到连接级，把每条代理IP线路单独绑一个实例。这类场景通常有明确的隔离要求，比如不同任务不能互相影响。一般的多实例场景，会话层分开就够，连接层按实例分配即可。
地址数量与实例数量怎么配
一对一最省心，也最容易核对。实例多于地址时，让同一地址上的实例分散在不同时段，减少同时出现的概率。地址多于实例时，保留几条备用代理IP线路，某条出问题时能立刻换上，不至于让实例停在那里等。
切分之后怎么验证效果
同一时刻从两个实例各查一次地址，结果不同即连接层已分开。再各做一次登录，看状态是否独立，这是会话层。两层都验证过，剩下的差异只能靠操作方式去补，工具这一侧已经没有可调的了。
做不到的部分怎么处理
设备层切不动，这一点先接受，不用在这上面花力气。行为层可以调，但调整要落到流程里：各实例处理不同内容、按各自进度推进，节奏自然不同。把这两点分清，方案就不会在无用功上打转。
回到粒度这个问题：连接层能切到一条一个地址，会话层能切到互不影响，设备层切不动。知道边界在哪，方案就不会设计到做不到的地方。