VPN连上了怎么确认生效？先对比出口 IP，再检查 DNS，最后验证实际使用的应用。客户端的“已连接”通常只说明连接状态或本地代理已经启动，不代表浏览器、会议软件和终端都经过同一条线路。判断是否生效，要把“哪个请求、走哪条路径、得到什么结果”对应起来。
连接状态与出口 IP：先看请求走向
出口 IP 是目标网站看到的公网来源地址。设备经过代理或隧道访问网站时，网站通常看到线路出口的地址，而不是本地网络原来的公网地址。最直接的检查方法，是在连接前后使用同一个检测页面，比较结果，而不是只看客户端的状态图标。
- 断开客户端连接，打开 IP 检测页，记录公网 IP、显示地区，以及页面是否分别提供 IPv4 和 IPv6 结果。
- 连接目标线路，确认订阅中确实选中了该线路，且配置已启用。重新发起检测，不只查看原来留在页面上的结果。
- 比较地址是否变化，再核对客户端的连接记录或规则命中结果，确认检测页面的请求经过代理，而不是直连。
- 切回日常分流模式后再测一次。临时全局代理下通过，并不能证明日常规则也覆盖了目标应用。
地址发生变化，是这次请求改变出口的有力证据；地址未变，则需要结合规则判断。如果检测网站被设置为直连，结果不变可能正是预期行为。反过来，即便检测网站显示线路出口，也不能据此断定所有应用都已经被接管。
系统代理与隧道模式：确认接管范围
日常所说的 VPN 客户端，可能使用系统 VPN 接口，也可能只是设置系统代理。系统代理主要面向愿意读取这些设置的程序；TUN 模式通过虚拟网络接口接管路由，覆盖范围通常更广，但仍然受路由、排除列表和分流规则影响。名称相似，不意味着工作范围相同。
| 当前方式 | 通常影响什么 | 需要额外检查什么 |
|---|---|---|
| 系统代理 | 遵循系统代理设置的浏览器与应用 | 应用是否忽略代理，是否启用了自己的代理配置 |
| 浏览器代理扩展 | 该浏览器中被扩展规则覆盖的请求 | 其他浏览器、桌面应用和终端不会因此自动接管 |
| TUN 或系统 VPN 接口 | 被路由与配置纳入隧道的流量 | 应用排除、IPv6 路由、DNS 设置及 UDP 支持 |
| 应用内代理 | 该应用明确交给代理的连接 | 代理地址、认证、域名解析方式是否匹配 |
“全局模式”也容易被误解。有些客户端的全局，只表示进入代理内核的请求统一走代理，并不负责让所有程序都进入内核。若程序根本没有读取系统代理，切换规则模式未必有帮助；此时应按客户端说明检查 TUN 或应用内代理，而不是反复更换节点。
订阅链接用于获取线路与配置，不是接管流量的开关。导入成功后，还要选择有效配置并启动连接。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议名称也不能单独证明接管范围；客户端版本、协议支持与实际路由都要匹配。不要把订阅链接粘贴到公开检测网站，它可能包含访问凭据。
DNS 检查：解析路径是否符合预期
DNS 负责把域名解析为地址。网页请求经过线路，并不自动意味着解析也经过同一路径。系统 DNS、客户端内置解析、浏览器的安全 DNS，以及应用自行发起的加密 DNS，都可能参与其中。检查 DNS 的目标是确认真实解析路径与配置一致，而不是看到陌生的解析服务商就判定异常。
可以使用可信的 DNS 泄漏检测页面发起新域名查询，观察它报告的递归解析器，再与客户端 DNS 配置对照。这类页面通常反映最终向检测域名查询的解析器，不能完整还原设备到解析器之间的所有路径。公共解析服务也可能使用分布式出口，因此解析器地区不必与线路出口地区完全相同。
若预期国际域名通过隧道解析，却持续出现本地网络运营商的解析器，应检查客户端是否接管 DNS、浏览器是否另设安全 DNS，以及系统里是否残留手动配置。规则允许国内域名使用本地 DNS 时，本地解析本身不等于泄漏；关键是哪些域名被送到了哪里，是否违背了既定策略。
终端中的 nslookup 或 dig 可以辅助观察解析结果，但它们不一定复现浏览器的安全 DNS 行为。相同域名得到相同地址，也不代表经过相同解析器；得到不同地址，也可能只是内容分发网络的正常调度。
分应用验证：浏览器通过不代表全部通过
应当用真正要使用的应用完成验证。浏览器、命令行、会议软件和游戏的网络栈可能不同；网页可以经由代理访问，而桌面应用仍在直连。客户端若提供连接记录，优先观察目标域名或进程、命中的规则，以及最终出站方式。界面名称随软件不同，以实际功能为准。
- ✅ 浏览器：检查代理扩展是否覆盖系统设置，重新发起 IP 检测，并观察检测域名对应的连接记录。
- ✅ 桌面应用：退出后重新打开，触发需要联网的实际操作，再查看该进程或目标域名是否进入预期出站。
- ✅ 终端：检查程序自身的代理选项和代理环境变量。命令行工具可能不读取桌面的系统代理设置。
- ✅ 会议与实时应用：分别验证登录、加入会议、语音和画面。登录页面可用，并不能说明媒体传输路径也正常。
- ❌ 只看任务栏图标、单个网页能否打开，或客户端内的节点延迟结果，就认定所有应用已经生效。
Windows 与 macOS 上，系统代理和隧道权限应分别检查。Android 需要留意分应用包含或排除列表，以及省电策略是否让客户端在后台停止工作。iOS 也应核对客户端配置中的路由与排除规则。系统出现 VPN 标志，只能说明接口状态，不能替代目标应用的实际测试。
如果能在应用内查看当前会话的来源地址，可把它作为辅助证据，但历史登录记录可能有延迟。不要为了验证而在不熟悉的网站输入账户凭据，也不要公开包含订阅地址、访问令牌或个人会话信息的调试日志。
看似连接却未生效：按症状缩小范围
浏览器生效，其他应用仍然直连
先排查浏览器是否独自使用了扩展代理，再看桌面应用是否支持系统代理。若需要更广的接管范围，按 使用指南 启用客户端支持的隧道方式，并确认权限授权完成。切换后重新启动目标应用，避免继续复用旧连接。
出口地址已变，网站地区仍然不对
网站可能综合账户地区、付款资料、定位权限、Cookie 和 IP 数据库作出判断。使用新的浏览会话有助于区分缓存因素，但不会改变账户本身的地区属性。先核对出口地址，再分析服务自己的判定；网站展示的内容不能单独作为线路失效的证据。
部分请求绕过线路，或只有实时功能失败
分别检查 IPv4 与 IPv6。若客户端没有接管 IPv6，而应用优先使用它，就可能出现不同出口。WebRTC 检测显示的局域网地址或 mDNS 名称不等于公网泄漏；更值得核对的是是否暴露了本地网络原有的公网地址，以及对应流量是否在预期接管范围内。
实时功能还可能涉及 UDP。能加载网页只说明相关网页连接可用，不能证明实时媒体传输正常。应检查客户端、线路和当前配置的 UDP 支持，以及目标应用的回退行为，不要把所有失败都归因于 DNS。
更换线路后结果没有变化
检查是否仍有旧连接被复用、切换是否实际应用，以及检测域名是否被规则固定为直连。同时运行的代理、VPN 或安全软件也可能争用路由与 DNS。先保留需要验证的连接工具，记录设置后逐项排除，避免连续修改导致无法判断原因。
检查结论：证据对应到具体请求
一份有用的检查记录，应包含当时的网络环境、客户端模式、所选线路、目标应用、出口检测结果和规则命中情况。需要求助时，可以通过 帮助中心 提供脱敏后的这些信息。仅描述“显示连接但打不开”，通常无法区分解析、路由与服务端限制。
目标请求的出口符合预期，DNS 解析策略与配置一致，实际应用的连接记录或功能测试也相互印证，才适合判断该场景已生效。这是针对当前应用与当前配置的结论，不是对整台设备所有流量的永久保证。
连接验证也不等于隐私审计。VPNIz 以“匿名无日志”作为隐私策略主话术；出口变化本身不能验证日志策略，也不能消除网站登录账户、浏览器 Cookie 或设备权限带来的识别。线路负责传输路径，账户与应用隐私设置仍需分别管理。