一台机器上跑着浏览器、下载工具和几个后台脚本，都走同一条代理IP。某天开始集体变慢，第一反应是线路出问题了。实际情况经常是另一回事：某个程序把出口占满了，其余程序跟着受影响。
先分清是出口的问题还是占用的问题
这个顺序别弄反。
逐个退出，看现象是否跟着消失
最直接的判断方法是把程序一个个停掉，观察其他程序是否立刻恢复。停掉某个程序之后其他程序恢复正常，问题基本就定位在它身上。代理IP本身没有变，变的只是出口被谁占着。这个方法看着笨，却是区分出口问题与占用问题最快的一步。
看连接数和带宽分别被谁吃掉
出口受限有两种形式，一种是连接数被占满，另一种是带宽被占满。打开本地连接列表，看哪个程序占着最多的连接；再看流量监控，看哪个程序在持续跑大流量。代理IP的两种受限表现出来的现象不一样：连接数满了新请求排不进来，带宽满了所有程序一起变慢但都还能跑。
判断顺序为什么重要
顺序搞反的代价是时间。如果是占用问题却去换出口，新的代理IP很快又会被同一个程序占满，现象照旧；如果是出口问题却去调程序，参数改了一轮也不会有改善。先花几分钟确认方向，比直接动手改配置划算得多。
把判断做成一张固定清单
三个动作固定下来就够用：先确认现象出现前动过什么，再逐个停程序观察其他程序是否恢复，最后分别查看连接数与带宽占用。这张清单写出来放在手边，谁遇到问题都能照着走一遍，不必依赖某个人的经验。
判断时最好只变一个条件：先停程序，其他都不动。同时停程序又换出口，即使恢复了也说不清是哪一步起了作用，下次遇到同样的问题还是得重来一遍。
- 先记录现象出现前动过哪个程序或配置
- 逐个停程序，看其他程序是否随之恢复
- 分别查看连接数占用与带宽占用
- 确认方向之后再决定是换出口还是调程序
长期来看，几个程序共用一个出口本身就容易互相影响。可行的做法是按程序分出口，或者给占用大的程序单独留一条线路，其余程序共用剩下的。代理IP的分配一旦按用途分开，出问题时判断范围会小很多，影响也更容易控制。
几个程序共用一个代理IP不是不行，但要把边界划清楚。哪个程序可以占用多少连接、跑多少流量，提前定一个上限，超出时先让程序自己排队，别让它把整条出口吃干净。代理IP的共用方案里，这一条比增加带宽更能提升整体的稳定感受。