VPN连上了到底生效没？检查出口 IP 与 DNS，不能只看客户端的连接图标。应先记录未连接时的结果，再比较连接后的出口、域名解析与目标应用表现。真正需要确认的是：指定应用的指定请求，是否按预期经过代理。
日常所说的 VPN 客户端，也可能实际使用代理协议和分流规则，并非接管整台设备的所有流量。下面的检查方法既适用于系统级连接，也适用于订阅客户端，但判断时要以实际工作模式为准。
连接图标与实际出口的区别
“已连接”可能只表示系统隧道建立，或本地代理服务已经启动，并不一定说明远端节点可达。有些客户端在节点不可用时仍保持运行状态；另一些应用则完全不读取系统代理设置。因此，客户端状态、网页出口和应用行为需要分开验证。
| 检查项目 | 能说明什么 | 不能单独证明什么 |
|---|---|---|
| 客户端显示已连接 | 客户端或系统连接处于运行状态 | 远端出口可用、所有应用都被接管 |
| 网页出口 IP 改变 | 该网页请求使用了不同的公网出口 | 其他应用、其他地址族和 DNS 也走同一路径 |
| DNS 检测结果改变 | 测试域名由另一组解析服务处理 | 全部网络流量已经进入代理 |
| 目标应用正常访问 | 该应用的当前功能能够使用 | 其登录、媒体、下载等请求全部经过代理 |
| 客户端连接记录命中规则 | 客户端识别了请求及其选路结果 | 服务器最终接受请求、内容一定能播放 |
还要明确自己的预期。规则模式下，本地网站直连、国际网站经过代理，可能正是正确配置；如果要求某个应用全部经过代理，则应检查该应用的所有相关规则，而不是仅查看一个测试网页。
检查出口 IP：先留基线，再做对照
出口 IP 是网站收到请求时看到的公网来源地址，不是设备在局域网中的地址。可以在浏览器中搜索“查询公网 IP”，选择能区分 IPv4 与 IPv6 的检测页面。检测服务也会接收你的访问请求，应阅读其隐私说明，不要向检测页面上传订阅链接或客户端配置。
- 断开代理并记录基线。保持当前网络不变，打开检测页面，记录公网地址、地址族和运营商信息。若网络本身已有上游代理，也要记入对照条件。
- 连接客户端并确认选路模式。检查选中节点、系统代理或隧道开关，以及规则模式是否符合预期。节点选中不等于系统接管已经启用。
- 重新请求检测页面。刷新页面，必要时重新打开浏览器。无痕窗口可减少部分站点缓存和登录状态干扰，但不能代替检查代理设置。
- 比较地址并核对规则。若出口变化，说明该次请求路径发生改变；若没有变化，先看检测域名是否命中直连规则，再判断连接是否异常。
- 分别查看可用的地址族。IPv4 经过代理，不意味着 IPv6 也被接管。若检测到 IPv6，需将其与未连接时的结果对照。
检测页面显示的国家或城市来自 IP 地理数据库，可能滞后，也可能与节点标签不同。不要单凭城市名称判定失败。更有价值的证据是公网地址是否变化、网络归属是否符合预期，以及客户端是否记录了对应的代理连接。
DNS 检测：解析位置不等于网页出口
DNS 负责把域名解析为地址。网页连接可以经过代理，而域名查询仍由本地网络处理；也可能由浏览器的安全 DNS 独立解析，再把网页请求交给代理。这些路径互相相关，却不是同一件事。
常见 DNS 检测页面会让浏览器请求临时生成的域名，再显示参与解析的递归解析服务。先断开连接跑一次，再连接后重新测试，观察解析服务是否变化。页面通常看到的是递归解析服务的出口，不一定是设备直接配置的解析地址，也不一定与代理节点处于同一地区。
所谓 DNS 泄漏，应相对于预期策略判断。如果目标是让相关域名通过代理侧解析，但实际查询仍发往本地网络解析器，就需要排查。若规则明确允许某些域名本地解析，其出现不能自动算作异常。看到熟悉的公共 DNS 品牌，也不能直接判断查询是否加密或是否经过代理。
出现意外解析结果时，检查这些位置
- 浏览器安全 DNS：浏览器可能使用自选的加密解析服务，其行为与系统 DNS 不同。记录设置后再做受控对照，不要长期关闭安全功能来掩盖问题。
- 客户端 DNS 模式：查看是否使用代理侧解析、DNS 接管或 Fake IP。Fake IP 是客户端内部映射机制，看到虚拟地址本身不代表连接失败。
- 系统与网络配置：企业网络策略、其他网络工具和手动设置的解析器，都可能改变查询路径。
- 缓存：已有解析结果可能暂时被复用。重新运行能生成新测试域名的检测，比反复刷新同一个普通网页更有参考价值。
命令行中的 nslookup 可以辅助查看传统 DNS 查询，但不一定反映浏览器的安全 DNS，也不等同于应用通过代理侧解析的行为。不要因为命令行结果与浏览器不同，就直接判定客户端失效。
分流规则与各平台的接管范围
系统代理通常只影响遵循该设置的应用。浏览器可能正常走代理，而终端、游戏或下载程序继续直连。TUN 模式通过虚拟网络接口接管流量，覆盖范围通常更广，但仍受路由、排除规则、地址族及系统权限影响，并非打开后就无需验证。
Windows 与 macOS 上，先分清客户端启用的是系统代理还是网络隧道，再检查浏览器扩展、自带代理和其他网络工具是否覆盖设置。终端程序可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 等环境变量，也可能需要单独配置。
Android 上要检查应用是否被排除在代理范围之外，以及客户端是否取得系统连接授权。iOS 上应确认当前启用的是预期的网络配置，并检查客户端规则；系统出现连接标识，也不能证明每个域名都被选为代理。
Linux 桌面环境、终端和后台服务可能分别采用不同的代理设置。只在桌面设置中启用代理，不代表服务进程会继承。排查时应在实际出问题的程序中验证，而不是仅用浏览器替代。
协议名称也不能代替检查。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 描述的是不同的代理连接方案；是否接管应用、在哪里解析 DNS，仍取决于客户端实现和配置。仅更换协议无法修复一条明确要求直连的分流规则。
按应用验证，定位请求在哪一步偏离
浏览器测试通过后，打开真正需要使用的应用，执行你关心的操作，例如登录、加载媒体或下载文件。同时查看客户端提供的连接视图或诊断记录，寻找该应用相关域名、命中的规则和最终出口。界面名称因客户端而异，不必照搬其他客户端的菜单。
同一应用可能把登录、图片和媒体分配给不同域名。首页能打开不代表视频请求也走代理；反过来，服务拒绝某个出口，也不等于请求没有经过代理。账号地区、内容授权、缓存、设备定位权限和服务自身限制，都可能影响结果。
- ✅ 先写明目标：哪个应用、哪个功能、预期直连还是代理。
- ✅ 每次只改变一个设置，保留连接前后的对照结果。
- ✅ 核对规则命中和选中出口，再重复目标操作。
- ✅ 分别检查浏览器与目标应用，不把网页结果推广到整台设备。
- ❌ 不把页面语言、搜索结果地区或访问速度当作唯一证据。
- ❌ 不把 IPv4 检查通过理解为 IPv6 和 DNS 同时通过。
如果担心 WebRTC 暴露地址，应使用专门检测并区分局域网地址与公网地址。浏览器可能以隐藏本地地址的名称形式展示结果，看到本地网络信息不等于公网出口绕过代理；若出现原网络公网地址，则应进一步核对浏览器策略和 UDP 接管情况。
看似连上但未生效的排查顺序
不要从删除客户端、清空全部设置开始。先保存当前配置和基线，再按下面的顺序缩小范围。这样既能保留可复现证据，也能避免同时修改多个设置后无法判断原因。
- 确认基础网络。断开连接后检查普通网站是否可达，先排除网络认证未完成或本地网络中断。
- 确认服务与订阅状态。在面板核对套餐、剩余流量和订阅信息。刷新订阅只是更新配置，不会自动修复本地接管设置。
- 确认远端节点可达。查看客户端错误提示。必要时切换可用节点作对照，但不要将客户端内的延迟测试当作网页访问成功的证明。
- 确认流量进入客户端。检查系统代理、隧道权限和应用排除项；如果完全没有目标请求记录，应优先查接管范围。
- 确认规则与解析路径。查看请求是否被判为直连、DNS 是否符合预期，再核对出口。临时调整规则后，应恢复并修正长期配置。
- 最后检查应用侧限制。出口与规则均符合预期但功能仍失败时，再检查账号、缓存、应用版本和目标服务的访问策略。
结论：以请求路径为准，不以连接图标为准。
出口 IP 对照验证网页路径，DNS 检测验证解析行为，应用实测与规则记录验证实际用途。相关证据一致，才有依据判断连接符合预期；任何一项异常，都应回到对应层级排查，而不是仅凭“已连接”或“打不开”下结论。
使用 VPNEast 时，客户端与订阅入口可在登录面板中获取；连接配置问题可参考使用教程，或前往帮助中心。VPNEast 的隐私策略为不记录日志；本地客户端诊断信息的生成与保存，则应根据所用客户端的设置另行核对。