多个实例共用一条代理IP线路，先看它们互相抢的是什么

几个实例挂在同一条独立IP线路上，跑单任务的时候看不出问题，一起跑就有人卡住。抢的东西有三样：带宽、连接数、对方给的排队位置。三样里带宽最容易想到，也最不常是真正的瓶颈，多数情况是连接数先到顶，后面的请求只能排在队尾等。

先分清抢的是哪一样，再决定怎么分。

同时变慢是线路挤，个别变慢是实例自己出了问题。

区分方法很直接：把实例一个个关掉，看其余的是否恢复。关掉某个之后其余立刻变顺，问题就在那个实例上，它可能在跑批量任务，把连接占满了。全都关掉才恢复，说明这条代理IP线路本身的容量不够，得加线或者错峰。

共用线路的三个代价

第一个代价是容量被平均分。一条线路的容量固定，挂的实例越多，每个分到的越少，峰值时段谁都不够用。第二个代价是表现被绑在一起，一个实例的异常行为会把整条线路拖下水，其余实例跟着受影响。

第三个代价最容易被忽略：出了问题分不清是谁的责任。五六个实例共用一条线，某个实例的连接失败率忽然升高，可能是它自己的配置错了，也可能是线路在抖，没有分段排查的手段就只能靠猜。

要降低这三个代价，最简单的办法是拆线。两三个实例一条线，出问题时影响面小，排查范围也窄。成本会上去一些，但比每次都从头查要划算得多。

拆线之后怎么分

按用途分，别按顺序分。跑批量任务的实例单独一条，交互型的实例共用一条。两类任务的连接特征完全不同，混在一起互相干扰最明显，分开之后各自都顺。

暂时不能拆怎么办

先限速，再错峰。限速是把批量任务的并发压下来，让它别把连接占满；错峰是把启动时间拉开，避开同一分钟。两个办法都不花钱，能撑一段时间，但规模再涨还是得拆。

怎么判断该拆了

连续一周在高峰时段出现IP连接排队，就该拆了。另一个信号是排查成本，一次故障要花两小时以上才能定位到具体实例，说明共用的粒度已经太粗，拆开比继续查更省时间。

拆线不是越多越好。每条线都有固定成本，拆到每个实例一条，成本会翻上去，多数场景两三个实例一条是比较合适的平衡点。

先看清抢的是哪一样，再决定拆还是限速，别一上来就加线。