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

怎么确认 VPN 真的生效了，不能只看客户端是否显示“已连接”。这个状态通常只能说明本地代理核心已经启动，或者客户端与所选线路完成了握手；它不能单独证明浏览器、桌面软件和命令行程序的流量都经过了目标出口。可靠的判断需要同时检查出口 IP、DNS 解析路径和具体应用的实际行为。

验证前先明确连接模式。启用 TUN 的客户端通常会创建虚拟网络接口并接管系统路由；系统代理模式主要影响遵循操作系统代理设置的软件；浏览器扩展只处理对应浏览器中的请求；分流模式则会让部分目标走代理、部分目标保持直连。模式不同，“生效”的范围也不同，不能用同一项结果概括整台设备。

判断标准：出口 IP 符合所选线路、需要代理的域名由预期 DNS 路径解析、目标应用确实使用代理接口，三项结果能够互相印证，才算完成连接验证。

先确认客户端到底接管了什么

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都可以承载代理流量，但协议名称本身不决定系统流量如何进入隧道。真正影响覆盖范围的是客户端采用的入口方式，例如系统代理、TUN 虚拟网卡、应用内代理或手动配置的本地端口。即使节点连接正常，没有被导入代理入口的应用仍会直接访问网络。

连接方式	通常覆盖的范围	“已连接”通常代表什么	仍需检查的项目
TUN 模式	由系统路由送入虚拟接口的流量	虚拟接口与代理核心已经运行	默认路由、排除规则、IPv6 路径
系统代理	遵循系统代理设置的应用	本地代理端口已启动并写入系统设置	应用是否忽略代理、代理设置是否被覆盖
浏览器代理	指定浏览器或指定配置文件	扩展或浏览器代理配置处于启用状态	其他应用仍可能直连，浏览器 DNS 也需单独核对
分流模式	仅匹配规则的域名、地址或应用	规则引擎与线路可用	目标请求命中了代理规则还是直连规则

订阅链接也只是配置入口。客户端导入订阅后，会获得线路、协议参数和可能存在的分流规则，但导入成功不等于系统代理已经开启。部分桌面客户端将“选择节点”“启动核心”“设置系统代理”分成独立操作；移动平台则常通过系统的 VPN 接口接管流量。验证时应先查看当前模式，再判断测试结果是否合理。

✅ 已确认当前选择的是预期线路，而不是自动选择或上次使用的线路
✅ 已确认系统代理、TUN 或应用内代理至少有一种入口处于启用状态
✅ 已确认分流模式名称，并知道测试域名预期走代理还是直连
❌ 只看到客户端计时或状态变色，就直接认定所有应用已经接管
❌ 导入订阅后没有启动线路，也没有把流量送入本地代理接口

用出口 IP 做前后对照

出口 IP 是最直接的验证项。正确方法不是只在连接后打开一个查询页面，而是先断开 VPN，记录当前公网出口的地址、网络运营方和大致地区；随后关闭测试页面，连接目标线路，再重新打开查询。若地址与网络归属发生符合预期的变化，说明当前测试请求大概率已经经过代理出口。

暂时断开客户端，并关闭可能单独设置代理的浏览器扩展。
在浏览器中查询公网 IP，记录地址、网络归属和地区信息作为直连基线。
连接需要验证的线路，确认系统代理或 TUN 模式已经启用。
使用新的隐私窗口重新查询，避免旧页面缓存或长连接干扰结果。
再用另一个应用发起请求，检查是否得到相同的代理出口。

提示：IP 数据库的地区标签可能滞后，也可能只显示机房注册地。验证重点应放在出口地址和网络归属是否改变，不要仅凭城市名称判断线路失效。

如果连接前后地址完全相同，先不要立刻认定节点故障。浏览器可能启用了独立代理扩展，系统代理可能没有写入成功，目标站点也可能复用了连接前建立的长连接。关闭相关页面并重新打开，或换一个没有扩展的浏览器测试，可以排除这些干扰。

