判断 VPN 生效：看请求，不只看连接图标
VPN 到底生效了没有？出口 IP 和 DNS 是检查起点，但不能只看一个检测页面。客户端显示“已连接”，通常说明本地连接或隧道已经建立；浏览器、聊天软件和命令行是否使用这条连接，还取决于系统代理、隧道路由、应用设置和分流规则。
先确定自己的目标：是让某个网站经过代理，还是让设备上的大部分网络请求进入隧道？规则模式允许部分网站直连，这可能正是预期结果。把“所有请求都必须换出口”当成唯一标准，反而容易将正常分流误判为故障。
完整验证需要分别回答：目标请求从哪里出去，域名由谁解析，实际使用的应用有没有采用同一套路径。下面按连接前记录、连接后对比、逐项排错的顺序操作，不需要凭下载速度猜测。
| 检查项目 | 能够说明什么 | 不能单独证明什么 |
|---|---|---|
| 出口 IP | 当前检测请求被网站看到的公网来源 | 其他应用、其他网站也经过代理 |
| DNS 检测 | 本次测试域名所使用的递归解析出口 | 设备上的全部域名查询都采用相同路径 |
| 客户端连接记录 | 应用请求匹配的规则和选用的出站 | 远端服务已正常返回完整内容 |
| 实际应用访问 | 目标功能在当前配置下能否使用 | 访问成功就代表连接具备全部隐私保护 |
出口 IP：先留基线，再做连接对照
选择可信的公网 IP 查询页面，留意它展示的是访问者地址，而不是网站服务器地址。检测站本身会收到访问请求，不要向其提交订阅链接、账号凭据或客户端配置。IP 归属地数据库可能存在更新滞后，城市名称尤其不能当作线路物理位置的精确证明。
- 记录直连状态。在允许短暂直连的测试环境里，断开客户端，打开查询页面，记下公网 IP、网络运营方，以及页面是否分别显示不同地址族的结果。
- 记录代理配置。连接目标节点，记下当前使用规则模式还是全局模式，以及是否启用系统代理或 TUN。测试期间保持同一网络，避免切换无线网络造成基线变化。
- 重新发起查询。刷新检测结果，必要时重新打开页面。将地址与连接前记录比较，再查看客户端是否出现这次访问的连接记录。
- 交叉检查。换一个可信查询页面重复操作。若结果不同，先检查两个检测域名是否匹配了不同规则，不要立刻认定其中一个结果错误。
连接后地址改变，说明这次查询的出口发生了变化；地址不变，则需要继续检查检测域名是否直连、浏览器是否绕过系统代理、客户端是否只完成了节点连接却没有接管流量。不能仅凭地址变化判断服务是否记录日志，也不能把网页显示的地区直接等同于所有应用看到的地区。
DNS 泄漏：区分解析位置与传输路径
DNS 的作用是把域名解析为可连接的地址。DNS 检测页面通常通过生成测试域名，观察哪些递归解析服务向其查询。页面显示的可能是公共解析商或其出口位置，不一定是设备直接连接的服务器，也不一定与代理节点位于同一地区。
因此，DNS 所在地区与出口 IP 不同，不足以单独判定泄漏。真正要核对的是：按照当前配置，本应经受保护路径发送的查询，是否被意外发往本地网络或运营商解析服务。规则模式也可能有意让直连域名在本地解析，不能脱离规则目标判断。
- 连接前后分别运行可信 DNS 检测，记录解析服务名称与网络归属，而不只是看地图上的国家或地区。
- 查看客户端的 DNS 设置，确认直连域名与代理域名分别使用什么解析策略，是否启用了 DNS 接管。
- 检查浏览器的“安全 DNS”等选项。浏览器可能通过加密 DNS 独立解析，绕开操作系统的解析设置；加密查询是否经过隧道仍取决于路由。
- 结合连接记录确认解析服务的访问路径。发现意外的本地解析后，调整配置，再使用新的测试查询复测，避免只看缓存结果。
Windows 可用下面的命令了解命令行解析器默认联系的服务器。它是定位线索，不是完整的 DNS 泄漏测试：浏览器可能使用独立解析器，代理也可能在远端解析域名。
nslookup example.com部分客户端采用 Fake-IP 机制，先向应用返回合成地址，再由客户端关联原始域名并决定出站。因此，系统工具显示的地址未必是目标站点的真实地址。不要仅因出现合成结果就手动替换 DNS；先查阅对应客户端的配置说明。
浏览器正常，其他应用为何仍然直连
“系统代理”通常只是告诉愿意遵循该设置的应用使用本地代理端口，并不强制接管设备全部流量。浏览器可能遵循设置，而游戏、命令行工具或带独立网络栈的软件不一定遵循。浏览器扩展也可能只影响浏览器内部，不能代表系统层面的连接状态。
TUN 模式通过虚拟网络接口和路由接管流量，覆盖面通常更广，但仍受权限、路由排除、DNS 配置与客户端实现影响。“全局模式”在许多代理客户端里只表示已被接管的请求统一选择代理出站，不等于所有应用都会自动进入客户端。
- ✅ 浏览器：检查代理扩展、系统代理与安全 DNS，确认没有互相覆盖。
- ✅ 桌面应用：查看是否提供独立代理选项，并在客户端连接列表中查找该应用的请求。
- ✅ 命令行工具：核对工具自身代理参数和代理环境变量，不把浏览器结果直接套用到终端。
- ✅ 游戏及通话应用：确认相关流量能否被接管，尤其留意 UDP 支持与应用的路由设置。
- ❌ 只看到客户端流量计数增加，就判断所有应用都已受保护；增加的流量可能只来自后台请求。
Windows、macOS 上的系统代理与 TUN 往往是不同开关；移动平台通常通过系统提供的 VPN 接口工作，但仍可能存在按应用分流或排除项。Linux 环境中，桌面代理设置与终端环境变量也不必然同步。菜单名称因客户端而异，应按功能核对，而不是机械寻找同名按钮。
用连接记录核对规则与节点
打开客户端的连接列表或诊断记录，再主动访问目标网站。优先确认请求的域名、匹配规则、出站名称和连接结果。若记录显示直连，检查域名规则、进程规则及最终兜底规则；若显示代理但访问失败，则继续查节点可达性、远端返回或目标服务限制。
网页往往还会请求登录、图片、视频和接口域名。主页面可以打开，不代表这些请求都成功。遇到“页面有文字但登录失败”时，观察失败操作新产生了哪些连接，比反复切换首页更容易定位问题。浏览器开发者工具可以辅助找出失败域名，但其中的远端地址可能是本地代理或中间连接地址，并非最终公网出口。
为了区分规则问题和节点问题，可以临时将已接管流量切换到全局代理后重试。若功能恢复，重点检查分流遗漏；若仍失败，则检查客户端接管范围、节点连接和目标服务自身状态。测试结束后恢复原来的分流策略。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 属于不同代理协议或传输方案，客户端必须支持订阅中实际提供的配置。协议名称本身不能证明 DNS 已受保护。IEPL 专线、中转与直连描述的也主要是线路路径组织，不会替代终端的代理接管与规则设置。
地址族、WebRTC 与断线后的复查
网络可能同时提供 IPv4 与 IPv6。若配置只接管其中一种，支持另一种地址族的网站仍可能采用不同出口。查询页面只显示一种结果时，不应据此推断另一种也已受保护。应选择能够分别检查两种地址族的工具，并结合客户端的路由支持判断。
浏览器的 WebRTC 功能用于实时通信，可能使用与普通网页请求不同的网络路径。检测中出现本地私有地址、经过隐藏处理的本地主机标识，与出现直连公网地址不是同一回事。重点关注是否暴露了不符合预期的公网来源；即便没有发现异常，也不能据此证明整个设备所有流量都已接管。
还要测试断线后的行为。关闭远端连接、电脑休眠恢复或切换网络时，应用可能重连，也可能回退直连。仅在可接受短暂直连的测试环境中验证这些情况，并检查客户端是否提供且正确启用了连接中断保护。不能因为软件叫 VPN，就默认它一定阻断断线后的网络请求。
检测结果矛盾时，按这个顺序处理
先查“有没有接管”，再查“接管后走哪里”，最后查“远端是否可用”。这个顺序能避免把应用未使用代理误当成节点故障，也能避免用更换 DNS 去处理实际上由目标网站限制导致的问题。
- IP 没变：检查检测域名是否直连，浏览器是否使用了独立代理，以及系统代理或 TUN 是否真正启用。
- IP 变了，DNS 看起来仍在本地：检查解析服务归属、浏览器独立 DNS、客户端 DNS 分流与接管记录，不只凭地区判断。
- 浏览器可用，应用不可用：检查该应用是否遵循系统代理，有没有独立代理设置，以及相关流量是否进入 TUN。
- 切换全局后恢复：检查失败请求对应的规则与关联域名，不必长期关闭全部分流。
- 客户端没有任何目标记录：优先查接管范围；若日志本身未启用，则先确认记录功能，再作判断。
需要帮助时，可提供操作系统、客户端名称、当前模式、问题发生步骤和经过脱敏的连接记录。不要公开完整订阅链接、认证令牌或包含凭据的配置。订阅链接通常具有访问配置的能力，泄露后应通过服务提供的管理方式更新。
结论：生效与否，要按具体应用和请求判断。出口 IP 对照确认网页来源，DNS 检测辅助核对解析路径，连接记录解释分流结果，实际操作验证目标功能。上述证据相互吻合，才能判断当前配置符合预期；客户端上的连接图标只能作为起点。
Z7VPN 的客户端入口位于用户面板，登录后获取订阅与客户端信息。首次导入后，仍应按本文流程验证设备上的实际走向；具体操作可参考使用教程，配置疑问可通过联系页面反馈。