VPN连上了没生效?查出口IP和DNS的方法

VPN连上了没生效，最可靠的判断标准不是客户端上的绿色图标，而是实际流量从哪里离开设备、域名由谁解析，以及目标应用是否遵循了当前路由。连接状态只能说明客户端完成了某段握手或建立了本地代理端口，不能单独证明浏览器、下载工具和其他应用都已进入预期线路。

排查时不要同时修改线路、协议、DNS 和分流规则。变量一起变化，问题即使暂时消失，也很难知道是哪项设置起了作用。更稳妥的做法是先记录直连状态，再连接线路，依次检查出口 IP、DNS 与具体应用。每一步只回答一个问题。

先区分“已连接”和“流量已接管”

不同客户端所说的“连接成功”并不完全相同。使用系统级隧道时，客户端通常会创建虚拟网络接口，并向操作系统写入路由。使用系统代理时，客户端可能只是在本机开放一个 HTTP、SOCKS 或混合代理端口，再把系统代理指向该端口。还有一些客户端只启动本地核心，是否接管应用流量取决于浏览器设置、分流模式或单独配置。

因此，同一台设备上可能出现浏览器已经走代理、终端命令仍然直连的情况；也可能出现大部分网站经过线路，但局域网、特定域名或指定应用按规则直连。这不一定是故障，可能只是客户端执行了既定分流规则。问题的关键是：当前结果是否符合使用者选择的模式。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 等协议负责客户端与远端节点之间的数据传输，但“协议连接成功”和“系统流量进入协议核心”仍是两件事。无论采用哪一种协议，最终都要回到路由、代理设置、DNS 与应用行为上验证。只反复更换协议，通常无法修复系统代理未启用或应用主动绕过代理的问题。

第一步：对比连接前后的出口 IP

出口 IP 是访问目标站点时，对方服务器看到的公网地址。验证时应先断开线路，打开一个可信的 IP 查询页面，记下国家或地区、网络运营方与地址；然后连接目标线路，刷新同一个页面。若地址及其网络归属发生变化，并与所选线路的大致地区一致，说明这一次网页请求已经从代理出口离开。

测试前最好关闭查询页面再重新打开，或使用浏览器的隐私窗口，避免页面缓存旧结果。若浏览器安装了独立代理扩展，也要记录扩展是否启用。扩展可以覆盖系统代理，使浏览器结果与其他应用不同。测试期间应只保留一种接管方式，避免系统客户端与浏览器扩展叠加。

1. 断开客户端，关闭原有 IP 查询页面，再打开查询页并记录直连结果。
2. 连接准备验证的线路，等待客户端明确进入已连接状态。
3. 重新打开查询页，不要只读取旧标签页里已经缓存的文字。
4. 比较地址、地区和网络归属，不要只看地图上的定位点。
5. 换一个浏览器或独立应用复查，确认结果是否一致。

地图位置只能作为辅助信息。IP 数据库会根据注册信息、机房位置或历史记录推断地点，不同数据库的标注可能存在差异。判断是否切换出口时，地址变化和网络归属通常比地图图钉更有价值。如果所选节点位于日本，而查询结果显示为该线路使用的日本机房网络，测试方向基本正确；如果地址与断开前完全相同，则应继续检查代理接管方式。

出口 IP 没变化时检查什么

• ✅ 确认客户端不是仅启动本地端口，而是已经启用系统代理或虚拟网卡模式。
• ✅ 确认浏览器没有设置“直连”或使用另一个代理扩展覆盖系统设置。
• ✅ 检查当前分流模式是否把 IP 查询站点匹配到了直连规则。
• ✅ 退出其他网络代理工具，避免多个客户端竞争系统代理与默认路由。
• ❌ 不要只通过刷新旧页面判断，缓存内容可能没有重新发起完整请求。
• ❌ 不要连续更换多个协议与节点，这会掩盖真正的接管问题。

如果只有某个浏览器的出口没有变化，可以检查该浏览器是否启用了独立代理策略。部分浏览器遵循系统代理，部分命令行工具默认不读取系统代理，下载器和游戏也可能直接创建网络连接。系统代理模式本来就无法保证所有应用自动接入；需要整机接管时，应使用客户端支持的虚拟网卡或系统隧道模式，并确认路由写入成功。

第二步：检查 DNS 请求走向

