VPN连上了没生效？查出口IP、DNS与分应用验证新手完整指南

先分清“已连接”和实际接管流量

代理或 VPN 客户端通常需要完成若干独立环节：读取节点配置、与服务器建立会话、设置系统代理或虚拟网络接口、写入路由规则，然后按照分流策略处理请求。界面上的连接开关，多数只能概括前面几个环节。系统策略被其他软件改写、虚拟接口没有获得路由、应用忽略系统代理时，都可能出现开关亮着但访问路径没变的情况。

不同协议不会改变这套判断逻辑。Shadowsocks、VMess、Trojan 与 VLESS 常由代理客户端配合系统代理或虚拟网卡模式使用；Hysteria2、TUIC 等协议同样需要客户端把应用流量交给对应连接。协议握手成功只证明客户端能够到达节点，是否覆盖整台设备仍由客户端模式、操作系统路由和分流规则共同决定。

还要区分“系统代理”和“虚拟网卡”两种常见接管方式。系统代理依赖应用主动读取操作系统的代理设置，浏览器通常支持得较好，但部分游戏、命令行工具和独立更新程序可能忽略它。虚拟网卡模式会从网络层接管更多流量，覆盖面通常更广，不过仍受路由排除项、分流规则和本地网络设置影响。

用出口IP做第一轮核对

出口 IP 是最直观的检查项。先断开客户端，打开本站的 IP 检测 页面，记下当前地址与大致地区。随后关闭该页面，连接目标线路，再重新打开检测页。不要只刷新一个长时间未关闭的标签页，因为浏览器缓存、页面脚本状态或旧连接复用可能干扰观察。

1. 断开线路，确认客户端已经恢复未连接状态。
2. 打开 IP 检测页，记录原网络出口。
3. 关闭检测标签页，再连接准备使用的线路。
4. 重新打开检测页，比较地址和地区是否与所选线路相符。
5. 更换一个浏览器或无痕窗口复查，排除扩展程序和缓存影响。

如果地址没有变化，先检查客户端当前模式。规则模式可能把 IP 检测站判定为直连，因此检测到的仍是原出口。排障阶段可以暂时切到全局或虚拟网卡模式进行对照，但确认原因后应恢复适合日常使用的分流设置。不要长期保留临时排障规则，否则本地网站、局域网设备或办公资源可能走上不必要的远端路径。

如果地址发生变化，但地区与所选节点明显不符，先排除数据库标注差异。IP 地理信息来自不同数据库，城市级结果可能不一致，不能把单个页面的城市名称当作线路故障证据。更有价值的是确认地址是否从原网络出口变为另一个地址，以及多个检测来源是否大体指向目标国家或地区。

若浏览器检测正常，而其他软件仍使用原网络，问题通常已经从“线路是否连接”缩小到“应用是否被接管”。此时无需反复更换节点，应继续检查客户端模式和具体应用行为。

检查DNS解析有没有绕回原网络

访问域名时，设备通常要先进行 DNS 解析，把域名转换为可连接的地址。网页正文经过远端线路，并不自动保证 DNS 请求也走同一路径。如果系统继续把解析请求发送给原网络提供的解析器，就会出现常说的 DNS 泄漏。它不一定导致网页打不开，但会让解析路径与访问路径不一致，也可能造成地区判断错误、域名解析异常或分流结果偏差。

检查时应在断开与连接状态下分别运行 DNS 检测，比较解析器归属。连接后仍只出现原网络解析器，说明客户端的 DNS 接管可能没有生效；同时出现原网络与线路侧解析器，则可能存在并行解析、浏览器自带加密 DNS、系统缓存或多个网络接口同时工作的情况。

• ✅ 连接前后分别检测，并保存两次结果用于对比。
• ✅ 检查浏览器是否启用了独立的安全 DNS 设置。
• ✅ 检查客户端是否提供远程 DNS、代理 DNS 或防泄漏选项。
• ✅ 修改设置后关闭旧标签页，再重新发起检测。
• ❌ 不要因为出现陌生解析器，就直接判断线路异常。
• ❌ 不要只清理浏览器记录，却忽略操作系统的 DNS 缓存。

浏览器自带的加密 DNS 容易让结果变得复杂。它可能绕过系统 DNS 设置，直接连接浏览器指定的解析服务；也可能根据系统策略自动降级。排障时可以暂时让浏览器跟随系统设置，再观察客户端能否接管解析。确认路径后，再决定使用浏览器独立解析还是客户端统一解析，避免两套策略互相覆盖。

分流客户端还可能根据域名规则决定走向。DNS 解析若在规则匹配前后采用了不同策略，某些域名可能得到适合原网络的地址，随后却被送往远端线路；也可能得到线路侧地址，却被判定为直连。这类问题常表现为部分网站正常、部分网站超时，而出口 IP 检测看起来没有异常。

IPv6 也需要单独留意。原网络支持 IPv6、线路却只接管 IPv4 时，支持双栈的应用可能优先选择未被接管的 IPv6 路径。检查页面如果同时展示两类地址，应确认它们是否都符合预期。客户端没有接管 IPv6 时，可以在客户端内启用对应支持、调整路由策略，或在排障阶段临时禁用该路径进行对照。不要在没有记录原设置的情况下直接修改系统网络参数。