还要注意分流规则。规则模式下，国内站点、局域网地址或指定服务可能被设计为直连，因此查询直连目标时看到原网络出口并不矛盾。应选择明确命中代理规则的目标进行验证，或者临时切换到全局代理进行对照。完成测试后再恢复原来的分流模式，避免让不需要代理的流量长期绕行。

浏览器结果变化，其他软件却没有变化

这种情况通常说明代理只覆盖了浏览器。常见原因是启用了浏览器扩展，或者桌面客户端仅设置了系统代理，而目标软件选择忽略系统代理。游戏启动器、同步工具、命令行程序和部分基于自带网络栈的软件，都可能不读取系统代理设置。需要为应用单独配置代理，或改用能够接管其流量的 TUN 模式。

检查 DNS 请求是否沿预期路径解析

出口 IP 改变后，仍需检查 DNS。DNS 负责把域名转换为网络地址。如果网页请求经过代理线路，但域名仍由本地网络的解析器处理，访问目标和解析路径就出现了分离。这通常被称为 DNS 泄漏。不过，在明确设计的分流方案中，直连域名使用本地 DNS、代理域名使用远端 DNS 也可能是正常策略，判断时必须结合规则预期。

浏览器中的 DNS 检测页面可以显示参与解析的服务器及其网络归属。连接线路后，如果代理域名仍持续由本地网络提供的解析器处理，应检查客户端的 DNS 模式、远程解析选项和浏览器自身的加密 DNS 设置。浏览器可能绕过操作系统解析器，客户端也可能通过虚拟 DNS 或域名嗅探来配合分流，两者设置冲突时，结果会变得难以解释。

系统层面可以先查看当前 DNS 配置。以下命令只用于观察，不会修改网络设置：

Windows
ipconfig /all
nslookup example.com

macOS
scutil --dns
nslookup example.com

Linux
resolvectl status
nslookup example.com

nslookup 显示的是当前查询所使用的解析器，但它不一定完全代表浏览器的解析路径。若浏览器启用了自己的安全 DNS，系统命令和浏览器检测结果可能不同。因此，系统查询与浏览器查询都要看，并结合客户端日志中是否出现目标域名来判断。

不要只看解析速度：响应快慢受缓存、网络距离和解析器负载影响，不能证明 DNS 是否经过代理。应查看解析服务器的归属、客户端规则命中情况以及代理域名是否使用了预期的远程解析。

IPv6 为什么会让结果看起来矛盾

设备可能同时拥有 IPv4 与 IPv6 网络能力。如果客户端只接管其中一种协议，而浏览器优先选择另一种可用路径，就会出现部分请求经过线路、部分请求保持直连的情况。此时 IP 查询页面可能显示与预期不一致的出口，DNS 返回的地址类型也可能影响最终路径。

排查时应查看客户端是否声明支持 IPv6、TUN 接口是否获得对应路由、分流规则是否同时处理两类地址。不要把关闭 IPv6 当作永久通用答案；更稳妥的做法是确认客户端能够正确接管，或明确让系统不向目标应用提供未受管理的路径。

逐个应用验证，避免浏览器代表整台设备

浏览器测试通过，只能证明当前浏览器请求大概率走了预期出口。若使用场景包含会议软件、网盘、代码工具、桌面客户端或终端程序，还需要逐个验证。应用可能使用不同的代理读取方式，也可能绕过系统设置直接建立连接。

先保持目标线路连接，并确认浏览器出口已变化。
完全退出待测应用，再重新启动，避免沿用连接前建立的会话。
在客户端连接日志中观察该应用访问目标时是否产生新请求。
若客户端支持按进程或规则查看命中结果，确认请求进入了代理规则。
切换为直连后重复同一操作，对比应用行为与日志是否发生变化。

