代理连接失败：从代理本身查到站点侧

代理填完，测试按钮给出失败。这时候最怕的是随机改配置，换端口、换协议、换节点，改了半天也不知道是哪一项起了作用。

原因大体分布在四层：代理服务本身、认证与协议、客户端配置、目标站点。顺序也按这个来，从代理自身往外查。

先把代理本身摘出来测

第一步不要在任何业务工具里查，直接把这条代理拿到一个能手动配置代理的普通浏览器或者系统代理设置里，看它能不能访问外网。这一步的意义是把代理和业务环境分开。

如果这个环境也连不上，问题就在代理本身：过期、被停用、出口节点故障，或者服务商那边设了访问限制。这时候后面几步都不用做，直接找代理服务商核对状态和用量。

如果这里能通，说明代理是活的，问题出在配置或者链路上，继续往下。

判断依据一句话就够：同一份凭据，换个地方能用，说明凭据本身没问题。

认证与协议要对齐

凭据正确却连不上，第二个怀疑对象是协议。常见的错配有三类：服务商给的是 SOCKS5，环境里选的是 HTTP；自建的是 SSH 隧道，环境里却按 SOCKS5 填；一套代理同时支持多种协议，但不同协议对应不同端口，端口填成了另一个。

判断依据是报错文本。提示认证失败或者凭据错误，就往账号密码上找，注意复制粘贴带进来的空格和换行，用户名里的特殊字符有没有按要求转义；提示协议错误、握手失败，就往协议类型和端口上找。

用户名和密码这类字段，建议手动敲一遍做对照。看不见的字符造成的失败，肉眼核对是查不出来的。

客户端里的配置到底生效了没有

这一步要回答一个更隐蔽的问题：配置填对了，但它生效了吗。

有两种常见情况。一是配置根本没被应用，改了没保存、改的是另一个环境的配置、启动的还是上一个会话。二是配置生效了，但被其他设置覆盖：环境里另有一处网络开关、扩展插件自己接管了代理、系统层的代理设置优先级更高。

判断依据看出口地址。连上之后访问一个显示当前出口的页面，显示的应该是代理的地址，而不是本地地址。如果还是本地地址，说明请求根本没走代理，哪怕测试按钮显示通过。

对照做法很简单：同一个环境分别开一次代理、关一次代理，看出口地址有没有变化。没有变化，问题就在客户端这一侧。如果同时在跑多个环境，还要逐个确认各自的出口，按账号隔离环境的工具（比如 PurpleMark）在做代理绑定时关注的正是这一点。

目标站点侧的拒绝特征

四层都通、代理也确实生效，但业务页面依然打不开，这时候要看的是目标站点的反应，而不是继续在代理上折腾。

这一类通常有比较明显的样子：连接能建立，握手也能完成，但请求返回 403 或者直接被重置；页面能打开，登录、发布这类动作被拒绝；同一个出口访问别的站点正常，只有这一个站点不行；还有一种是间歇性失败，这说明出口或者链路被限速、并发被限制。

判断的关键是分开连接层和业务层。连不上是代理的问题，连上了但被拒绝，多半是出口质量或者访问频率的问题。数据中心 IP、被大量使用过的共享 IP，在业务层容易被拦；住宅 IP 相对好一些，但也不是通行证，请求频率、并发数、访问时段同样会影响结果。

排查时守住三个习惯

一次只改一项。同时改了协议又换了节点，最后即使通了，你也不知道原因，下次还会再踩一遍。

先记录再调整。把能用的那份配置记下来，地址、端口、协议、认证方式都写上，下次出问题直接对照，比从零排查快得多。

对照测试优于反复重试。确认配置没问题却还是连不上，反复点测试按钮不会带来新信息，不如换一个网络环境、换一条代理做对照。