多账号同时在线的时候，最容易犯的错是买了一批代理ip却绑在整机层，表面上每个账号都有地址，可一台机器上的所有程序走的还是同一条线。要按实例分开绑，先确认工具能不能识别到单个进程或者单个窗口，这一步做不到，后面的配置都是白费，改十遍也一样。
绑错一层等于没绑，再贵的IP资源也用不上，钱白花。
先问粒度，再谈资源。
绑在哪一层
- 先看工具能不能识别到进程
- 再看规则能不能按进程单独生效
- 最后验证地址是不是真的变了
- 整机层：配一次全机生效，最省事也最粗
- 进程层：一个实例一条线，够用且可控
- 设备层：一台一套环境，最彻底也最贵
大多数场景做到进程层就够了。整机层适合只需要一个来源的场合，设备层留给要求最严的项目。三层可以叠着用，比如主力账号走设备层，测试账号走进程层，成本能压下来不少，也不用一次配到底。配置表按层分开写，改的时候不容易牵一发动全身。
一个实例绑几条
一条就够，多绑反而乱。同一个实例挂两条IP线路，走哪条取决于谁先建立连接，结果不可控。要做冗余就用主备切换，别用同时生效。切换的阈值设高一点，频繁切换比不切换更不稳定，最后连问题出在哪都说不清。
绑完怎么验证
每个实例单独开一个查询页面，把结果截图存下来，跟配置表对一遍。截图这一步别省，配置是会变的，过两周回头查，只有截图能证明当时的状态。十来个实例一轮验证十分钟，比事后排查快得多，也省心。
账号多了怎么排
按业务分组，同组同地址段，不同组彻底分开。分组的好处是出问题时影响面可控，一组出状况，其余组照常。分组之后配置表也好看，一页纸能写完，交接的时候不用解释半天，新人看一眼就懂。
分组也要留余地。全部分死，加一个账号就要改动好几处，容易出错。留一组机动IP，专门给新增账号用，用完再归到对应组里，账也好记，不用每次重排整张表。
还有一种常见误区是频繁给同一个实例换地址，以为换来换去更安全，实际会让这个实例的表现变得没有规律，看起来比不换更显眼。
绑在进程层，验证留截图，配置写下来，三件事就够了。