代理服务器就像一处转运站，货物进出都要经过它。转运站本身修得再大，前面的路窄、后面的路堵，整体吞吐一样上不去。卡顿出现时，很多人第一反应是机器不行，实际原因常常在别处。
代理常见的瓶颈就那么几处：IP带宽、并发连接数、处理开销、上游线路。挨个排除比笼统地扩容更有效。
- 先看IP带宽 同时跑的任务总量是否接近上限
- 再看连接数 并发数是否触顶，表现为新连接排队
- 然后看处理开销 加解密与转发是否占满处理器
- 最后看上游 对方线路本身是否已经饱和
几处常见的瓶颈
带宽这处瓶颈最直观，任务量上来之后，每一条连接的可用带宽被摊薄，表现是整体变慢，个别请求未必失败。连接数这一处的表现不同，新连接建不起来，会看到排队和超时，而已有的连接照常跑。处理开销这处瓶颈比较隐蔽，加密转发对处理器有持续占用，任务量不大时看不出来，一上量就顶到天花板。上游这条瓶颈则完全不在自己手里，只能通过与不同上游对比来确认。
先分清是变慢还是连不上，两类现象指向的位置不同。变慢多半是带宽或上游，连不上多半是连接数或上游拒绝。
怎么判断卡在带宽还是连接数
对代理来说，看两个指标就够了：单位时间的传输总量是否已经贴在某个数值上不再上升；新建连接的成功率是否明显下降。前者贴着不动，说明带宽到顶；后者掉下来，说明连接数或者上游的接受能力到了上限。两个指标同时看，基本能锁定方向。
处理开销容易被忽略
加密转发要在每一条连接上做计算，连接数越多，这部分开销越大。任务量小的时候，处理器的余量很足，怎么跑都看不出问题；一旦并发上去，处理器成了短板，表现却是带宽没用满、连接也没到顶，但速度就是上不去。这种情况加带宽没有用，得从并发数量或者处理方式上想办法。
上下游的连带影响
自己这一侧都正常，问题也可能出在上下游。上游线路拥塞、下游目标站限速，都会让你的参数看起来一切正常却跑不快。判断的办法是换一条上游复测，或者换一个目标站对比，能把责任范围缩小。
顺着这几处查下来，多数情况都能定位到大致的范围。记住这三点：
- 变慢先看带宽，连不上先看连接数
- 带宽未满而速度上不去，看处理开销
- 自己这侧都正常时，换上游或换目标站对比
把代理服务器的排查顺序固定成习惯，下次遇到卡顿就不用从头猜起了。