怎么确认VPN真的生效了?查出口IP、DNS与分应用验证

怎么确认 VPN 真的生效了，不能只看客户端里的“已连接”。这个状态通常只表示客户端完成了握手、代理端口已经监听，或者系统里出现了虚拟网络接口；它不一定能证明浏览器、命令行工具和其他应用的请求都经过目标线路。可靠的判断需要同时查看出口 IP、DNS 请求去向和具体应用的实际路径。

验证时最重要的原则是做对照。先记录未连接时的网络状态，再连接线路并重复完全相同的请求。只看连接后的单次结果，很容易把本地网络原有的出口、浏览器缓存或安全 DNS 服务误认为线路效果。下面的流程不依赖客户端品牌，也适用于系统代理、TUN 模式、原生 VPN 配置和浏览器扩展等常见接入方式。

判断标准：图标、握手与实际流量不是一回事

一次连接可以分成配置加载、协议握手、系统接管和应用发出请求几个环节。订阅链接只是配置分发入口，导入成功只能说明客户端读取了节点信息。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 等协议完成握手后，客户端仍需通过系统代理、虚拟网卡或应用内代理把流量交给该连接。

因此，准确结论不是“客户端亮灯”，而是“预期接管的应用，其新建请求从目标出口发出，域名解析也符合当前配置”。如果启用了分流，部分请求保持直连反而可能是正常行为，关键在于结果是否符合规则，而不是所有流量是否呈现同一个出口。

基线记录与出口 IP 对照

出口 IP 是最直接的第一层检查。关闭连接后，通过可信的 IP 查询页面记录公网地址、网络运营方和大致地区；随后连接目标线路，刷新查询结果。若地址和网络归属发生变化，说明当前查询请求确实经过了另一个公网出口。

• ✅ 断开线路，关闭可能自动接管流量的浏览器扩展，并记录当前出口信息。
• ✅ 连接目标线路，等待客户端显示握手完成，再新建浏览器标签页进行查询。
• ✅ 对比公网地址、自治网络归属和地区，不只看地图上的城市名称。
• ✅ 分别检查 IPv4 与 IPv6；双栈网络可能让两类请求选择不同路径。
• ✅ 使用另一个预期被接管的应用复查，避免把浏览器独有的代理设置当成全局结果。

地区名称只能作为辅助信息。IP 数据库可能把同一地址段标在机房注册地、网络运营方所在地或相邻城市，因此城市不完全一致不等于线路失效。更有价值的是公网地址是否改变、网络归属是否符合节点类型，以及多次新建请求是否保持在预期出口。

如果连接前后地址完全相同，先不要反复切换节点。应检查当前模式是否只开启了本地代理端口，却没有打开系统代理或 TUN；还要确认查询页面是否被分流规则判定为直连。浏览器扩展也可能覆盖系统设置，使浏览器与其他应用呈现相反结果。

域名解析：DNS 归属与泄漏判断

DNS 负责把域名转换为可连接的地址。网页流量经过线路，但 DNS 查询仍交给本地网络解析器时，访问的域名信息可能沿着不同路径发送。这通常被称为 DNS 泄漏。判断重点不是“DNS 所在国家必须与出口完全相同”，而是解析器是否符合客户端、系统或浏览器中设定的方案。

现代浏览器可能启用加密 DNS，并直接使用浏览器指定的解析服务；Android 的专用 DNS、系统网络配置和客户端内置 DNS 也可能互相覆盖。此时查询结果显示第三方解析网络并不自动等于泄漏。需要先确认是谁负责解析，再判断这条路径是否符合预期。

各桌面平台都能查看当前解析配置。下面的命令用于观察系统状态，不会直接证明浏览器是否绕过系统 DNS，但能帮助定位配置来源：

Windows
ipconfig /all

macOS
scutil --dns

Linux
resolvectl status

Windows 输出中可查看活动网络接口使用的 DNS 服务器；macOS 的结果会列出不同作用域的解析器；采用 systemd-resolved 的 Linux 环境可查看各接口的 DNS 与默认路由状态。若客户端使用 TUN 并接管解析，通常能在相关虚拟接口或客户端配置中找到对应线索。

浏览器侧还要单独查看安全 DNS 设置。如果浏览器强制使用自定义解析器，系统命令显示的服务器可能根本没有处理网页查询。相反，某些客户端会拦截系统 DNS 并在隧道内转发，此时本机看到的地址只是接收入口，最终递归解析器可能位于其他网络。

分应用请求：找出谁在直连

出口 IP 页面只能证明发起查询的那个应用走了线路。浏览器正常，不代表终端、下载工具、游戏平台或桌面通信软件也采用相同路径。最稳妥的方法是按应用做相同请求，并把结果与接入模式对应起来。

系统代理通常只影响主动读取系统代理设置的软件。有些命令行工具、游戏和自带网络栈的应用会忽略该设置。TUN 模式通过虚拟网络接口接管更广泛的 IP 流量，但仍可能受路由排除项、应用绕过规则和局域网直连规则影响。浏览器扩展的范围更窄，通常只处理该浏览器内部支持代理的请求。

1. 先在浏览器中检查出口，并记录结果。
2. 再用命令行网络工具请求同类出口查询接口，比较网络归属。
3. 打开需要验证的桌面或移动应用，触发一个新请求，而不是观察缓存内容。
4. 查看客户端连接日志或活动连接列表，确认是否出现目标域名、目标地址或对应进程。
5. 切换为全局规则做短暂对照；若全局模式正常而分流模式异常，问题通常位于规则匹配。

