多个实例从同一个来源起步，想分散开，能动的只有代理IP这一层。做法是把实例分到不同ip线路上，让它们各自从不同地址发出请求。这一步解决的是「看起来来自哪里」，至于实例之间还有没有别的相似之处，要另算。分散之后还得重新核一遍，否则不知道谁真的走了哪条线。
分散做的是加法，不是替换。原来那条线不用废掉，只是把一部分实例挪出去。
挪之前先想清楚要分开的是哪一类线索，来源、时段还是别的。只是不想让它们同时挤在同一条线上，分两条就够；要让外部完全看不出关联，得分到不同区域，数量也跟着上去。
| 程度 | 做法 | 代价 |
|---|---|---|
| 同区域分线 | 一条线分两个实例 | 成本低，来源仍同区域 |
| 跨区域分线 | 按区域分配到不同线路 | 成本中等，管理复杂 |
| 一实例一线 | 每个实例单独一条 | 成本最高，核对最清楚 |
- 先统计现有实例数量与活跃时段
- 按用途分组，同组可以共用一条线
- 把同时活跃的实例错开到不同线路
- 留一成备用线，应对临时新增
分散到哪一档才够
判断标准是同时活跃的实例有多少。同一时刻只有两三个在动，分两条线就够；十几个同时跑，就得按组分散，否则线路再换也会在时间上撞在一起。这一层想清楚，后面的动作才有依据，不然容易在数量上反复加减。分散的档位定下来之后，再回到代理IP的线路池里挑具体的线。
先算同时活跃数
翻一下各实例的活跃时段，找出重叠最多的那一段，数一下这段时间里有多少个在跑。这个数字才是来源分散的依据，实例总数反而没那么重要。总数二十个但活跃时段完全错开的情形很常见，那种情况几条线就够用。
错开时段比多加线便宜
把两个实例的活跃时段拉开，效果接近分到两条线，成本却为零。前提是任务允许调整时间，有些任务固定在某个时段，这类只能靠分线解决。先看哪些能调，剩下的再分代理IP线路，顺序这样排省下的成本最多。
分散之后要重新核对
线路变了，之前记的对应关系就全废了。核对的办法是同一时刻从每个实例各查一次地址，与新的来源分配表逐条对。对不上的多半是规则没生效或者进程名写错，查一遍就能定位，不必从头配。
分散做到够用就行，不必追到极限。实例数量还会涨，留出余量比一次配到最细更实用。