代理客户端显示“连接成功”，打开IP查询页面却仍是原来的公网地址，最常见的原因不是节点失效，而是目标浏览器或应用没有走代理。客户端连上服务端，只证明认证和基础会话可能建立成功；流量是否被接管，还取决于系统代理、应用设置、PAC规则、协议、IPv4/IPv6和缓存。
先建立一份直连基线
关闭代理，记录当前IPv4、IPv6、DNS和本地网络。可以使用极跃圈收录的IP查询入口查看公网出口，再打开代理后用同一个页面复测。不要同时更换Wi-Fi、移动热点和浏览器，否则无法判断变化来自哪里。
测试时记录：
- 设备与操作系统；
- 浏览器或应用名称；
- 代理协议、服务器和端口；
- 全局、规则或直连模式；
- 测试前后的IPv4与IPv6；
- 发生时间和具体错误。
第一步：确认目标应用是否支持代理
浏览器可能读取系统代理，也可能使用自己的扩展或独立配置；命令行工具、游戏、下载器和桌面软件不一定跟随系统设置。先用一个明确支持代理的应用测试，不要假设“一处连接，全机生效”。
例如HTTP代理通常处理HTTP/HTTPS流量，SOCKS5适用范围更广，但应用必须正确配置。L2TP等系统级连接接管范围不同，也受路由表和分流策略影响。
第二步：检查服务器、端口和认证
地址填错、端口使用了另一种协议、用户名或密码过期，都可能让客户端界面处于不完整连接状态。查看客户端详细日志，不只看绿色图标。常见检查项包括：
- HTTP端口是否被误填到SOCKS5设置；
- 服务器地址是否带了多余空格或协议前缀；
- 账号密码、白名单或有效期是否正常；
- 节点是否要求特定客户端或认证方式；
- 系统时间是否导致令牌或证书验证失败。
第三步：排查PAC和分流规则
PAC或规则模式会根据域名决定直连还是代理。IP查询网站如果命中DIRECT，显示本地出口是预期结果。临时切换到全局模式进行一次低风险测试；若全局模式变化，说明节点可用，问题在分流规则。
修复时只调整自己需要的域名和规则，不要长期使用全局模式掩盖配置错误。企业设备还可能受到安全软件、组策略或浏览器管理策略覆盖。
第四步：清除连接与页面缓存
现代浏览器会复用HTTP/2、HTTP/3和已有连接。切换代理后，旧连接可能继续使用原路径。关闭相关标签页、重启浏览器或等待连接释放，再重新打开查询页面。某些页面也会缓存上一次检测结果，应强制刷新或选择另一家站内收录工具交叉验证。
不要只看页面显示的城市文字，核对完整IP是否变化。数据库属地未更新不等于IP没换。
第五步：分别检查IPv4和IPv6
代理可能只提供IPv4，而本地网络同时支持IPv6。浏览器访问双栈查询站点时，可能优先通过本地IPv6直连，于是页面显示的仍是本地地址。这属于代理范围或路由问题，不应简单称为“节点泄露”。
分别访问IPv4与IPv6检测，查看代理文档是否支持IPv6。需要严格统一出口的合规业务，应选择支持相应协议的方案或在受控网络中配置正确路由；不要随意关闭整个IPv6防火墙。
第六步：DNS和公网出口不要混为一谈
DNS查询可能由本地运营商解析，而HTTP请求经过代理；也可能两者都直连。DNS泄露检测能说明解析路径，不代表网页流量一定没走代理。SOCKS5客户端有时提供“远程DNS”选项，HTTP代理和系统隧道的处理方式又不同。
先确认公网请求路径，再单独核对DNS。一次改变一个变量，排查效率更高。
第七步：检查多层代理和旁路
浏览器扩展、系统代理、VPN、企业安全客户端、软路由和应用内代理可能同时存在。后启用的配置不一定覆盖前一个，甚至形成代理套代理。关闭无关工具，保留一条最简单路径测试，再逐层恢复。
虚拟机、容器和远程桌面也有自己的网络环境。在宿主机查询到的IP，不能代表虚拟机内应用的实际出口。
天行IP用户可以怎样核对
使用天行IP时，先从后台确认节点、协议、端口、有效期和认证方式。通过极跃圈天行IP收录页注册可填写邀请码 blsj；价格、测试资格、节点和配置以当前后台与官方说明为准。
如果仍未解决，向官方客服提供脱敏账号、节点、协议、客户端、时间和错误日志，不要发送密码、验证码或完整提取链接。
最终验证不要只做一次
- 关闭代理记录直连IPv4、IPv6和DNS；
- 启用代理，确认日志显示认证与连接成功；
- 在目标应用中分别测试IPv4和IPv6出口；
- 重启应用后复测，确认不是旧连接缓存；
- 访问自有或授权业务，检查功能、延迟与稳定性。
从“客户端有没有连接”走到“目标应用是否代理”，再检查规则、IPv6和DNS，通常能定位大多数“代理IP连上但IP没变”的问题。
