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

VPN 连上了到底生效没？判断不能只看连接按钮。出口 IP 能说明某次请求从哪里出去，DNS 检查用于观察域名解析路径，分应用验证则确认真正要用的软件是否经过预期线路。把这些证据放在一起，才能区分正常分流与配置没有接管流量。

连接状态与实际流量不是同一件事

客户端的“已连接”可能表示隧道已经建立，也可能只是代理服务已启动、节点已选中。具体含义取决于客户端。订阅导入成功只说明配置能被读取；节点测试通过通常也只说明某项探测成功，不能据此推断所有应用的请求都会使用该节点。

在常见的代理客户端里，系统代理是把代理地址交给愿意遵循该设置的应用。浏览器通常能使用它，但其他软件可能使用自己的网络设置。TUN 或系统 VPN 模式则通过虚拟网络接口接管符合路由条件的流量，覆盖范围通常更广，但仍受排除应用、路由规则和 DNS 设置影响。

还要区分“全局代理”和“所有流量”。某些客户端的全局模式仅改变已进入代理内核的请求如何选路，不会自动让原本绕过代理的应用进入内核。排查时应分别核对接管方式、运行模式和应用设置，不要把相似的界面名称当成同一个开关。

先做出口 IP 的前后对照

先明确测试目标：是希望某个国际网站走代理，还是希望整个应用都走系统隧道。然后选择可信的公网 IP 查询页面，记录检测地址、时间、当前网络和客户端模式。检测服务会接收到你的访问请求，不必为了检查网络上传订阅链接、账号资料或客户端配置。

1. 建立直连基线。在允许直连测试的环境中断开代理，打开 IP 查询页面，记录公网地址及其地址族。若当前工作不能接受直连暴露，跳过这一步，不要为测试中断必要的保护。
2. 连接并核对模式。选择目标线路，确认系统代理或隧道接管已按计划启用。若使用规则模式，同时查看查询页面的域名将命中哪条规则。
3. 重新发起请求。重新加载检测页面，必要时关闭旧标签后再打开。记录新的地址，并查看客户端是否出现对应连接记录。
4. 交叉核对。用另一家可信检测服务复查，并比较地址归属信息。不同数据库的地区标注可能不同，不能仅凭地图上的城市判断连接失败。

如果地址没有改变，先看该检测网站是否被规则设为直连，再查浏览器是否使用独立代理或扩展配置。如果地址改变，只能确认这次网页请求改变了出口。还应留意 IPv4 与 IPv6：检测页面可能只展示其中一种，而目标应用可能优先使用另一种。

DNS 验证：看解析路径，不只看国家

DNS 把域名解析为网络地址。网页数据经过代理，并不自动意味着解析请求也由远端处理；反过来，使用远端 DNS 也不能证明网页数据经过代理。客户端可能采用本地解析、远端解析或按规则分流解析，浏览器还可能启用自己的加密 DNS。

常见 DNS 检测页面会让浏览器请求专门生成的测试域名，再观察哪些递归解析器参与查询。结果里的地址通常属于解析服务，不是你的网页出口。公共解析服务可能采用任播和分布式节点，显示本地地区或陌生国家，都不能单独作为泄漏结论。

更有用的办法是先读配置意图：哪些域名应本地解析，哪些应交给代理侧解析，加密 DNS 的连接本身又走哪条路。接着执行检测，对照预期解析服务，并检查客户端的 DNS 日志。如果预期所有目标域名都远端解析，却反复看到未经预期的本地解析路径，才需要进一步定位。

Windows 可用下面的 PowerShell 命令查看网卡 DNS 配置。这只是配置线索，不是最终路径证明；浏览器加密 DNS、客户端内置解析器或隧道重定向都可能改变实际行为。

Get-DnsClientServerAddress

排查时分别核对浏览器的安全 DNS 设置和客户端的 DNS 设置。只改变其中一项，再重新测试，避免同时切换多个开关而失去对照。清理缓存可以帮助重新触发解析，但不能修复错误路由；已有连接也可能继续复用旧地址，需要重新打开目标应用再观察。