按应用逐个验证，不要只测浏览器

浏览器通过检测不代表整台设备已经接管。不同应用使用网络的方式并不相同：浏览器通常遵循系统代理；部分桌面软件使用自己的代理设置；命令行程序可能读取环境变量；游戏和实时通信工具可能直接发送 UDP；商店应用与系统服务还可能受到操作系统沙箱或后台策略约束。

验证时应选择实际要用的应用，而不是一次打开很多软件。先关闭应用，连接线路，再重新启动应用并访问一个能明确反映地区或网络出口的功能。已经运行的应用可能保留旧连接，即使系统路由发生变化，旧会话也不一定立即重建。

浏览器

先检查扩展程序。代理扩展可能覆盖系统代理，也可能只代理当前浏览器。如果客户端与扩展同时启用，实际路径可能出现重复代理或规则冲突。排障时保留一种接管方式即可。无痕窗口通常会停用部分扩展，适合做对照，但仍需确认浏览器是否允许扩展在无痕模式运行。

桌面软件与命令行工具

桌面软件如果提供“跟随系统”“不使用代理”或“自定义代理”等选项，应先确认它当前选择了哪一项。命令行工具则可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 等环境变量。旧终端窗口不会总是自动获得后来写入的变量，修改后应重新打开终端再测。

检查顺序
断开线路 → 记录原出口
连接线路 → 新开浏览器检测
重启目标应用 → 执行实际访问
对照客户端连接记录 → 确认是否命中规则
切换接管模式 → 再做一次对照

实时通信与使用 UDP 的应用

部分应用的登录请求走 TCP，而语音、视频或实时数据走 UDP，因此可能出现“能登录但通话异常”。需要确认节点协议、客户端和当前网络都能处理应用所需的 UDP 流量。系统代理模式对这类流量的覆盖通常不如虚拟网卡模式完整，排障时可以用虚拟网卡模式做交叉验证。

如果只有一个应用异常，而其他应用出口和 DNS 都正常，优先检查该应用自身设置、防火墙许可、旧连接和分流命中情况。此时继续更换线路往往不能定位问题。客户端如果提供连接记录，可查看目标域名或地址最终被标记为代理、直连还是拒绝；记录用于判断规则，不应只看流量总量。

常见的假连接现象与对应处理

“看起来连上了但没走线路”通常不是单一故障。下面这些现象可以帮助缩小范围。处理时一次只改一项，并在每次修改后重复相同检测；同时更换节点、协议、DNS 和模式，会让结果无法归因。

订阅链接与客户端配置也可能造成误判。订阅更新后，客户端内仍可能选中旧节点；同名节点不一定对应相同配置。遇到长期异常时，可以先刷新订阅，确认更新时间和当前选中的节点，再重新连接。不要把订阅链接直接粘贴到网页检测工具或发给他人，其中通常包含账户关联信息。

多个客户端同时运行也是常见冲突来源。一个客户端写入系统代理，另一个创建虚拟接口，关闭其中一个时又恢复旧设置，最终状态会很难判断。排障阶段应完全退出其他代理或 VPN 客户端，只保留当前测试的软件。仅关闭窗口不一定等于退出，需检查后台状态。

从 Wi-Fi 切换到有线网络、热点或休眠恢复后，原有虚拟接口和默认路由可能失效。客户端仍显示连接，是因为会话尚未及时更新。此时先断开再重连；如果仍无效，再退出客户端并重新启动。企业网络、酒店网络和公共网络还可能限制特定连接方式，换协议可以作为对照，但应先确认基本的网页访问本身正常。

按固定顺序完成最终复查

经过修改后，应从头执行一次完整复查，不要把前面不同设置下得到的结果拼在一起。最终结果应来自同一次连接、同一套规则和同一网络环境。下面的清单适合在更换客户端、导入新订阅或调整分流规则后使用。

• ✅ 断开状态下记录了原出口和 DNS 基线。
• ✅ 连接后出口地址发生预期变化，地区与所选线路大体一致。
• ✅ DNS 检测没有意外只显示原网络解析路径。
• ✅ IPv4 与 IPv6 的处理方式符合当前客户端配置。
• ✅ 浏览器扩展没有覆盖或重复客户端代理。
• ✅ 实际使用的桌面应用已经关闭重开并单独验证。
• ✅ 分流记录显示目标请求命中了预期规则。
• ✅ 临时使用的全局模式或测试设置已经恢复。
• ❌ 不把单个网站能否打开当作唯一判断依据。
• ❌ 不在一次排查中同时修改所有网络选项。

如果出口 IP、DNS 和多个应用都符合预期，可以认为当前连接已经正常接管需要处理的流量。如果只有个别应用失败，继续查应用设置与分流；如果所有应用都失败，回到系统代理、虚拟接口和路由层；如果出口正常但解析异常，则集中处理 DNS 与浏览器独立解析设置。按层定位比反复切换节点更稳定，也更容易复现。