怎么确认VPN真的生效了:查IP、查DNS新手完整自查

怎么确认VPN真的生效了，不能只看客户端是否显示“已连接”。这个状态通常只能证明客户端完成了握手，不能单独证明浏览器、命令行工具和其他应用的流量都经过隧道。可靠的检查需要建立断开时的基线，再依次核对出口 IP、DNS、IPv6、系统路由和应用分流。

最实用的方法不是寻找某个“一键通过”的结果，而是做连接前后的同条件对照。使用同一设备、同一网络和同一个检测页面，记录断开与连接时的差异。如果出口地址已经变化，但 DNS 仍由本地网络提供，说明网页流量和域名解析可能走了不同路径；如果浏览器变化而其他应用不变，通常与系统代理、TUN 模式或分应用规则有关。

先建立未连接时的网络基线

检查之前先完全断开客户端，并确认没有其他代理、浏览器扩展或旧连接仍在运行。打开本站的 IP 检测页面，记录当前出口 IP 所属的网络运营方、国家或地区以及地址类型。这里的重点是“对照”，不是判断基线地址本身是否正常。

随后查看当前使用的 DNS 解析器。不同检测工具对解析器名称和地区的识别可能不一致，因此不要只盯着地图位置。更有价值的信息是解析器是否明显属于本地网络服务商、路由设备，或者此前手动设置的公共 DNS 服务。

• ✅ 断开客户端后刷新 IP 检测页面，记录出口网络与地区。
• ✅ 关闭可能独立代理流量的浏览器扩展，避免基线被旧配置影响。
• ✅ 记录 DNS 解析器名称，不把地理位置偏差直接判定为泄漏。
• ✅ 确认设备当前连接的是预期网络，排除网络切换造成的出口变化。
• ✅ 保留检测页面，在建立连接后使用相同页面重新测试。

连接后检查出口 IP 是否切换

启动客户端、选择线路并等待状态稳定，然后回到原检测页面重新加载。全局隧道模式下，公网出口通常应从本地网络的出口切换到所选线路对应的出口网络。若地址、网络运营方和地区均未发生符合预期的变化，应先按“未生效”处理，而不是继续依赖客户端图标。

出口 IP 发生变化是必要检查，但仍不是完整结论。浏览器可能通过扩展或系统代理进入线路，而其他应用继续直连；反过来，启用 TUN 后，大部分系统流量可能已经进入隧道，但被规则指定为直连的网站仍会显示本地出口。测试时必须先弄清客户端当前采用的是全局、规则还是直连模式。

为什么只查一个网页还不够

系统代理主要影响愿意读取系统代理设置的应用。部分命令行工具、游戏、更新程序和自带网络栈的软件可能忽略这项设置。TUN 模式则创建虚拟网络接口，并通过系统路由接管更多流量，但仍可能受到排除规则、接口优先级和系统权限影响。

浏览器扩展的覆盖范围更窄，通常只处理该浏览器中的请求。看到网页出口已经变化，并不能据此推断整个设备都已进入隧道。需要保护其他应用时，应检查客户端是否启用了系统代理或 TUN，以及目标应用是否被放入绕过列表。

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

访问网站时，设备通常先把域名交给 DNS 解析器，再连接解析出的服务器地址。即使网页数据已经经过隧道，DNS 查询仍可能被浏览器、安全软件、操作系统或本地网络单独处理。所谓 DNS 泄漏，关注的正是解析请求是否意外离开预期路径。

连接线路后运行 DNS 检测，并将结果与基线比较。如果仍出现本地网络服务商的解析器，而客户端说明 DNS 应由隧道接管，就需要排查。若结果显示公共 DNS 或线路提供的解析器，则不能仅因解析器所在地与线路地区不同就认定异常。公共 DNS 广泛使用任播网络，检测数据库也可能把同一个服务标注到不同地区。

浏览器加密 DNS 会改变结果

部分浏览器可独立启用加密 DNS。启用后，域名请求可能绕过操作系统默认解析器，直接发给浏览器配置的服务。这个行为不一定意味着泄漏，但它会让浏览器与其他应用使用不同的解析路径。排查时应查看浏览器的安全 DNS 设置，并确认它是否符合当前需求。

