VPN 连上了怎么确认生效？先对比连接前后的出口 IP，再检查 DNS 解析路径，最后验证实际使用的应用。客户端里的“已连接”只是起点，不能单独证明浏览器、游戏或其他软件都经过了所选线路。
先分清连接状态与流量路径
不同客户端对“已连接”的定义不同。有的表示系统隧道已经建立，有的只表示本地代理服务开始监听。即使节点不可达，本地代理也可能已经启动；即使节点可达，应用也可能没有使用这个代理。
系统代理通常供遵循系统代理设置的程序使用，并不自动覆盖所有网络流量。TUN 模式通过虚拟网络接口接管符合路由条件的流量，覆盖范围通常更广，但仍受排除规则、权限和客户端实现影响。移动端出现 VPN 图标，也不等于每个应用都走同一个出口。
还要区分“节点延迟测试成功”和“目标网站访问成功”。前者可能只检测某个连接或测试地址；后者还涉及 DNS、分流、目标服务状态及账号限制。Shadowsocks、VMess、Trojan、VLESS 等协议名称也不能替代实际验证，是否支持相关传输功能要看客户端与服务配置。
| 看到的现象 | 可以说明 | 仍需检查 |
|---|---|---|
| 客户端显示已连接 | 客户端已进入连接或运行状态 | 节点是否可达、应用是否被接管 |
| 浏览器出口 IP 改变 | 这次网页请求的出口发生变化 | 其他应用、其他地址族与分流规则 |
| DNS 检测出现公共解析商 | 测试域名由相应解析服务处理 | 解析请求是否经过预期路径 |
| 目标应用可以正常使用 | 当前功能在当前网络条件下可用 | 实际出口、地区判断与持续连接情况 |
出口 IP 检测：先留基线，再做对照
出口 IP 是目标网站看到的来源地址，不是电脑在路由器内使用的局域网地址。不要拿系统网络设置里的本地地址与查询网页比较。查询结果中的国家、城市和运营商来自地址数据库，可能存在更新滞后，因此地区文字只能辅助判断。
- 记录未连接时的结果。暂停客户端连接，在浏览器搜索“查询公网 IP”，打开可信的查询页面，记录公网地址、标注地区及网络名称。保持同一网络，不要在对照过程中切换无线网络。
- 连接并确认模式。选择目标节点，检查系统代理或 TUN 是否按教程启用。采用规则模式时，确认查询页面本身会走代理，否则它显示本地出口可能正是规则设计的结果。
- 重新发起查询。刷新查询页面，必要时新开隐私窗口，比较地址是否变化。换用独立的查询服务交叉核对，避免缓存或单个数据库误标造成误判。
- 用目标应用复核。查看客户端连接记录，确认访问目标域名时命中了代理规则及所选节点。测试结束后恢复原本需要的分流模式。
如果查询页面同时报告 IPv4 和 IPv6，应分别观察。某些配置只接管其中一种，浏览器可能优先使用另一种路径。不要把“某个地址已经改变”直接理解成全部请求都被接管；应根据客户端的 IPv6 支持与路由说明处理。
DNS 泄漏：看解析路径，不只看国家
DNS 负责把域名转换为网络地址。网页请求走了代理，不代表域名查询也走同一路径。所谓 DNS 泄漏，需要结合预期配置判断：本来希望解析也由隧道承载，但查询却通过本地网络发出，才是需要处理的路径偏离。
连接后可搜索并打开可信的 DNS 泄漏检测页面，按页面说明完成测试，记录出现的解析商名称，再与客户端 DNS 设置对照。此类测试通常通过专用域名识别参与解析的递归服务器，并不能直接展示请求从设备到解析服务器之间的全部路径。
因此，出现本地运营商解析服务是值得核查的信号，但出现境外公共解析服务也不能自动证明没有泄漏。公共解析商可能使用就近接入；浏览器的安全 DNS，也就是 DoH，还可能独立于系统 DNS 工作。解析商所在地不是唯一判据。
- ✅ 核对客户端的远程 DNS、直连 DNS 与域名分流设置，先理解各自用于哪些请求。
- ✅ 检查浏览器安全 DNS 是否与客户端方案冲突，修改后重新启动浏览器并复测。
- ✅ 查看客户端日志中的解析与规则命中情况，确认测试域名走了预期路径。
- ❌ 不要把所有解析地址都改成陌生公共 DNS；这可能绕开原配置，也未必解决路由问题。
修改解析设置后，已有 DNS 缓存和应用长连接可能仍在使用旧结果。可以先关闭目标应用再重新打开；需要清理系统缓存时，使用对应平台的官方操作说明。不要同时改节点、DNS 和规则，否则复测成功后也难以确定原因。
按应用验证：浏览器成功不等于全部生效
浏览器扩展往往只影响浏览器内的流量，独立客户端不会因此自动使用代理。反过来，某个扩展也可能覆盖系统代理，让网页出口与其他程序不同。排查时先暂停不需要的代理扩展，保留一个明确的接管方案。
Windows 与 macOS 上，应检查系统代理设置是否已被其他网络工具改写，并确认目标应用是否遵循它。Linux 桌面代理设置也不必然被命令行程序采用；部分程序读取代理环境变量，部分需要单独配置。仅用浏览器查询结果，无法证明终端工具的路径。
iOS 与 Android 客户端通常使用系统提供的 VPN 接口，但仍可能配置按应用排除或按目标地址分流。若浏览器正常而独立应用失败，先查应用是否被排除，再查目标域名是否命中直连规则，而不是直接归因于节点失效。
最实用的方法是打开客户端的连接记录，然后启动目标应用并执行实际功能，例如登录、加载内容或发起请求。观察新出现的域名、命中规则和出口节点。应用可能同时连接多个域名，主界面能打开也不代表登录或媒体请求使用同一路径。
常见“假连接”的排查顺序
出口没变：先检查规则，再检查接管
规则模式允许一部分网站直连，所以国内查询页面显示本地出口并不一定异常。先查看该请求命中了什么规则。需要做对照时，可临时让测试请求明确走代理，再恢复原设置。即便客户端称为“全局模式”，也要确认它的覆盖范围，并非所有实现都会接管全部系统流量。
网页能打开，应用仍报错
先检查应用是否走代理，以及相关域名是否分流完整。确认路径后再考虑地区资格、账号状态、服务自身故障或出口风控。网页缓存也可能造成“能打开”的错觉，应验证需要联网的新操作，而不是只看已经加载的页面。
切换节点后结果没有变化
旧连接可能仍然保持，应用也可能复用之前的会话。关闭目标应用后重开，再查看新连接的记录。若仍未变化，核对当前策略组实际选择的节点；自动选择、故障转移或单独的应用策略组，可能与首页显示的选择不同。
订阅导入成功，却无法正常访问
订阅导入只证明客户端读到了配置，不等于节点可用。确认订阅是否已更新、账户套餐是否有效，以及客户端是否支持配置使用的协议与传输方式。不要为修复连接关闭证书校验或安装来源不明的证书，应优先按服务教程核对配置。
如果改用另一条线路后正常，应记录原线路、出现问题的应用、错误提示及规则命中结果，再向支持渠道反馈。IEPL 专线、中转和直连描述的是线路组织方式，不会替代设备端的代理接管与 DNS 配置；线路名称本身不是生效证据。
最后用检查清单确认结果
无需每次连接都做完整测试。首次配置、切换客户端、调整规则或遇到地区异常时，再按同样顺序复查。保留简短记录，比反复重装更容易定位问题。
- ✅ 已记录连接前后的公网出口，并确认测试请求应当走代理。
- ✅ 已核对 DNS 设置与浏览器安全 DNS，没有只凭解析商国家作判断。
- ✅ 已在目标应用内执行实际联网操作，并检查对应连接记录。
- ✅ 已检查 IPv6、应用排除与旧连接，测试后恢复日常分流设置。