VPN 连上了怎么确认生效？出口 IP、DNS 与分应用检查新手指南

先确认连接模式与检查范围

常见客户端有系统代理、虚拟网卡接管和应用内代理等接入方式。系统代理会向操作系统登记代理设置，但是否采用仍取决于应用；虚拟网卡模式通过路由接管更多流量，也可能受到排除列表、应用分流和系统权限影响。浏览器扩展通常只影响浏览器内的部分请求，不应据此推断其他软件的走向。

客户端里的“全局”也有作用范围：它可能表示“进入代理内核的请求全部选代理”，并不等于操作系统里每个应用都已被接管。检查前，记录当前线路名称、规则模式和接入方式。若客户端存在规则命中或连接记录视图，保持该视图打开，后面用它把请求与出口对应起来。

出口 IP：用相同条件比较前后结果

出口 IP 是目标服务器看到的来源地址。先在断开连接时打开网络检测页，记下页面实际显示的公网地址；再连接线路，用同一个浏览器重新发起检查。不要只看国家名称或旗帜，优先比较地址本身。地址归属数据库可能更新滞后，城市标注尤其不适合用来断言线路部署位置。

1. 保存正在进行的工作，暂时停用其他代理扩展或并行运行的网络客户端，减少相互覆盖。
2. 记录未连接时的公网地址与网络环境，连接后保持同一网络，不要同时切换无线网络。
3. 确认检测域名命中了预期规则。若它被设为直连，检测结果不变本身不能说明国际网站也在直连。
4. 重新发起请求并对照客户端记录。必要时重开浏览器，避免已有连接继续沿用先前建立的路径。
5. 在条件允许时用另一项独立检测交叉核对，并分别关注 IPv4 与 IPv6 的结果。

若 IPv4 已变而 IPv6 仍呈现本地网络地址，说明至少这部分检测流量可能没有按预期被接管。先查客户端的 IPv6 支持、系统路由与绕过配置，再决定是否调整设置；不要把关闭 IPv6 当作所有问题的通用答案。双栈网络中，不同应用选择的地址族可能不同。

DNS 泄漏：先看解析策略，再看检测结果

DNS 用来把域名解析为地址，随后才是应用连接目标服务器。解析请求与网页数据可以走不同路径，因此网页出口正确，并不代表解析也符合预期。所谓 DNS 泄漏，应当结合策略判断：本应经代理或指定解析器处理的域名，却交给了预期之外的解析服务，才是需要追查的偏差。

DNS 检测通常通过专用测试域名，观察哪些递归解析器前来查询。页面展示的地区和运营商信息只是线索，并不直接显示设备到解析器之间的完整路径。公共解析服务可能使用分布式出口；仅凭“解析器地区与线路地区不同”，不能认定发生泄漏。

按解析来源逐项排查

• 客户端 DNS：检查是否启用了内置解析、远程解析或域名分流。代理域名与直连域名可能有不同的解析策略。
• 浏览器安全 DNS：浏览器可能通过加密 DNS 自行解析。它是否经过代理，仍取决于浏览器代理行为和客户端规则，需要结合连接记录判断。
• 系统及应用缓存：切换线路后，已有解析结果可能继续有效。重新运行检测，并在必要时按系统文档清理缓存，不要仅凭旧页面得出结论。
• 应用自带解析：部分应用会直接连接自有解析服务。浏览器的检测结果不能替这些应用作结论。

如果客户端采用 Fake-IP，系统或应用看到的地址可能是客户端用于映射域名的合成地址，而不是目标网站真实地址。这是接管解析的一种机制，本身不是泄漏证据。更有用的是核对域名对应的规则、解析请求的去向，以及最终连接是否成功。

分应用检查：浏览器、终端与桌面软件

浏览器能正常访问而终端失败，首先应怀疑代理作用范围，而不是直接更换线路。命令行工具对系统代理的支持并不一致，有些依赖环境变量，有些需要自身配置。即使终端设置了代理，编辑器里的后台进程也可能在启动时继承了旧环境，重开终端并不会自动改变已运行程序的配置。

• ✅ 浏览器：检查扩展、自定义代理和安全 DNS，重新打开目标页面，并核对请求是否出现在客户端连接记录中。
• ✅ 终端：查看工具自身的代理说明，核对代理地址、协议与本地监听端口，再用同一个目标发起请求。
• ✅ 编辑器与桌面软件：检查应用内网络设置，调整后完全退出并重新启动，再观察真实业务请求。
• ✅ 移动设备：检查是否启用了按应用接管或排除规则，并确认测试的是前台实际使用的应用。
• ❌ 不要把浏览器检测通过，写成所有应用均已通过；也不要把某个应用未显示记录，直接解释成线路故障。

在 Windows 与 macOS 上，系统代理和虚拟网卡模式是不同的接管机制，授权要求也可能不同。Linux 上，桌面环境的代理设置不一定传递给命令行进程。移动平台则受系统网络扩展与客户端能力限制，具体选项以实际客户端为准。跨平台复现时，应保持检查目标一致，而不是只比较开关名称。

HTTP 代理与 SOCKS 代理还可能在域名由谁解析的问题上存在差异。排查终端时，不要从网上照抄未知端口；应读取当前客户端实际显示的本地监听配置，并确认工具支持该代理类型。若工具支持远端解析选项，再按其文档核对是否启用。

看似连接成功的常见偏差

规则选中了直连，或订阅没有更新

导入订阅只是让客户端获得线路与配置，不代表目标请求一定选择了其中的代理。检查当前配置是否确为刚导入的订阅、策略组是否选中可用线路、目标域名是否命中直连或排除规则。订阅链接应按凭据保管，不要贴进公开截图、在线解析工具或问题讨论区。

连接记录有请求，但业务仍然失败

这说明排查应继续向后推进：检查 DNS 结果、连接错误、目标服务状态、账号会话及地区限制。出口改变不保证平台授权、内容片库或登录一定成功。也不要为了复现而连续更换地区；保持同一出口测试，更容易区分网络问题与会话风控。

网页正常，通话或其他实时功能异常

不同功能可能使用不同传输方式，普通网页请求成功不能证明 UDP 等流量已被正确接管。先确认客户端模式是否覆盖该流量、应用是否被排除，再查看相关连接记录。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议名称不能代替实际验证；协议支持、客户端实现与系统接管方式需要一起看。

IEPL 专线、中转与直连描述的主要是线路路径和承载方式，不是应用接管开关。即使更换线路类型，未采用系统代理的应用仍可能保持原来的路径。因此先验证流量有没有进入客户端，再讨论线路表现，能避免把配置问题误判成线路问题。

整理证据，再决定是否调整配置

复测时每次只改一个条件，例如只切换接管模式，或只调整目标域名的规则。保留更改前后的出口结果、规则命中和错误提示。若问题集中出现在晚高峰，应记录实际发生时段与网络环境，在相同应用、相同目标下复测；没有观测记录时，不应直接归因于拥塞。

需要联系客服时，提供操作系统、客户端名称、连接模式、所选线路、目标域名和错误文字即可形成有效排查起点。分享截图前隐藏公网地址中不愿公开的部分、订阅链接、访问令牌与账号信息。客户端连接记录是本地排查材料，不等同于服务端的日志策略说明。