客户端日志比“网页能不能打开”更适合定位分流。若日志把请求标为直连，应检查域名规则、IP 规则、进程规则和规则优先级。域名在解析后可能连接到内容分发网络地址，只写域名规则而实际匹配发生在 IP 阶段时，也可能得到与预期不同的路径。

还要区分连接测试和业务可用性。线路握手成功、出口变化，证明传输路径基本成立；目标服务仍然报错，则可能与账号地区、缓存、浏览器存储、时间设置或服务自身策略有关。此时继续修改代理端口通常不能解决应用层问题。

典型误判与对应修法

只启动客户端，没有启用系统接管

不少代理客户端允许“启动核心”与“设置系统代理”分开控制。前者只在本机监听代理端口，适合手动填写代理的应用；后者才会修改系统代理设置。如果希望覆盖更多不读取系统代理的软件，应在客户端支持的情况下评估 TUN 模式，并检查虚拟网卡权限是否已授予。

分流规则把测试目标设为直连

规则模式会根据域名、地址、进程或规则集决定路径。出口查询网站若命中直连规则，就会显示本地出口，但其他目标可能已经通过线路。排查时可暂时切换到全局模式做对照，确认线路本身无误后，再回到规则模式修正规则。

IPv4 经过线路，IPv6 保持直连

双栈网络会根据域名返回结果和系统路由选择协议族。若客户端只接管 IPv4，而应用优先建立 IPv6 连接，查询结果可能暴露本地 IPv6 出口。修复方式不是盲目关闭系统功能，而是先确认客户端是否支持对应流量，再调整 TUN、路由或 DNS 返回策略。

浏览器和系统使用不同 DNS

浏览器安全 DNS 可以绕过系统解析设置，系统的专用 DNS 也可能优先于客户端配置。应明确选择一种受控方案：由浏览器自行加密解析，或由客户端在隧道内统一处理。多层设置同时开启时，结果虽然可能可用，但排错会变得困难。

旧连接没有随线路切换

应用可能复用已有连接，连接池和后台进程也可能继续保持旧路径。切换节点后，应让测试应用建立新连接。退出应用、重新打开页面或清理相关连接状态，比连续点击刷新更能排除旧会话干扰。

• ✅ 浏览器变化、其他应用不变：检查系统代理适配范围，或改用合适的 TUN 接管。
• ✅ 全局模式变化、规则模式不变：检查直连规则、规则顺序与进程匹配。
• ✅ IP 变化、DNS 仍走本地网络：检查客户端 DNS 接管和浏览器安全 DNS。
• ✅ IPv4 变化、IPv6 不变：检查双栈路由与客户端协议族支持。
• ✅ 所有出口都正确但目标服务异常：转向账号、缓存、地区判定和应用层错误排查。

平台差异：同一配置为何结果不同

Windows 上，系统代理与路由表是两套不同机制。浏览器可能读取系统代理，而命令行程序未必读取；TUN 模式则依赖虚拟网卡和路由。可以使用 route print 查看默认路由及虚拟接口是否参与转发，同时结合客户端日志判断具体请求。

macOS 的系统代理按网络服务保存，而基于 Network Extension 的客户端可以建立系统级隧道。若同一台设备安装了多个网络扩展，应避免同时启用相互冲突的接管方式。查看 scutil --proxy 可以了解系统代理状态，scutil --dns 则用于核对解析作用域。

iOS 上，系统状态栏的 VPN 标记只说明配置处于活动状态。浏览器、应用内请求和 DNS 是否符合预期，仍需通过出口与实际业务请求验证。部分应用可能使用缓存内容，因此切换线路后应触发新加载。由组织管理的按应用 VPN 与普通个人配置也不是同一种接管范围。

Android 同时存在 VPN 服务、始终开启连接、专用 DNS 和应用排除列表。若某个应用被排除，它会保持直连；若专用 DNS 独立启用，解析路径也可能与客户端不同。验证时应检查客户端的分应用设置以及系统网络设置，而不是只看钥匙或 VPN 图标。

Linux 的桌面网络管理器、环境变量代理和 TUN 路由可以并存。终端工具是否使用代理，取决于工具自身配置和环境变量；系统级路由则影响更广。可用 ip route 查看路由，用 resolvectl status 查看解析器，再结合目标进程的连接记录判断。

完整复核：按固定顺序缩小问题范围

当结果互相矛盾时，不要同时修改协议、节点、DNS 和分流规则。一次只改变一个变量，才能知道哪项设置真正影响结果。建议先验证线路基础连通，再验证系统接管，最后处理应用规则与 DNS。

1. 断开连接，记录浏览器、命令行和系统 DNS 的基线状态。
2. 连接线路，确认客户端完成握手且没有持续报错。
3. 新建浏览器请求，对照出口 IP 与网络归属。
4. 检查 IPv4、IPv6 和 DNS 是否符合当前接管方案。
5. 对需要使用线路的应用分别发起新请求，并查看客户端日志。
6. 若应用结果不同，依次检查系统代理、TUN、应用排除项和分流规则。
7. 恢复日常规则后再次复测，确保排查时的临时全局设置没有掩盖问题。