VPN 是否生效怎么查：出口 IP、DNS 与分应用验证

先看结论：连接状态不等于流量已经经过线路

客户端显示已连接，通常只说明本地客户端与远端节点之间完成了协议握手，或者系统已经接受了客户端创建的代理、虚拟网卡或 VPN 配置。它并不能单独证明浏览器、下载工具和其他应用都把流量交给了这条连接。

验证时应把问题拆成不同层次：出口 IP 是否改变，用于判断公网请求从哪里离开；DNS 请求交给谁解析，用于判断域名查询有没有绕过预期路径；目标应用是否实际命中代理或隧道规则，用于判断分流是否符合预期。只有这些结果互相吻合，才能认为当前访问确实按设定经过了线路。

检查出口 IP：确认网页请求从哪里离开

出口 IP 是最直观的检查项。断开 VPN 后，通过可信的 IP 查询页面记录当前公网地址和大致地区；随后关闭原页面、连接目标线路，再新开无痕窗口进行相同查询。如果地址或出口地区变为所选线路所在区域，说明这次浏览器请求已经到达远端出口。

对比时不要只刷新旧标签页。浏览器可能复用已建立的连接，也可能保留站点缓存。更稳妥的做法是关闭相关标签页，等待客户端确认连接后再重新打开浏览器窗口。若客户端提供连接日志，也可以同时观察访问查询页面时是否出现新的出站记录。

同时检查 IPv4 与 IPv6

部分网络同时提供 IPv4 和 IPv6，而客户端配置可能只接管其中一种。如果查询页面显示 IPv4 已经改变，但 IPv6 仍指向本地网络，支持 IPv6 的网站就可能优先使用未被接管的路径。这类情况经常表现为：某些网站显示线路地区，另一些网站仍判断为原网络地区。

处理方式取决于客户端能力。优先启用能够完整接管双栈流量的 TUN 或系统 VPN 模式；如果当前节点、协议或客户端无法处理 IPv6，可在明确理解影响后暂时关闭本地网络的 IPv6，再重新建立连接并复查。不要仅通过反复切换节点掩盖协议栈不一致的问题。

为什么出口地区与节点名称可能不完全一致

节点名称通常表示线路用途或预期出口区域，但 IP 数据库由不同服务维护，更新速度和归属判断可能不同。某个地址可能已经迁移到新的机房，查询页面却仍显示旧地区。因此，地区文字不一致时应结合公网地址是否变化、目标服务实际返回的内容区域以及客户端日志综合判断，而不是只依赖单一数据库。

IEPL 专线、中转和直连描述的是到达出口节点之前的传输方式。IEPL 通常侧重跨境段的专线承载，中转会先把流量送到中继节点，直连则由本地网络直接访问远端入口。这些线路类型会影响路径与稳定性，但最终网站看到的仍是出口节点的公网地址。仅凭出口 IP 无法反推出前段究竟使用了哪种承载方式。

检查 DNS：识别域名查询是否绕过预期路径

访问网站前，设备通常需要先把域名解析为 IP 地址。网页内容经过 VPN，并不必然表示 DNS 请求也经过同一线路。如果系统仍把查询发送给本地网络提供的解析器，就会形成 DNS 路径与内容流量路径不一致的情况，常被统称为 DNS 泄漏。

验证时可以使用 DNS 检查页面观察解析器所属网络与地区，但不要把“解析器地区必须和出口地区完全相同”当作唯一标准。公共解析服务可能使用就近接入，返回的节点名称也未必对应实际物理位置。更重要的是确认结果中是否持续出现本地网络的解析器，以及连接前后的解析路径是否发生了预期变化。

浏览器安全 DNS 会改变测试结果

现代浏览器可能启用基于 HTTPS 的 DNS，也就是常见的 DoH。此时浏览器会绕过系统 DNS 设置，直接向浏览器指定的解析服务发起加密查询。系统层 VPN 可能仍会承载这段连接，但解析器名称不会变成客户端配置的 DNS；如果使用规则代理，浏览器的 DoH 请求还可能因为规则不同而直连。

排查时应先查看浏览器的安全 DNS 设置，再查看客户端是否提供 DNS 劫持、虚拟 DNS、远程解析或遵循系统解析等选项。不要同时修改多处设置，否则很难判断是哪一项产生了效果。完成测试后，再根据隐私需求、兼容性和分流策略决定采用系统 DNS、客户端远程解析还是浏览器安全 DNS。