逐个应用验证，避免浏览器通过就收工

列出实际使用的应用，选择其中能重复执行的网络操作，例如打开目标页面、刷新远程内容或建立新的服务连接。每次测试都记录应用名称、操作时间、目标域名及客户端日志中的匹配结果。若日志没有进程名，可以用操作时间和目标域名辅助关联，但不要把时间接近当成绝对证据。

• ✅ 浏览器：核对系统代理、扩展代理与加密 DNS 设置，确认正在测试的浏览器使用哪套配置。
• ✅ 桌面应用：查看应用自身的代理选项；如需使用系统隧道，核对该应用是否被排除。
• ✅ 命令行工具：查看环境变量和工具自己的代理参数，不用终端测试结果替代浏览器测试。
• ✅ 移动应用：确认系统 VPN 连接仍然存在，并检查客户端是否启用了按应用分流。
• ✅ 目标功能：分别验证登录、内容加载等实际操作，留意它们是否连接不同域名。

Windows 上，WinHTTP 代理与用户界面的系统代理不是同一套配置。可以用以下命令查看 WinHTTP 配置，但输出为直连不代表浏览器一定直连，也不要为了让输出一致就盲目修改它。

netsh winhttp show proxy

macOS 的网络服务代理、应用内部代理和隧道配置也应分别核对。Linux 的桌面代理设置未必被终端程序采用，终端还可能使用代理环境变量。Android 的按应用设置与 iOS 客户端的路由能力取决于具体实现，不应假定不同平台具有完全相同的菜单和行为。

在线游戏、语音和部分实时应用可能涉及 UDP。浏览器网页正常加载不能证明这些连接也被接管。应查看客户端与当前配置是否支持所需流量，再验证目标功能；不能仅凭协议名称判断某个应用一定可用。

“看起来连上了”的常见原因

检测页面走直连，目标网站却正常走代理

这通常是规则差异，而不是互相矛盾的结果。查看两个域名各自命中的规则与策略组。规则名称只是标签，还要展开确认策略组最终选中的出口。订阅链接负责分发配置，并不保证本地已有的规则覆盖关系符合你的目标。

浏览器出口改变，其他软件仍走原网络

优先检查接管范围。系统代理只对遵循它的应用有效，应用也可能使用独立代理、保持旧连接或被隧道排除。先完全退出目标应用再打开，观察新连接；若仍不符合预期，再依客户端说明调整接管方式，不要直接卸载系统网络组件。

IP 已改变，但服务仍显示原地区

服务可能结合账号地区、历史会话、定位权限、缓存及自身地址数据库判断地区。先把“网络出口验证”和“服务地区判断”分开记录。清理相关站点数据或使用新的浏览器会话可辅助排除缓存，但更换出口不保证目标服务改变地区或提供相同内容。

DNS 看起来符合预期，网页却无法打开

解析成功只意味着获得了地址，后续还可能遇到路由、证书、目标服务限制或连接失败。核对系统时间和浏览器错误提示，再查客户端日志。不要通过忽略证书警告来完成所谓验证，也不要在未确认来源的页面输入账号信息。

把排查收敛成可复现记录

遇到异常时，每轮只改一个变量，例如只切换规则模式、只换线路，或只调整某个应用的代理设置。固定目标操作并重新建立连接，才能判断是哪项变化产生影响。反复同时更换网络、客户端和配置，只会让“偶尔恢复”难以解释。

向支持人员反馈时，提供设备系统、客户端名称、测试时间、接管模式、目标域名、错误提示和脱敏后的相关日志。公网 IP 也属于敏感信息，应按沟通需要处理。订阅地址可能包含访问凭据，不要贴到公开讨论区；截图时遮住完整订阅链接和账号令牌。

需要核对 MHZVPN 的使用入口，可查看客户端使用教程；涉及线路选择时，可查看服务器目录。线路数量和覆盖地区是选择范围，不是某个目标应用必然可用的证明，实际使用仍应按本文步骤验证。