VPN 怎么确认真的生效了?出口 IP 与 DNS 自查指南

连接状态与实际流量路径

不同客户端对“连接”的定义不同。有的表示代理核心已启动，有的表示虚拟网络接口已启用，有的还会检查所选节点是否可达。即使状态正常，目标网站仍可能被规则判定为直连，应用也可能忽略系统代理。

系统代理主要向支持它的应用提供代理设置。TUN 或系统 VPN 模式通常通过虚拟接口接管更多流量，但仍受到路由、应用排除项及客户端实现影响。客户端中的“全局代理”也未必等于接管整台设备：它可能只是把已经进入代理核心的请求统一送往节点。

因此，自查应结合网页结果与本地连接记录。记录中没有某个请求，不一定是节点故障，也可能是应用根本没有把流量交给客户端。

出口 IP：连接前后对照

出口 IP 是目标网站看到的公网地址，不是设备在局域网内的地址。检查时选用可信的公网 IP 查询页面，始终使用同一浏览器、同一查询页面，并记录地址、网络运营方与地区提示。查询网站会接收到本次请求的公网地址，不要向检测页面提交订阅链接或账号凭据。

1. 断开客户端连接，确认浏览器能够正常访问查询页面，记录当前公网 IP，作为直连基线。
2. 连接目标节点，确认客户端模式与当前规则。重新载入查询页面，必要时关闭旧页面后再打开，减少缓存和既有连接的影响。
3. 比较地址是否变化，并查看该请求在客户端中命中的规则。如果查询域名被设为直连，应先调整测试条件，而不是直接判定节点失效。
4. 再次断开连接，观察结果是否回到直连路径。往返对照比只看一次地区标签更有说服力。

IP 地理位置来自数据库，可能存在更新滞后。节点标签与查询页面的城市不完全一致，不能仅据此判断连接无效；网络运营方、实际地址变化和客户端记录更值得交叉核对。也不要把出口地址变化解释为身份不可识别，登录账号、Cookie 和其他应用数据仍可关联活动。

DNS 自查：解析器与查询路径

DNS 用于把域名解析为可连接的地址。常见 DNS 检测页面会让浏览器访问测试域名，再识别参与查询的递归解析器。它显示的通常是解析器的出口信息，而不是设备的公网出口，也不是节点所在位置。

连接前后使用同一检测页面，记录解析器运营方及结果变化，再结合客户端 DNS 设置判断。若配置要求域名解析经过代理，但连接后仍出现本地网络提供的解析器，应继续检查系统 DNS、客户端 DNS 接管和浏览器设置。若规则明确允许本地网站使用本地解析器，这种结果则可能符合设计。

浏览器安全 DNS 与系统 DNS

浏览器可能启用基于 HTTPS 的 DNS，也就是 DoH。它可以绕开系统默认解析器，因此浏览器测试不能代表其他应用。DoH 本身也不等于“经节点解析”：其连接是否经过代理，仍取决于应用代理方式和分流规则。

排查时先记录浏览器安全 DNS 的配置，再与客户端文档核对。可以在知晓影响的前提下临时关闭该功能做对照，完成后恢复原设置。不要同时修改浏览器 DNS、客户端模式和节点，否则很难知道是哪项改变了结果。

浏览器 DNS 测试也不等于 WebRTC 检查。WebRTC 涉及实时通信及候选地址发现，检测页面出现本地地址或经隐藏处理的主机名，与 DNS 查询路径是不同问题。应按具体浏览器和客户端行为分别验证，避免把所有地址提示统称为泄漏。

分应用验证：浏览器、终端与客户端

浏览器能正常访问，不代表命令行工具也能访问。终端程序可能需要独立的代理配置或环境变量；桌面应用可能有自己的 HTTP 或 SOCKS 代理选项；容器及虚拟机还可能使用独立网络。应在真正使用的环境中发起请求，而不是只在浏览器里检查。