DNS 缓存会制造“修改无效”的假象

系统、浏览器和应用都可能缓存已经解析过的域名。切换线路后立即访问刚刚打开过的网站，应用可能直接使用缓存结果，不会产生新的 DNS 查询。此时 DNS 检查日志看不到请求，并不代表配置一定失效。可以关闭浏览器进程、清理系统 DNS 缓存，或者测试此前没有访问过的域名，再观察解析结果。

分流环境中的 DNS 必须与规则配合

规则模式会按照域名、IP、进程或规则集决定直连与代理。如果域名先通过本地 DNS 解析，客户端只能看到解析后的 IP，某些依赖域名的规则可能无法命中；反过来，如果所有域名都交给远程解析，本地站点可能得到不合适的地址。较成熟的客户端会通过域名嗅探、虚拟 IP 或按规则选择解析器来保持映射关系。

当问题只发生在特定域名时，应检查域名规则是否排在更宽泛的直连规则之后、规则集是否已经更新，以及该应用是否自行执行加密 DNS。DNS 结果正确但页面仍无法访问，则应继续检查路由、协议握手和目标服务限制，而不是持续更换解析器。

分应用验证：确认浏览器之外的程序有没有走线路

许多“VPN 已连接但应用无效”的问题，实际来自代理模式差异。系统代理只对主动遵循系统设置的程序生效；TUN 模式通过虚拟网卡接管更多系统流量；应用内代理则只影响设置过的那个程序。浏览器能打开目标网站，不代表游戏、命令行工具、同步软件或商店应用也使用相同路径。

用同一项测试分别检查不同应用

1. 断开连接，分别在浏览器和目标应用中记录当前可观察到的出口或访问结果。
2. 连接线路，确认客户端没有握手错误，并保持网络环境不变。
3. 在浏览器重新检查出口 IP，再在目标应用中执行相同类型的网络请求。
4. 查看客户端连接日志，确认目标域名、目标地址或进程是否出现，以及命中了代理还是直连规则。
5. 如果浏览器变化而目标应用没有变化，切换到 TUN 模式或为该应用设置客户端支持的独立代理。

一些应用会忽略系统代理，一些应用使用 UDP，还有一些应用在启动时建立长连接并持续复用。切换线路后，旧连接可能仍留在原路径上。测试前应彻底退出目标应用，再连接线路并重新启动。只关闭窗口未必会结束后台进程，需要在系统任务管理界面确认程序是否仍在运行。

规则模式、全局模式与直连规则

全局模式通常把客户端可接管的流量统一送往节点，适合用于快速判断问题是否由分流规则造成。规则模式则根据目标地址、域名或应用选择路径，更适合日常使用。如果全局模式正常、规则模式异常，重点应放在规则顺序、规则集版本、进程匹配和 DNS 映射，而不是协议本身。

本地网络、打印设备、局域网文件共享和部分本地服务通常需要保留直连。启用全局接管后如果这些服务不可用，不代表 VPN 失效，而可能是局域网绕过选项没有开启。验证跨境访问与维护本地网络连通性是不同目标，应分别检查。

系统代理与 TUN 模式的差别

协议与订阅正常，不代表系统路由已经正确

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可以作为客户端连接节点时使用的协议或传输方案，但它们解决的是客户端与服务端之间如何建立和承载连接。应用流量是否进入该连接，仍由客户端的系统代理、TUN、路由和分流配置决定。

例如，Shadowsocks、VMess、Trojan 或 VLESS 节点在客户端日志中显示握手成功，但系统代理没有启用，浏览器也未配置代理，那么网页仍可能直连。Hysteria2 与 TUIC 常使用基于 UDP 的传输，如果本地网络对 UDP 不友好，可能出现能够建立会话但实际请求不稳定的情况。此时可以比较其他协议线路的表现，并查看日志中的超时、重传或握手失败，而不是仅观察连接按钮颜色。

订阅链接只负责交付节点配置

订阅链接通常用于向客户端导入节点地址、端口、协议参数和线路名称。导入成功说明客户端能够读取并解析订阅内容，不等于节点已经连接，也不等于操作系统流量已经被接管。订阅更新后，还需要选择节点、启用对应接管模式并完成实际出口测试。