日志比“能不能打开”更有判断价值。某个服务在直连和代理环境下都能正常访问时，仅凭页面可用无法确认路径。客户端日志若显示目标域名、目标地址、规则名称和所选线路，可以把应用行为与实际转发路径对应起来。分享日志前应先移除订阅链接、认证信息和完整配置内容。

命令行工具也常出现单独配置。终端中的环境变量、工具自身的代理参数与系统代理可能互不相同。若浏览器出口已经改变，但终端请求仍走直连，应检查当前终端会话是否继承了旧的代理环境，或所用工具是否明确忽略系统代理。修改后重新打开终端，通常比在旧会话中反复测试更容易得到稳定结果。

分应用结论：同一台设备出现不同出口并不一定是故障。先确认这是分流设计、应用忽略系统代理，还是 TUN 路由遗漏，再决定是否需要调整模式。

显示已连接但流量未经过线路的常见原因

系统代理没有成功写入

客户端核心可以正常连接节点，但操作系统仍保留旧代理、手动代理或自动配置脚本。此时客户端会显示已连接，却没有应用把请求送进本地代理端口。可以先关闭其他代理工具，检查系统网络设置，再在客户端中重新启用系统代理。

TUN 路由被其他网络工具覆盖

虚拟机、容器、企业网络客户端和其他虚拟网卡都可能修改路由优先级。TUN 接口虽然存在，默认流量却被更优先的路由带走。排查时可暂时退出会修改网络路径的程序，重新连接线路，然后再逐项恢复，以确定冲突来源。

规则把测试目标判定为直连

域名规则、地址规则和地理规则可能给出不同结果。目标域名先经过 DNS 得到地址后，也可能被另一条地址规则覆盖。查看客户端日志中的最终命中规则，比只阅读规则列表更可靠。若全局模式测试正常而规则模式异常，问题通常位于规则或 DNS 配合，而不是线路握手。

浏览器保留旧连接或独立 DNS 设置

现代浏览器会复用连接，也可能启用自己的加密 DNS。连接 VPN 后直接刷新旧页面，未必会建立新的网络会话。完整关闭浏览器并重新打开，使用新的隐私窗口，再对比系统 DNS 与浏览器 DNS 结果，可以减少误判。

订阅更新后仍在使用旧配置

订阅更新可能改变线路参数或规则，但部分客户端需要手动切换到新节点，或者重新载入配置后才会应用。确认当前活动配置的名称、更新时间和所选线路，不要只看订阅列表中是否出现了新内容。订阅链接本身属于敏感凭据，不应粘贴到公开检测网站或截图中。

按固定顺序完成最终排查

面对“客户端显示已连接，但访问路径没有变化”，最有效的方法是从入口向出口逐层检查，而不是频繁更换协议或节点。每次只改变一个条件，才能知道是哪项设置造成结果变化。

✅ 核对当前配置、线路和连接模式是否符合预期
✅ 断开线路并记录直连出口，连接后使用新窗口重新对照
✅ 检查代理目标的 DNS 解析器与客户端 DNS 设置
✅ 分别测试浏览器、桌面应用和命令行程序
✅ 查看日志中的最终规则、目标地址与实际所选线路
✅ 检查 IPv6、虚拟网卡和其他网络工具造成的旁路
❌ 同时修改节点、协议、DNS 和分流规则，导致无法定位变量
❌ 把地区标签不精确直接当作连接未生效的证据

如果出口 IP 没有变化，优先检查流量入口与系统代理；如果出口变化但 DNS 路径异常，检查远程解析、浏览器 DNS 和分流策略；如果浏览器正常而单个应用异常，检查该应用是否读取系统代理以及是否需要 TUN 接管；如果只有部分目标异常，则重点查看规则命中和地址类型。这个顺序能够把问题缩小到客户端入口、DNS、路由或应用配置中的某一层。

完成标准：保存一份自己的直连基线，并在每次更换客户端、网络环境或分流规则后重新做出口 IP、DNS 与目标应用测试。结果一致时，不需要依赖客户端状态图标进行猜测。