怎么检查VPN是否生效:出口 IP、DNS 一次查清

怎么检查VPN是否生效？先对比出口 IP，再核对 DNS，最后验证目标应用。客户端显示“已连接”，只说明连接状态，不能单独证明所有请求都经过所选线路。检查结果必须和当前模式、分流规则一起看。

本文按实际排查顺序展开。目标不是让检测页的所有字段都显示同一个地区，而是确认：该走代理的请求确实走了代理，域名解析符合配置，直连请求也符合自己的预期。

先确定“生效”的检查范围

系统隧道、系统代理和浏览器代理的覆盖范围不同。系统代理通常只影响遵循该设置的软件；浏览器扩展可能只接管浏览器请求。隧道模式可以接管更广的流量，但仍会受到路由、排除应用和分流规则影响。不能看到系统里的 VPN 图标，就推断每个应用都已接管。

规则模式下，本地网站直连、国际网站走代理可以同时成立。检测出口 IP 的网站也可能命中直连规则。客户端中的“全局”往往表示已接管的请求统一选择代理，不代表它自动捕获所有应用流量。

检查前记下当前模式、节点名称、浏览器安全 DNS 设置，以及是否启用了隧道。之后每次只改一个条件，才能知道结果为什么变化。

出口 IP：先建立连接前后的对照

出口 IP 是远端网站看到的公网地址，不是设备在局域网里的地址。在断开连接时，用浏览器打开可信的公网 IP 检测页，记下地址与网络归属。然后连接所选线路，在同一浏览器重新发起检测。不要直接拿很久以前的截图作对照，本地网络的公网地址也可能变化。

1. 断开连接，记录当前网络下的公网 IP；若检测页分别显示 IPv4 与 IPv6，都保留结果。
2. 连接线路，确认客户端没有握手失败、认证失败或配置错误提示。
3. 重新加载检测页，必要时用新的隐私窗口排除页面缓存影响。
4. 打开客户端连接记录，确认检测域名命中了哪个规则、选用了哪个出口。
5. 换一个独立检测来源核对地址，不只看地图上的城市名称。

连接后地址改变，且日志显示该请求经过所选代理，才形成较完整的证据。地理位置数据库可能陈旧，城市显示不准并不等于线路失效。判断时优先看地址、网络归属与请求路径，不能只凭国旗或地区标签下结论。

地址没有改变，也不必马上认定连接失败。先检查检测域名是否被规则设为直连，浏览器是否绕过系统代理，检测页是否只展示了其中一种地址类型。如果需要临时用全局策略作对照，完成测试后应恢复原设置。

DNS：解析器不同，不一定就是泄漏

DNS 把域名解析为地址。DNS 检测页通常通过专门生成的测试域名，观察哪些递归解析器向其权威服务器发起查询。它展示的往往是解析器对外查询时的地址，不是设备自己的公网出口，所以 DNS 地址与网页出口 IP 不同很常见。

比较时要看解析器归属及配置，而不是要求所有结果都在节点所在地区。公共 DNS 可能使用分布式服务，检测页给出的地区只是数据库定位。客户端可能按域名分别采用本地解析、远端解析或合成地址机制，这些策略都会影响结果。

更值得调查的情况是：原本希望所有相关解析经过代理，检测却反复出现本地接入网络的解析器，且日志或设置能确认查询确实绕过了预期路径。仅看到熟悉的公共 DNS 品牌，还不能判定泄漏。

加密 DNS 与代理出口是不同问题。浏览器使用 DoH 可以加密浏览器到解析服务的查询，但这段连接仍可能直连。用了加密 DNS，不等于 DNS 已经走了所选线路。

先检查浏览器的安全 DNS，再看客户端的 DNS 策略和系统设置。某些浏览器会自行解析，绕过客户端预设的解析服务；某些客户端会把 DNS 请求接管到内部模块。不要把检测页结果机械地复制进配置，更不要一次替换所有解析设置。

按应用验证，别把浏览器结果推广到整台设备

浏览器出口正确，只能证明测试网页的请求符合预期。桌面软件、游戏、终端和后台服务可能使用不同的网络栈。有些应用不读取系统代理，有些使用 UDP，还有些已经建立的连接不会因为切换节点而立刻迁移。

实际操作时，先退出目标应用，再重新打开并执行一个明确的联网动作。同步查看客户端连接记录，寻找目标域名、进程或目的地址，核对匹配规则和出口。如果只看总流量增长，很难分清是应用请求还是系统后台流量。