如果更新订阅后所有节点突然不可用，应先确认系统时间是否准确、客户端是否支持订阅中的协议、旧配置是否覆盖了新配置，以及网络是否阻断了节点入口。不要在多个客户端之间反复导入同一订阅后同时开启连接，多个系统代理或虚拟网卡互相竞争会让路由结果更难判断。

不同平台的检查重点

Windows

Windows 上应同时检查系统代理、虚拟网卡和路由表。部分桌面程序读取系统代理，部分程序直接建立网络连接。使用 TUN 模式时，客户端通常需要创建虚拟适配器并写入路由；如果权限不足、安全策略阻止驱动加载或其他网络工具修改了路由，界面可能显示连接成功，但流量不会按预期进入隧道。

macOS

macOS 客户端可能通过系统 VPN 配置、网络扩展或系统代理接管流量。首次启用时需要授予相应系统权限。如果系统设置中存在旧的 VPN 配置或其他网络扩展，应避免同时启用。浏览器正常而命令行工具直连时，通常需要确认当前使用的是系统代理还是完整隧道模式。

iOS 与 Android

移动平台通常通过系统 VPN 接口承载连接，但省电策略、后台限制和网络切换可能中断隧道。由无线网络切换到移动网络后，应重新观察系统状态栏中的 VPN 标记，并复查出口。Android 客户端还可能提供按应用代理或绕过应用列表，目标程序若被加入绕过列表，就会继续直连。

Linux

Linux 的网络栈与桌面环境组合较多，需要区分环境变量代理、桌面代理、TUN 设备和策略路由。图形浏览器可能遵循桌面代理，终端程序则可能读取自己的代理环境变量。使用 TUN 时应检查设备是否创建、默认路由和策略规则是否写入，以及 DNS 管理服务有没有覆盖客户端设置。

显示已连接但流量未经过线路：按顺序排查

排查的关键是一次只改变一个变量。先从最简单的连接与出口检查开始，再进入 DNS、分流和协议层。随意同时更换节点、协议、DNS 和客户端，会让问题暂时消失，却无法确认真正原因。

1. 确认基础网络可用。断开客户端后访问常用网站。如果基础网络本身中断，应先恢复本地连接。
2. 重建客户端连接。断开当前节点，关闭可能冲突的网络工具，再重新连接并查看握手日志。
3. 切换为全局接管进行对照。如果全局模式有效而规则模式无效，检查规则匹配与 DNS 配置。
4. 重新启动目标应用。结束后台进程，避免旧连接继续复用原路径。
5. 分别检查 IPv4、IPv6 与 DNS。确认没有出现部分流量进入线路、部分流量直连的双栈问题。
6. 检查系统时间与权限。时间偏差可能影响证书验证，权限不足可能阻止虚拟网卡或系统 VPN 配置生效。
7. 比较不同线路类型。如果特定入口在当前网络无法连接，可比较直连、中转或 IEPL 线路，但仍需通过出口测试确认结果。
8. 重新导入订阅。先移除失效或重复配置，再从可信来源导入，避免旧参数和同名节点造成混淆。

常见现象与对应方向

如果日志显示节点握手成功、出口 IP 也已经改变，但只有某个网站或应用不可用，问题通常已经不在“VPN 是否生效”这一层。此时应检查目标服务的地区规则、账号区域、缓存、应用版本与目标线路兼容性。不要把单个服务的访问结果直接等同于整条线路失效。

最终检查清单

• 未连接与已连接状态下的出口 IP 有明确差异。
• IPv4 与 IPv6 都按预期进入线路，或已明确处理不支持的协议栈。
• DNS 解析路径符合当前方案，没有意外回到本地解析器。
• 浏览器和目标应用分别完成测试，结果不是由单个应用设置造成。
• 客户端日志能看到目标请求，并显示命中预期的代理或直连规则。
• 订阅已更新，节点协议与当前客户端兼容。
• 系统中没有同时运行并争用代理、路由或虚拟网卡的其他工具。

完成这些检查后，可以较清楚地区分节点连接问题、系统接管问题、DNS 问题和应用分流问题。出口 IP 用于确认公网出口，DNS 检查用于确认解析路径，分应用测试用于确认实际程序是否命中规则；三者结合，比单看“已连接”状态可靠得多。