DNS 负责把域名转换为可连接的地址。网页内容经过代理，不代表域名查询也一定经过同一路径。如果系统仍向本地网络指定的解析器发送查询，访问方可能得到与代理出口地区不一致的解析结果。对于使用区域调度的流媒体、下载镜像和内容分发网络，这种不一致可能表现为页面能打开但内容报错、节点选择异常或加载速度不稳定。

所谓 DNS 泄漏，通常是指按照当前隐私或路由目标，本应通过隧道或指定加密解析器发送的查询，却从本地网络接口交给了其他解析器。发现本地解析器不等于所有网页内容都在直连，但它说明 DNS 路径没有按预期统一，需要继续检查客户端的 DNS 接管选项。

验证方法与出口 IP 类似：先在断开状态记录解析器的网络归属，再连接线路并重新测试。重点看解析请求由哪一网络处理、地区是否与目标出口明显冲突，以及重复测试时是否仍混入本地网络提供的解析器。不要只看解析出来的网站地址，因为大型网站可能根据地区、缓存和负载返回不同结果。

nslookup example.com

# 查看系统当前 DNS 配置
# Windows
ipconfig /all

# macOS
scutil --dns

# 常见 Linux 环境
resolvectl status

这些命令解决的是不同问题。nslookup可以显示当前查询使用的解析服务器及返回结果；系统网络命令用于查看操作系统配置了哪些 DNS；它们都不能单独证明浏览器使用了相同解析器。现代浏览器可能启用安全 DNS，也就是通过 HTTPS 单独发送查询，从而绕开操作系统设置。排查浏览器与系统结果不一致时，应检查浏览器的安全 DNS选项。

DNS 结果异常的常见原因

客户端可能只代理 TCP 或 UDP 应用流量，却没有接管系统 DNS；虚拟网卡模式可能已创建，但 DNS 路由仍指向原网络接口；浏览器可能使用自己的加密 DNS；分流规则也可能规定国内域名直连解析、其他域名交给远端解析。最后一种属于常见的分流设计，不能仅凭解析器不同就判定故障，应结合目标域名的匹配规则判断。

修改 DNS 后若结果仍旧不变，可能是系统、浏览器或本地代理核心保留了缓存。此时先重启浏览器，再断开并重新连接客户端。仍无法更新时，可使用操作系统提供的 DNS 缓存清理功能。不要把“清理缓存”当成长期修复手段；如果每次连接都要手动处理，应该回到客户端 DNS 接管和路由设置查根因。

第三步：按浏览器与应用逐个验证

确认浏览器出口和 DNS 后，还不能直接推断所有软件都已生效。应用是否进入线路，取决于它是否遵循系统代理、是否被虚拟网卡接管、使用哪种传输协议，以及分流规则如何匹配目标地址。浏览器、终端、游戏平台、视频客户端和下载工具可能得到不同结果。

建议建立一张简单的验证记录：应用名称、预期路径、实际出口、DNS 表现和访问结果。先测试最重要的应用，不要用“某网页能打开”代替整机验收。若一个应用异常而其他应用正常，问题通常位于应用代理设置、协议支持或分流规则，而不是节点整体失效。

系统代理主要面向愿意读取代理设置的应用。虚拟网卡模式在网络层接管范围更广，通常更适合不支持代理设置的程序，但仍受路由优先级、排除规则和客户端实现影响。Windows、macOS、Android、iOS 与 Linux 的网络栈和权限模型不同，同一份订阅导入不同客户端后，可用的系统代理、虚拟网卡、按应用分流与 DNS 接管能力也可能不同。

订阅链接只负责向客户端提供节点与相关配置。导入成功说明客户端取得了配置，不代表操作系统已经授权建立隧道，也不代表分流规则适用于当前平台。首次导入后，应确认选择了节点、启用了正确模式，并处理系统弹出的网络配置授权。若订阅已更新但客户端仍使用旧节点，可在客户端内刷新订阅后重新选择线路。

全局、规则与直连模式如何影响结果

全局模式通常让更多目标进入代理，但局域网、客户端自身通信和必要的系统服务仍可能被排除。规则模式依据域名、地址、地区或进程决定代理与直连，最容易出现“部分生效”的观感。直连模式则会保留节点配置但不转发普通流量，适合临时停用代理；如果误选该模式，客户端可能仍在运行，出口却不会变化。