如果希望所有应用统一由客户端处理 DNS，可先暂时关闭浏览器独立解析，再重新检测。若关闭后结果恢复正常，问题通常位于浏览器设置而不是节点协议。若结果仍指向本地网络，则继续检查客户端的 DNS 接管、TUN 权限和系统网络配置。

排查 IPv6、WebRTC 与分流规则

部分网络同时提供 IPv4 和 IPv6。如果客户端只接管 IPv4，而系统仍优先通过 IPv6 访问目标，检测结果就可能出现两套出口：IPv4 来自线路，IPv6 来自本地网络。这种情况通常称为 IPv6 泄漏。

处理方式取决于客户端能力。支持完整双栈 TUN 的客户端可以同时路由两类流量；有些客户端会在连接期间关闭未接管的 IPv6；另一些则要求在系统网络设置中单独处理。不要在不了解影响时长期修改系统配置。更稳妥的顺序是先升级客户端配置、检查 TUN 和 DNS 选项，再根据客户端文档调整系统网络。

WebRTC 是浏览器中的实时通信能力。检测页面有时会展示本地接口地址、虚拟接口地址或经过匿名化处理的候选地址。看到局域网地址不等于公网出口已经泄漏，因为局域网地址本身不能直接代表外部访问路径。判断重点仍是是否暴露了不应出现的公网直连出口。

分流会让不同网站看到不同出口

规则模式会按照域名、IP、应用或规则集决定走线路还是直连。比如本地服务可以直连，国际网站通过线路。此时两个检测页面得到不同出口并不一定是故障，可能只是它们命中了不同规则。

排查分流时，先把客户端临时切换到全局模式，再重复出口和 DNS 检查。如果全局模式正常、规则模式异常，说明连接与节点本身大概率可用，问题更可能在规则匹配。接着查看客户端连接日志，确认检测域名命中了代理、直连还是拒绝规则。

1. 断开当前连接，记录 IP 与 DNS 基线。
2. 启用全局模式并重新连接同一线路。
3. 刷新同一检测页面，核对出口、DNS 与 IPv6。
4. 恢复规则模式，再观察结果是否改变。
5. 查看连接日志中的域名匹配与最终出站。
6. 修正规则后重新测试，不用旧页面结果代替新请求。

按平台确认路由是否真正改变

不同平台给客户端的网络权限不同，检查入口也不完全一致。Windows 和 macOS 通常同时存在系统代理与虚拟网络接口两种实现；Linux 更常直接查看路由表、策略路由和 DNS 服务；iOS 与 Android 主要通过系统提供的 VPN 接口工作，应用侧可见的底层路由信息较少。

Windows

在客户端内确认当前模式。如果只启用了系统代理，浏览器可能正常，而忽略代理设置的程序仍然直连。需要更广覆盖时，检查客户端是否支持并启用 TUN，同时确认虚拟接口没有被安全软件阻止。可在终端运行以下命令查看路由表：

route print

检查是否出现由客户端创建的虚拟接口，以及默认路由或目标网段是否指向该接口。路由表内容因客户端实现而异，不能只凭接口名称判断；应结合连接日志和出口检测一起确认。

macOS 与 Linux

macOS 可通过系统网络设置查看代理状态，也可检查路由表是否出现隧道接口。Linux 桌面环境、网络管理服务和命令行客户端的组合较多，尤其要留意策略路由与 DNS 服务是否同时更新。

netstat -rn
ip route

macOS 环境通常使用前一条命令查看路由；Linux 可使用后一条。若客户端采用透明代理，还可能借助系统防火墙规则重定向流量，此时仅查看默认路由未必能呈现全部路径，需要结合客户端日志判断。

iOS 与 Android

移动端通常会显示系统级 VPN 状态，但状态图标仍只代表系统接口已经建立。应在连接前后使用同一 IP 检测页面对照，并检查客户端是否启用了按应用绕过、仅代理选定应用或本地网络直连等选项。

如果切换网络后连接状态仍在，但网页无法访问，可先断开再重新建立隧道。网络接口变化可能导致旧会话失效，而客户端界面尚未及时更新。若某个应用始终直连，则检查该应用是否被分应用规则排除。