• ✅ 浏览器：检查独立代理扩展与安全 DNS，查看目标请求是否出现在客户端连接记录中。
• ✅ 终端工具：查看工具文档和当前代理环境变量，例如 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY，确认没有被绕过列表排除。
• ✅ 桌面应用：确认其使用系统代理还是应用内代理，修改后重新启动应用，避免沿用旧连接。
• ✅ 移动端应用：检查系统 VPN 状态、客户端分流及应用排除设置，并在实际应用中验证目标功能。
• ✅ 容器与虚拟机：核对内部网络及 DNS 配置，不把宿主机的检测结果当作内部环境的结果。

Windows 与 macOS 上，设置系统代理与启用虚拟接口是不同的接管方式。iOS 的客户端通常通过系统网络扩展建立配置，但实际路由仍由客户端配置决定。Android 客户端若支持按应用处理，也可能将某些应用排除。Linux 上则需要留意当前会话的代理环境与路由设置。

如果工具使用 SOCKS 代理，还要核对域名由本地解析还是交给代理端解析。不同工具对代理地址写法的处理不同，不能照搬其他应用的配置。订阅导入方法可参考连接教程，具体代理行为则以所用客户端与工具的文档为准。

看似连上、实际未生效的情况

订阅存在，但没有选中可用配置

订阅链接是获取节点与规则等配置的入口，不是网络接管开关。导入成功后，还要确认配置已启用、目标策略组选中了预期节点。更新订阅后，原节点名称或策略选择可能发生变化，应重新核对。订阅链接包含访问凭据，求助时不要公开粘贴。

分流规则命中直连

目标域名可能被直连规则、应用排除项或绕过列表匹配。打开客户端连接记录，找到对应域名，检查最终策略。必要时临时切换规则模式做对照；验证结束后恢复原配置。改变规则能用于定位问题，但不应成为长期忽略配置原因的替代方案。

旧连接与多个网络工具冲突

浏览器、聊天应用及开发工具可能保留既有连接。切换节点后，新请求与旧连接可能短暂走不同路径。可以退出目标应用再打开。若同时运行多个代理或 VPN 客户端，还可能出现系统代理覆盖、虚拟接口路由竞争及 DNS 设置冲突，排查时只保留当前要验证的客户端。

把访问限制误当成线路失效

出口 IP 已变化，但目标服务仍拒绝访问，可能与账号地区、登录状态、服务政策或出口地址信誉有关。网页能打开却无法完成某项功能，也不能仅归因于带宽。先确认流量路径，再处理服务端限制，不要反复切换节点来代替诊断。

线路类型与连接证明

IEPL 专线、中转与直连描述的是不同的传输路径安排，不是连接生效的证明。专线通常用于特定区段的专用传输；中转经由中间入口转发；直连通常指客户端直接连接出口服务端。具体区段和路由仍应以线路说明为准，任何类型都需要做出口与应用验证。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 是不同的代理协议或协议体系，不应仅因协议名称就推断 DNS 已被接管。客户端是否支持订阅中的协议、是否启用正确配置、域名在哪里解析以及流量如何分流，才决定实际行为。

需要了解本站线路信息时，可查看节点页面。选择线路后仍建议保留自己的连接前后对照，不把线路名称、客户端状态或网页地区标签当作单独的验收结果。

自查结论与求助信息

若问题仍存在，保存连接前后的检测结果，并记录操作系统、客户端名称、当前模式、节点名称和目标应用。说明异常发生在连接、解析、页面加载还是登录阶段，比只说“无法使用”更便于定位。

向支持页面提交材料时，遮盖订阅链接、密码、访问令牌及私人域名。客户端本地诊断记录与服务端日志策略不是同一概念；VPNEP 的“不记录日志”是服务隐私立场，不替代设备端配置检查，也不代表第三方检测页面不会处理请求信息。

最后保留一份可正常使用的配置。每次只改变一个变量，验证后恢复临时设置。这样，无论是节点变化、DNS 配置还是应用升级导致异常，都能用相同的对照方法重新确认，而不是依赖连接图标猜测。