同一个代理IP下挂多个实例，会遇到两类完全不同的问题，混在一起想就会得出矛盾的结论。一类是并发，多个实例同时发请求，抢的是带宽和连接数；另一类是关联，多个实例的表现被当成同一个来源的行为记录下来。前者影响速度，后者影响能不能长期跑下去，判断方向完全不一样。
两件事各管什么
并发不够会有什么表现？
先是慢，接着是超时，最后是直接连不上。表现是一路变差的，跟关联问题的表现完全不同，后者往往是某个实例突然用不了，其余照常。
- 并发
- 带宽、连接数、握手频率，任一项到顶都会卡
- 关联
- 来源地址、设备指纹、行为时段，任一项重合度太高就会被归到一起
分开看就清楚了。并发不够，加带宽或者加IP都能缓解，属于资源问题，花钱能解决。关联太紧，加资源没用，得把来源拆开，让不同实例看起来来自不同的地方。资源问题花钱解决，关联问题靠结构解决，两种办法不能互换，也换不了。
判断方向错了，后面花再多钱也只是绕远路。
一个地址最多挂几个
一个IP挂三到五个实例只是经验值，不是一个标准。实际能挂多少要看请求频次，低频的挂十个也没事，高频的两个就够呛。判断依据是连接数和握手频率，不是实例数本身，先量一量再定。
先看表现是逐渐变差还是某个实例单独出问题。逐渐变差往并发方向查，单独出问题往关联方向查。两种表现偶尔同时出现，这时候先解决并发，因为并发问题会掩盖关联问题，混在一起查容易走错方向，越查越乱。
拆开之后怎么管
拆开不是终点，还要能对上号。每个实例对应哪个IP，写下来，换的时候同步更新。没有这张表，出问题的时候只能一个个试，试到第三个就乱了。表不用给别人看，自己看得懂就行，关键是别靠记忆，记忆在第三个实例的时候就开始出错。
还有一项容易被忽略：拆开之后各实例的上线时间也要错开一点。同一秒起来的一批实例，请求节奏完全一致，即使IP不同，行为特征仍然很像。错开几分钟，看起来会自然很多。
并发是钱的问题，关联是结构的问题。
两件事分清楚之后，配置怎么写、资源买多少，答案自然就出来了，不用再反复纠结同一件事。