代理IP连不上的首查顺序，不能一套模板套到底——不同使用场景里，「最可能出问题的地方」不一样，先查哪里自然也不同。浏览器场景先查系统代理，桌面程序场景先查软件自身配置，脚本场景先查环境变量与代码里的代理设置，找准场景的首查重点，比按通用顺序硬走快得多。
分场景的前提是先确认「当前用的是哪种场景」——很多时候代理IP连不上发生在混合场景：浏览器和脚本同时在跑，分不清是哪个在报错。动手前先锁定报错来自哪个程序，再套用对应场景的首查重点；分不清来源就按「全部连不上」处理，从系统代理开始查起，先覆盖公共环节。
三类场景的首查重点
浏览器场景先查系统代理
浏览器场景最常见的连不上，根源在系统代理：浏览器默认读取系统网络设置里的代理配置，系统代理没开、指向错误或与浏览器自带的代理设置冲突，页面就会打不开——而页面报错往往被误读成代理IP问题。首查先看系统代理开关与填入值，再确认浏览器没有启用与系统设置冲突的独立代理配置，多数浏览器场景问题在这一步解决。
桌面程序场景先查自身配置
桌面程序场景与浏览器相反：大多数程序不读系统代理，要在软件自己的设置里单独填代理IP——首查先找软件的代理设置入口，确认填入了配置且已启用；很多桌面程序还分「系统代理」与「自定义代理」两个选项，选错也会导致流量没走代理。这类场景的连不上，大概率不是代理IP服务端的问题，而是程序这一层的接管没到位。
脚本与命令行场景先查调用方式
脚本与命令行场景的坑在「代理设置放在哪一层」：有的脚本读系统环境变量，有的要在代码里显式指定代理IP，还有的要靠第三方库的独立配置——同一个脚本换个运行环境就失效，多半是读取的配置层变了。首查先确认脚本实际读取的是哪一层设置，再核对那一层的填入值；顺带确认脚本里的代理IP地址端口写法与配置一致，这类场景的连不上大多是「配置没被读到」而非「代理真的坏了」。
三种场景有一个共同点：先确认「这个程序到底从哪读代理配置」，再查「那一层的值对不对」——接管层找对了，问题就解决了一半；找错了层，在别处反复折腾都是白费。场景差异的本质，就是各自读取代理配置的入口不同。
场景还会随使用方式变化：同一台设备，今天用浏览器、明天跑脚本，代理IP出问题时的首查重点就不同——别把「上次是这么修的」当万能钥匙，每次先按当前场景定位。把常用场景的检查要点各记一份，出问题时对号入座，比临场回忆快得多，也能避免拿错场景的经验硬套。
四步首查走完、场景差异也考虑了，仍然定位不了——此时需要进入更深一层的定位方法：把问题挂回配置、接管、链路、服务端四层逐层验证，并学会带着证据求助。下一篇讲首查之后的深挖路径。