怎么确认 VPN 真的生效？先查出口 IP，再检查 DNS 的解析路径，最后在实际使用的应用里验证。客户端显示“已连接”，只能说明它报告的连接状态，不能直接证明所有应用、所有域名都走了所选线路。
判断时先明确目标：是让某个浏览器访问国际网站，还是让设备上的目标应用按规则转发？分流模式允许部分访问直连，因此“某个网站仍显示本地出口”不一定是故障。下面按可复查的顺序操作，每次只改一项设置，避免把浏览器、客户端与应用的问题混在一起。
先区分：连接状态、出口 IP 与应用路径
客户端、系统与目标网站看到的是不同层面的信息。系统出现 VPN 标识，通常表示网络扩展或隧道已经启用；客户端能够更新订阅，只能说明订阅获取成功。它们都不是目标网页实际经过指定出口的直接证据。
| 检查对象 | 能说明的问题 | 不能据此推断的结论 |
|---|---|---|
| 客户端显示已连接 | 客户端报告连接或代理已启动 | 全部应用都经过代理 |
| 检测页的公网 IP 改变 | 该次网页请求的出口发生变化 | 其他应用与 DNS 同样走该出口 |
| DNS 检测显示某解析服务 | 检测请求观察到的递归解析出口 | 单凭解析器地区确认泄漏 |
| 目标应用可以访问 | 当时该功能可用 | 应用所有连接均经指定线路 |
| 流媒体出现目标片库 | 平台当时的地区与内容判定符合预期 | 线路以后始终可用 |
更稳妥的判断需要交叉证据：出口变化符合预期，DNS 行为符合配置，目标应用连接也命中对应规则。这里说的“符合预期”，比单纯追求检测页全是绿色更重要。
查出口 IP：保留连接前后的对照
出口 IP 是目标服务器看到的公网地址，不是设备在家庭网络里的局域网地址。可以在浏览器搜索“公网 IP 检测”，选择能分别展示 IPv4 与 IPv6 的工具。检测工具也会接收到你的访问请求，不必为了检查而填写账户资料或安装陌生扩展。
- 建立基线。断开客户端连接，打开检测页，记下公网 IP、网络运营方和标注地区。保持当前网络不变，避免同时切换 Wi-Fi 与蜂窝网络。
- 连接目标线路。确认节点已选中，检查客户端当前使用的是规则模式、系统代理还是设备级隧道模式。
- 重新发起请求。刷新检测页；如果页面没有重新检测入口，可关闭该页后重开。必要时换一个检测工具交叉核对。
- 比较实际地址。先看 IP 是否改变，再看归属与地区。不要只看国旗，也不要把检测页显示的城市当成物理机房定位。
IP 地理数据库可能更新滞后，不同检测服务也可能给出不同地区。所选节点的名称、出口地址的登记信息和平台自己的地区判断，不一定完全一致。地址变化是线索，但是否属于预期出口，还要结合服务提供的节点说明与客户端记录判断。
如果检测页走了直连规则，连接后地址可能不变。可以临时使用客户端提供的全局代理模式复查，完成后恢复原规则；但“全局”往往只是客户端内部的路由选择，并不必然接管所有应用。系统代理仍可能被应用忽略。
同时检查 IPv4 与 IPv6。如果其中一种地址仍来自原有网络，先核对客户端对该地址族的接管方式。不要仅凭 IPv4 已变化，就认定所有网络请求都已覆盖。
查 DNS：看解析路径，而不是只看地区
DNS 把域名转换为用于连接的地址。网页流量经过代理，不代表域名查询也一定经过代理。在本文语境里，DNS 泄漏指本应由预期受保护路径处理的查询，实际交给了不符合配置预期的解析路径，例如仍通过本地网络向运营方解析器查询。
在保持目标线路连接的情况下，打开 DNS 泄漏检测工具并运行测试。工具通常让浏览器请求临时生成的域名，再从测试方的权威 DNS 侧观察递归解析器。它显示的主要是递归解析出口，不一定是设备直接联系的服务器，也不等于能看到整条 DNS 传输路径。
- 先记录未连接结果。了解原网络通常使用什么解析服务，再对照连接后的变化。
- 检查配置意图。确认客户端对代理域名、直连域名分别如何解析，以及是否启用了 DNS 接管。
- 核对浏览器安全 DNS。浏览器可能使用自己的加密解析服务，覆盖或绕过系统的解析选择；其连接是否经代理，还取决于路由。
- 结合连接记录判断。如果测试仍出现原网络的解析器，应检查是否存在直接发出的查询，而不是立即认定检测工具有误。
解析器显示在另一个地区，不自动构成泄漏；公共解析服务的出口可能采用分布式部署。反过来，解析器与节点地区相同，也不能单凭这一点证明查询已经加密或完整经过隧道。若客户端使用 fake-IP，把临时映射地址交给应用也是正常机制，不能把它误认为真实公网出口。
判断结论：DNS 检测是排查线索，不是隐私认证。应当把检测结果与客户端 DNS 配置、浏览器安全 DNS 设置及连接记录一起看。无法确认路径时，保留记录并向支持人员询问，不要用地区标签代替证据。
逐个验证应用：浏览器正常不代表全部正常
系统代理、浏览器扩展代理和设备级隧道，覆盖范围不同。Windows 与 macOS 的部分应用会遵循系统代理，另一些则使用自己的网络设置；Linux 还可能依赖桌面代理配置或环境变量。浏览器扩展通常只影响浏览器相关流量，不能据此判断其他软件。
iOS 与 Android 的客户端常通过系统网络接口接管流量，但具体应用范围、域名规则与排除项仍由实现和设置决定。Android 的省电策略可能限制后台运行；设备切换网络后，也需要重新确认连接恢复。系统图标仍在，并不能代替实际测试。
- ✅ 在目标浏览器重新检测出口，确认浏览器自身没有启用另一套代理扩展。
- ✅ 在实际应用中触发新的网络请求，例如重新搜索或打开尚未缓存的内容，而不是只看已经加载的首页。
- ✅ 若客户端提供连接记录，按应用或目标域名查看命中规则、出站节点及连接错误。
- ✅ 检查分应用列表中的“包含”与“排除”含义，确认目标应用没有被设为直连。
- ✅ 切换网络、唤醒设备后再复查，判断问题是否只发生在后台恢复阶段。
日志中的 DNS 查询、网页请求和应用连接未必使用相同域名。应用还可能联系登录、图片、视频与更新服务。看到其中一个域名命中代理，只能说明该条连接的情况；应以你正在排查的具体功能为目标，查找对应请求。
看起来连上却没走：按症状定位
订阅已导入，但线路不能使用
订阅链接提供节点与配置，不是网络隧道本身。导入成功后，还需选择可用节点并启动连接。客户端能否解析某种配置，取决于版本与实现；Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议名称不能混为一谈，也不应假定任意客户端都支持。本段只解释兼容性，不代表 LQVPN 提供上述全部协议。
如果订阅更新失败，先核对链接是否完整、客户端是否兼容；如果节点连接失败，则查看认证、连接与配置错误。不要把自己的订阅地址贴到公开检测网站，它可能包含访问凭据。
浏览器出口不变，其他应用却能访问
优先检查浏览器扩展、独立代理设置，以及检测域名命中的规则。反向情况也一样：浏览器出口改变，但其他应用未走代理，常见原因是应用没有遵循系统代理，或被分应用规则排除。仅反复更换节点，通常不能解决接管范围的问题。
网页正常，通话或其他实时功能异常
这些功能可能采用与普通网页不同的连接方式。WebRTC 检测里出现局域网地址或经 mDNS 隐藏的主机名，不等同于公网 IP 泄漏；若出现原网络的公网地址，则需要进一步检查媒体连接路径。是否能代理相关 UDP 流量，要看客户端、节点与规则的实际支持情况。
出口正确，流媒体仍提示地区不符
平台还可能参考账户地区、付款资料、位置权限、缓存与出口信誉。先重新打开应用，再核对地区相关设置；必要时按平台指引处理缓存。IEPL 专线、中转与直连描述的是线路组织方式，不能单凭线路类型断言 DNS 不会泄漏，或某个片库始终可用。
把检查结果整理成可复查的记录
排查时记下设备系统、客户端名称与版本、所选节点、运行模式、出口变化和 DNS 检测结果。如果开启客户端日志，尽量复现问题后再截取相关片段。对外发送前，遮盖用户名、订阅链接、访问令牌和与问题无关的访问记录。
同一次排查不要同时修改 DNS、分流模式和节点。每改一项，就在同一目标应用里重试；问题解决后恢复不必要的临时设置。若只是为了诊断切换到全局代理，别忘了复核恢复规则后的表现。
最终检查口径：目标请求的出口符合预期，域名解析路径符合配置，实际应用也命中正确出站，才形成较完整的生效证据。这只能说明当前环境下的测试结果，不代表所有应用或未来连接都已得到验证。
LQVPN 用户可先对照新手指引检查客户端与订阅步骤，再到常见问题核对设置。仍无法定位时，可通过面板工单提交经过遮盖的记录，比只描述“连上但打不开”更便于排查。