规则匹配还有先后顺序。某个域名若先命中直连规则，后面的代理规则就不会再处理它。域名解析后直接连接地址的应用，也可能绕过只按域名编写的规则。排查时可暂时切换到覆盖范围更广的模式进行对照：若应用随后恢复，节点本身大概率可用，问题应集中到原分流规则；完成对照后再恢复规则模式并修正匹配项。

看起来连上却没走代理的典型原因

客户端只启动了本地代理端口

部分桌面客户端允许核心独立运行。此时节点连接已经建立，本机也有可用代理端口，但系统代理开关没有打开，普通浏览器和应用仍然直连。解决方向不是更换节点，而是启用系统代理、为应用填写本地代理地址，或切换到虚拟网卡模式。

多个网络工具同时修改路由

两个客户端同时运行时，后启动的软件可能覆盖系统代理，虚拟网卡路由也可能产生优先级竞争。表面上看，两边都显示连接正常，实际流量却进入了另一条路径。排查时退出其他代理、过滤器和网络调试工具，只保留当前客户端，再重新比较出口。

浏览器缓存与长连接没有重建

切换线路后，已经打开的页面可能复用现有连接，DNS 结果也可能仍在缓存中。于是新打开的查询页显示新出口，旧标签页却保持原状态。关闭对应标签页或浏览器后重新测试，比连续按刷新键更可靠。对于长期保持连接的桌面应用，也应完全退出后再打开。

IPv4 与 IPv6 路径不一致

网络可能同时提供 IPv4 与 IPv6，而客户端只接管其中一种路径。目标站点若优先选择未被接管的协议族，就会出现出口与预期不一致。检查时应观察查询页分别报告的地址类型，并查看客户端是否明确支持和接管当前系统启用的协议族。不要仅关闭某种协议作为长期方案，优先修正客户端与路由配置。

规则让目标域名直连

规则模式下，广告过滤、局域网保留、地区分流和自定义规则都可能影响结果。IP 查询站点本身也可能被列入直连集合，导致测试页显示原出口，而其他目标已经经过代理。可换用另一个查询方法交叉验证，并查看客户端连接日志中的规则命中信息。日志用于确认域名匹配和出站选择，不应只盯着握手成功一行。

系统时间或证书校验异常

Trojan、VLESS 搭配 TLS 等配置依赖正确的证书校验，其他基于 TLS 或 QUIC 的传输同样可能受系统时间影响。若时间偏差导致握手失败，客户端通常会在日志中给出证书、超时或握手错误，而不是稳定进入可传输状态。此类问题应先恢复系统自动校时，再检查服务器名称、传输参数和订阅配置是否完整。

一套可重复执行的最终检查清单

完成单项排查后，用固定顺序再做一次验收。这样既能避免遗漏，也便于在更换网络、客户端或线路后重复使用。记录每一步的实际结果，比只保存一张“已连接”截图更有诊断价值。

• ✅ 断开线路并记录基准出口 IP、网络归属和 DNS 解析路径。
• ✅ 连接目标线路，确认客户端模式是系统代理、虚拟网卡还是本地端口。
• ✅ 重新打开查询页面，确认测试请求的出口发生预期变化。
• ✅ 检查 DNS 解析路径，并对照浏览器安全 DNS 与系统设置。
• ✅ 分别测试浏览器、终端和目标应用，不用单个网页代表全部流量。
• ✅ 查看分流规则命中结果，确认异常目标没有被意外分配到直连。
• ✅ 检查 IPv4 与 IPv6 是否由同一接管策略处理。
• ✅ 只改变一个变量后复测，并记录修改前后的差异。
• ❌ 不把客户端图标、节点名称或订阅导入成功当成最终证据。
• ❌ 不在原因未明确时同时更换节点、协议、DNS 和客户端。

如果出口 IP 已变化、DNS 路径符合预期，但特定应用仍无法使用，应把问题缩小到该应用：检查它是否支持系统代理、是否使用 UDP、是否拥有独立代理设置，以及是否被分流规则命中。若所有应用的出口都没有变化，则回到客户端接管方式、系统权限和路由写入检查。若出口反复变化或连接频繁中断，再查看客户端日志中的超时、握手和网络切换记录。

IEPL 专线、中转线路与公网直连描述的是节点之间或用户到出口之间的传输路径，不会改变上述验证原则。IEPL 通常强调专用跨境承载，中转线路会先到中转入口再转发到出口，公网直连则直接连接远端节点。无论线路结构如何，访问目标最终看到的仍是出口节点地址；本机是否把流量送入该线路，仍需通过出口、DNS 和应用测试确认。