协议、订阅与线路类型不会替代验证

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可以承载代理流量，但协议名称本身不能证明系统流量已经进入隧道。Shadowsocks 属于加密代理协议；VMess 与 VLESS 常见于支持多种传输方式的客户端；Trojan 通常使用 TLS 外观承载连接；Hysteria2 与 TUIC 基于 QUIC 方向的传输设计，更关注复杂网络下的传输表现。

这些协议解决的是客户端与服务器之间如何传输数据。系统代理、TUN、DNS 接管和分流规则解决的是“哪些请求会交给这个连接”。节点握手成功，只能说明客户端能够与服务器通信。如果应用没有被路由到对应出站，它仍可能使用本地网络。

订阅链接也只是配置分发入口。导入订阅后，客户端会获得节点、名称和相关参数，但仍需要选择可用节点、建立连接并启用正确的系统接管方式。订阅更新成功不等于当前节点已经连接，节点被选中也不等于系统代理或 TUN 已经开启。

IEPL 专线、中转与直连描述的是客户端到线路出口之间的上游路径。直连通常由设备直接连接远端入口；中转会先进入中间节点，再转发到出口；IEPL 专线通常强调运营侧跨境传输链路。无论上游采用哪种路径，本地验证方法都相同：检查请求是否被客户端接管、出口是否符合预期、DNS 是否按配置处理。

看起来连上了但没有生效的常见原因

如果客户端显示已连接，而检测结果仍是本地出口，可按下面顺序处理。每次只改一项，然后重新连接并测试。一次修改多项设置会让故障来源变得难以判断。

• ❌ 只选择了节点，没有打开系统代理或 TUN。
• ❌ 浏览器扩展已经连接，但其他应用不受扩展控制。
• ❌ 检测网站被分流规则指定为直连。
• ❌ 目标应用位于按应用绕过列表。
• ❌ 系统中仍有旧代理配置，流量被交给另一个本地端口。
• ❌ TUN 所需权限未授予，虚拟接口没有正确建立。
• ❌ IPv4 已进入线路，但 IPv6 仍沿本地网络外出。
• ❌ 浏览器独立 DNS 与客户端 DNS 策略不一致。
• ❌ 网络切换后旧会话失效，客户端状态尚未刷新。
• ❌ 多个客户端同时修改系统代理或路由，配置互相覆盖。

遇到多个客户端冲突时，应先全部断开，退出不使用的客户端，再清理系统代理并重新连接。切换客户端前先断开当前连接，可减少旧虚拟接口、旧 DNS 和残留代理状态带来的干扰。

若只有特定网站无法访问，不要立刻判断整条线路失效。先测试其他网站，再观察 DNS 是否能解析、连接日志是否命中拒绝规则，以及网站是否主动限制当前出口。整条线路故障通常会影响多个目标；单一网站异常更可能与分流、解析、出口限制或站点自身状态有关。

形成可重复的完整自查流程

一套稳定的验证流程应当能够重复执行，并且每一步都有明确结论。先断开连接建立基线，再用全局模式验证线路基础能力，之后才恢复日常分流。这样可以把节点问题、系统接管问题和规则问题拆开处理。

1. 关闭其他代理与扩展，断开客户端。
2. 记录本地出口网络、地区、DNS 和 IPv6 状态。
3. 连接目标线路，确认系统代理或 TUN 已启用。
4. 在同一页面重新检查出口 IP。
5. 运行 DNS 检测，核对解析器归属。
6. 检查 IPv6 是否进入隧道或被正确处理。
7. 分别测试浏览器与实际要使用的应用。
8. 恢复分流规则，查看目标域名命中的出站。
9. 切换网络后重新执行关键检查，不沿用旧结论。

最终判断不依赖单个绿色提示，而依赖多项结果是否一致。出口 IP 证明当前请求从哪里离开公网，DNS 说明域名由谁解析，IPv6 检查补足双栈路径，应用测试则验证分流范围。四者都符合当前配置，才能较有把握地确认 VPN 已经按预期生效。