代理连接失败排查：出口、链路、应用层三层顺序

代理填好了，账号密码也填对了，点检查却提示连接失败。多数人这时候直接去找代理服务商，换节点、改端口、催客服。效率通常很低，因为失败原因分布在整条链路上，代理只是其中一环。

与其挨个乱试，不如固定一个从外到里的顺序：先确认出口有没有真的生效，再看链路通不通，之后才轮到应用层的认证和协议。这三层走完，大部分问题都能定位。

出口有没有真的生效

这一步最容易被跳过，因为配置看上去是成功的。但配置成功和流量真的从代理走，是两件事。

判断出口是否生效，看两个东西。一是 IP 有没有变：记下不走代理时的公网 IP，挂上代理再看一次，两者一样就说明流量根本没出去，后面查什么都是白费。二是归属地对不对：代理详情一般会给到国家、地区、州、省、城市，还有精确到小数点后六位的经纬度以及邮编，把这些跟购买时的地区信息对一遍。出口地区的系统时区如果明显对不上，也是隐患。

出口不生效，原因常常不在服务商那边，而在本机残留的设置。之前用过的网络工具退出时如果没清理干净，系统层可能还留着 HTTP_PROXY、HTTPS_PROXY 这类环境变量，或者 macOS 的网页代理、SOCKS 代理开关没有关闭。这种情况下客户端以为自己在按系统代理走，实际请求却绕开了。把这些残留清掉再测，比重配一遍代理更有用。

链路层常见的三类错误

出口确认没问题，接着看请求有没有真正到达目标。

域名解析是第一个卡点，表现为解析失败，或者解析出来的结果明显不对，本该指向目标服务的域名落到了一个奇怪的地址上。换一个公共 DNS 重新解析，或者清掉本地解析缓存，再看是否恢复。

连接超时是第二种。端口被防火墙或安全软件拦住时，表现就是一直转圈然后超时，这时候要确认端口放行规则，也顺便留意是不是企业内网、公共 Wi-Fi 这类环境本身有限制。有个判断很省事：不用代理直连，如果也打不开任何网站，那问题在基础网络，跟代理无关，重启路由器或切到手机热点验证一遍就能确认。

证书错误要单独说。提示证书不受信任、握手失败，很多人第一反应是流量被解密或证书被替换。这种可能确实存在，但还有一类更隐蔽的原因：本机时间不准。不少认证与会话机制依赖时间戳，本地时间与服务器时间差距超过 5 分钟，签名校验就会失败，表现出来是连接被拒；落在 HTTPS 上，就是证书校验过不去。看到证书错误，顺手看一眼系统时间同步状态，异常就开启自动同步并立即校准，校准完重启客户端再试。

认证和协议别填错

能连到代理服务器却仍然不通，问题多半在应用层。

最常见的是认证信息。代理的用户名密码、认证方式要跟服务商给的一致，改过密码没同步到配置里也很常见。手动配置模式下，还要确认填进去的端口号和代理工具自己监听的端口一致，这两个数字长得很像，填错就完全连不上。

协议不匹配是第二类。HTTP、HTTPS、SOCKS5 不能混着填：服务商给你的是 SOCKS5，配置里填成 HTTP，检查必然失败。另外代理是否允许访问目标站点和目标端口也要确认，部分代理会限制目标或协议。

判断是节点问题还是配置问题，最快的办法是换一个节点再测。换完能用，就是原节点的问题；换完照样不行，方向回到配置和链路。这时候别反复改参数，一次只变一个变量，改完记录结果，否则问题会被自己的操作掩盖掉。

连上了，不等于环境可用

补一个常见的坑。代理显示连接正常，账号却还是频繁触发风控，问题往往不在能不能连，而在这条出口看起来像不像一个正常用户。

要核对的还是那几项：出口归属地和账号注册地区是否一致；IP 类型是否合理，数据中心 IP 和住宅 IP 在平台侧的信任度不一样；这条 IP 之前有没有被目标站点标记过，同一条 IP 上如果跑过大量异常行为，会连累后来的使用者。连接测试通过之后，再确认一次出口的干净程度，这一步花不了几分钟。

如果一台设备上要跑多个环境，出口最好一对一：一个环境配一条自己的出口，出问题能单独定位，某条出口被标记也只会影响对应的那一个，而不是全部一起断。PurpleMark 在多环境管理里就是按环境分别配置出口和隔离的，逻辑正是这个。

排查方法仅供技术交流，相关工具与服务请在合法合规的前提下使用。