模拟器多开之后，最容易出问题的是代理IP配置的层级。同一台机器上的多个实例，配置可以写在模拟器全局、可以写在单个实例、也可以写在实例内部的客户端，三个位置生效范围不同，写错一个地方，前面配的全白做。
- 模拟器全局
- 一次配置所有实例生效，适合全部实例走同一条代理IP线路的场景
- 单实例设置
- 只对当前实例生效，多实例分别走不同线路时用这一层
- 实例内客户端
- 优先级最高，会覆盖上面两层的设置，排错时先看这里
顺序为什么重要
顺序错了会出现一种很难查的情况：配置看起来都填了，实测代理IP却全都是同一个。原因是全局那一层的优先级高过单实例，实例层的填写被忽略。改的时候从全局往下改，先确认全局是空的，再逐个实例填，最后看实例内部有没有残留的旧配置。
三层都检查过之后，再去做验证。验证的办法是在每个实例里各打开一次查地址的页面，结果互不相同，说明分配生效。
先清空上层，再填下层，最后检查最里面那一层，这个顺序换不得。
还有一种情况是配置文件的复制。新建实例的时候选择从已有实例复制，源实例的线路设置会一起带过去，看起来是新实例，用的还是旧地址。批量新建之前先确认复制模板是干净的。
分配数量怎么定
实例数和线路数要一对一，不要几个实例挤一条再靠错峰，错峰只在任务量很小的时候有效，任务量一上来就失效。
一对一最省心，也最容易记账。
线路数不够的时候，宁可减少实例数，不要共用。共用之后每个实例的失败率互相影响，一个实例跑满带宽，其他实例跟着超时，查起来分不清是谁的问题。减少实例数的代价是进度慢一点，共用带来的代价是故障定位时间翻倍，后者更贵。
分配完之后，把实例编号和代理IP线路编号对应起来记一张表。表上还可以加一列，记录这条线路启用的日期。跑一段时间之后回头看，哪条线路最先出问题一目了然。
层级、顺序、数量，这三件事定下来，模拟器多开的网络部分就稳了。剩下的问题基本都在任务本身，跟配置无关。