• ✅ 浏览器：重新打开检测页，核对出口地址与检测域名的规则。
• ✅ 目标应用：重启后执行实际功能，查看相应连接记录是否出现。
• ✅ UDP 场景：核对客户端接管方式和线路支持，不用网页访问代替验证。
• ✅ 规则模式：分别检查应代理与应直连的请求，确认两者都符合预期。
• ❌ 仅凭页面能打开、应用图标亮起或流量计数变化，就认定全部生效。

Windows 与 macOS 上，要区分系统代理和隧道接管；Android 上，要查看是否排除了目标应用；iOS 上，允许添加 VPN 配置只是系统授权，仍需要检查客户端的策略与实际连接。各平台菜单名称不同，应以正在使用的客户端说明为准。

终端工具也可能受代理环境变量影响。浏览器成功、命令行失败时，先检查命令行是否使用相同代理路径，不要立刻换线路。需要配置说明时，可从快速上手核对接管与导入步骤。

IPv6 与 WebRTC：补查容易漏掉的路径

网络同时提供 IPv4 和 IPv6 时，应用可能优先采用其中一种。若客户端只接管了部分流量，就可能出现网页的 IPv4 出口变化，而 IPv6 仍使用本地网络的情况。应分别检查，不能只看检测页最醒目的一个地址。

本地网络没有可用 IPv6 时，检测失败并不表示代理异常。若检测显示本地网络的公网 IPv6，先确认该请求是否本来被允许直连，再查看隧道、IPv6 路由及排除规则。临时关闭 IPv6 可以辅助定位，但不是通用的长期修复方案。

WebRTC 用于浏览器实时通信，可能通过不同于普通网页请求的路径发现候选地址。检测结果里的局域网地址、经过隐藏处理的主机名和公网地址含义不同，不能看到一个地址就都称作泄漏。

重点是是否出现了不符合预期的本地公网出口。若出现，检查浏览器的相关隐私设置、客户端的 UDP 接管和隧道策略。修改前也要考虑视频会议等功能的需求，不能为让检测页变得整齐而盲目关闭必要功能。

已连接却没生效，按现象缩小范围

订阅导入了，但选中的配置没有更新

订阅链接用于获取节点与配置，不是连接成功的证明。更新失败、客户端格式不兼容、仍在使用旧配置，都可能让界面保留节点名称却无法正常请求。核对订阅更新时间与错误提示，再确认选中的节点确实来自当前配置。客户端需支持订阅所含协议，节点名称相同不能代替兼容性检查。

订阅链接通常带有账户凭据。求助时不要公开完整链接，也不要把它粘贴到来源不明的在线转换工具。截图和日志中的访问令牌应先遮盖。

出口已经改变，目标网站仍然不可用

这时应把“代理是否生效”和“网站是否接受该请求”分开。网站可能依据账户地区、历史会话、出口信誉或服务政策作判断；应用也可能保留旧连接。先重启应用并核对新请求日志，再检查网站本身的提示。不能把所有访问失败都归因于 DNS。

重连、切换网络之后结果变了

网络切换可能改变系统 DNS、默认路由和已经建立的连接。浏览器页面缓存、系统 DNS 缓存、客户端解析缓存也不一定同步更新。先重新发起请求和重启相关应用，仍不一致时再按平台文档清理缓存。记录每次操作，不要同时清缓存、换节点、改 DNS 和更换模式。

IEPL 专线、中转和直连描述的是线路传输方式，不是设备端接管范围。专线不能自动修正应用绕过代理或错误分流。协议与拓扑的概念可在线路与协议中进一步核对。

把检测结果整理成可复查的结论

一份有用的记录应包括：网络环境、客户端与模式、节点名称、连接前后出口、DNS 归属、目标应用行为，以及日志匹配的规则。保存时间与操作顺序，之后在同样条件下复测，才容易区分偶发故障和配置问题。

如果仍无法解释结果，可通过客服入口提交脱敏后的记录。说明期待哪类请求经过代理、实际观察到什么，比只写“连不上”更容易定位。日志中如含完整公网地址、访问域名或订阅凭据，只保留排查必要的信息。

最后恢复测试过程中临时修改的设置，并再次核对常用应用。检测页是观察工具，不是最终目标；真正需要确认的是日常使用的请求是否持续按自己的规则走线。