和全范围变慢相反，还有一种更隐蔽的情况：只有某一个程序走代理IP的时候特别慢，其他程序一切正常。这种“局部慢”最迷惑人，因为代理IP看起来没问题、网络也通，偏偏就是那一个程序不争气。其实局部慢的规律性很强，问题多半出在三个地方：程序自己的代理设置、程序的并发或线程配置、以及程序和代理IP类型的匹配。
为什么局部慢要从程序自己身上找原因？因为代理IP对每个程序提供的底层网络是一样的：同一个出口、同一条线路，别的程序跑得顺，唯独某个程序慢，差异一定出在程序和代理IP的配合方式上，而不是代理IP本身。把代理IP当成变量反复换，不如先看那个程序是怎么用代理的，方向反了最容易白忙活。
第一处：程序的代理设置有没有配对
先看程序自己怎么走代理IP。有些程序支持系统代理，有些程序要用自己的代理设置，还有些程序两者都支持但只能选一个。如果程序同时开了系统代理和自己内部的代理配置，两个设置指向不一致，流量会在两层之间反复折腾，慢就是必然的。检查时把程序的代理入口打开，确认它走的确实是代理IP的地址端口，而不是系统里残留的旧配置。
代理设置还有一个常见的坑：协议类型。程序里如果让你选 HTTP 还是 SOCKS5，选错了虽然能连上，但性能会明显打折——用 HTTP 的方式去走一个需要 SOCKS5 协商的链路，或者反过来，都会多出不必要的转换开销。确认程序里填的协议类型和代理IP服务商提供的类型一致，这个细节常常就是局部慢的真凶。
第二处：程序的并发和线程配置
第二处看程序的并发配置。有的程序默认开几十上百个并发连接，每个连接都要走代理IP建立会话，连接一多，对代理IP的并发额度消耗就大。如果代理IP套餐的并发数有限，程序一开高并发就把额度占满，表现为这个程序特别慢，而其他低并发的程序不受影响。这时候把程序的并发数调低，或者看代理IP控制台确认并发占用，往往立刻见效。
线程数也有类似影响。有些程序的线程配置默认很高，线程多、请求密，代理IP出口处理不过来就会排队，慢的体感就出来了。调整方向是让程序的并发线程和代理IP套餐的容量匹配，而不是无脑加线程——线程加得越多，出口排队越严重，反而更慢，这是局部慢里很常见的一个认知误区。
第三处看程序对代理IP类型的敏感度。实时性强的程序，比如游戏、语音、视频会议，对延迟和抖动敏感，走共享的轮换出口就会忽快忽慢，换个长效固定的出口立刻稳定；而大批量下载的程序对带宽敏感，对延迟不敏感，走低带宽的独享出口反而慢，换个高带宽的共享出口更快。同一个代理IP在不同类型的程序里体感不同，不是代理IP坏了，是类型没对上。
判断程序和代理IP类型是否匹配，最直接的办法就是交叉验证：把这个程序换到另一类出口上试一次，再把另一个同类型程序放到当前出口上试一次。换出口后程序变快，说明是类型匹配问题；换什么出口都慢，问题才回到程序自身的设置上。两次交叉，答案基本就清楚了。
局部慢的三处排查，顺序也有讲究：先设置后并发再类型。设置是最容易出问题也最好改的一处，并发是第二常见的一处，类型匹配属于更深一层。按这个顺序走，多数局部慢在设置这一关就能解决，用不着动并发和类型。排查的时候一次只改一处、改完立刻验证，能准确知道是哪一步起的效果。
问自己一个问题：这个程序是不是必须走代理IP？如果它只是偶尔用一下，而代理IP套餐是给别的长任务准备的，那它的慢可能只是因为共享了同一条出口——给它在空闲时段用，或者单独分配出口，比反复调它的设置更实际。程序的慢要先问“该不该走这条路”，再问“这条路怎么走”，顺序别搞反。
个别程序慢的定位到此基本讲完：查设置、查并发、查类型匹配，三处都过一遍还慢，就要怀疑是目标那一边的问题了。