VPN连上了怎么确认生效？先做出口 IP 与 DNS 检测，再检查实际使用的应用。客户端的“已连接”通常只说明连接或本地代理已启动，不能单独证明浏览器、聊天软件和其他程序都走了预期线路。
本文不提供虚构的检测结果。你需要在自己的设备上留下连接前后的对照，并结合客户端规则和连接记录判断。出口变化、解析路径与应用路由是不同问题，不能用一个绿色图标代替全部检查。
连接状态与实际出口的区别
常见客户端可能使用系统 VPN 隧道，也可能只是启动本地代理并修改系统代理设置。前者通过系统网络接口接管符合路由规则的流量；后者依赖应用是否遵循代理设置。界面都可能显示“已连接”，实际覆盖范围却不同。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 是不同的代理协议或协议体系，不等于客户端工作模式。看到这些名称，不能直接推断所有流量已经接管。VLESS 本身不提供加密，实际保护还取决于传输层配置；其他协议也应按客户端与服务端的实际配置判断。
| 检查项目 | 能说明什么 | 不能单独证明什么 |
|---|---|---|
| 客户端已连接 | 客户端报告的连接或代理状态 | 所有应用都已进入隧道 |
| 网页出口 IP | 该次网页请求对外呈现的地址 | 其他应用、DNS和所有地址族的路径 |
| DNS 测试结果 | 该测试中参与解析的服务器线索 | 解析请求经过的完整路径及是否加密 |
| 客户端连接记录 | 匹配规则、所选出口及接管的请求 | 未被客户端接管的所有系统流量 |
出口 IP：保留连接前后对照
先选择能够显示公网 IP 的检测页面。可通过搜索“公网 IP 检测”找到工具，但不要为了检测安装来历不明的扩展，也不要输入账户凭据。检测页面会接触你的访问地址；挑选工具时应考虑其隐私说明。
- 记录直连基线。暂停客户端连接，在同一浏览器打开检测页面，记录公网 IP、网络归属和页面标注的地区。不要公开发布完整地址。
- 连接目标线路。确认客户端选中的线路与工作模式。为便于对照，可暂时选择让测试请求经过代理的模式，完成后再恢复日常规则。
- 发起新的检测。重新运行页面测试，不要只看旧截图或缓存内容。对比连接前后的 IP，并检查客户端是否出现对应请求。
- 解释结果。地址变化且请求匹配预期出口，是有效线索；地址未变时，先看测试域名是否被规则指定为直连，再判断连接是否异常。
IP 的地区标注来自数据库，可能滞后或只对应地址注册信息。客户端写着某个地区，而检测网站标注不同，不足以直接判定线路无效。应结合网络归属、线路说明及实际请求记录交叉核对，必要时向支持人员询问。
同样，某个网站能打开，也不证明连接生效：网站可能原本就可直连，或者页面主要内容来自缓存。反过来，出口正确但目标网站打不开，也可能是网站风控、账户限制或该出口被拒绝，并非客户端完全失效。
DNS 检测：核对解析策略
DNS 把域名转换成网络地址。所谓 DNS 泄漏，通常指解析请求绕过了预期隧道或解析策略，让不希望参与的网络解析器接触到查询。它与网页出口是两条检查线：网页经过代理，DNS 仍可能按另一套设置运行。
先在未连接时运行 DNS 检测并记录解析器线索，再连接目标线路重新运行。测试通常通过访问新生成的域名识别参与解析的服务器，因此需要真正执行新测试。只刷新结果页，不一定触发新的查询。
- ✅ 检查客户端是否接管 DNS，以及规则模式是否允许部分域名使用本地解析。
- ✅ 检查浏览器“安全 DNS”设置，了解它是使用系统配置还是指定的加密解析服务。
- ✅ 对照连接记录与解析器归属，确认结果是否符合自己设定的策略。
- ❌ 不要只凭解析器所在地区与出口地区不同，就认定发生泄漏。
浏览器可能使用 DNS over HTTPS，绕过系统配置的解析器，但解析服务连接仍可能经过代理。公共解析器也可能采用分布式网络，测试显示的地点不必与出口一致。因此，“出现公共 DNS”不等于泄漏，“没有本地运营商名称”也不是完整的隐私证明。
不要把 DNS 设置随意改成一个陌生地址。先阅读客户端关于解析、远程 DNS 和分流的说明，再一次只调整一项设置，保留调整前后的结果。
如果测试出现本地网络解析器，而你的目标是让解析全部经过隧道，应检查客户端 DNS 接管、浏览器覆盖设置及系统配置。修改后关闭旧测试页面并重新运行。仍无法解释时，保留脱敏结果与客户端设置供支持人员排查。
分应用验证：浏览器不代表全部
系统代理并非所有应用都会遵循。有的程序自行建立连接，有的只支持特定代理类型，还有的需要完全退出后才读取新设置。浏览器检测通过之后，应继续验证真正要使用的应用，而不是在同一个网页上反复点击。
在 Windows、macOS 或 Linux 上，先确认客户端运行的是系统代理、TUN 模式还是其他隧道模式。TUN 可以扩大流量接管范围，但仍受路由、规则、权限和排除项影响。名称中带“全局”的选项，也可能仅代表已接管请求全部使用代理，并非接管了所有程序。
在 iOS 和 Android 上，检查系统 VPN 状态与客户端的应用排除设置。Android 客户端可能提供按应用代理选项；iOS 的具体覆盖范围取决于客户端实现和系统配置。状态栏标记只能作为辅助信息，仍需在目标应用发起新请求。
- 打开目标应用，执行可识别的联网操作，例如刷新内容或加载新页面。
- 查看客户端记录，核对对应域名或连接是否出现，以及命中了直连还是代理规则。
- 若记录里找不到请求，检查应用排除、代理支持情况和客户端权限；缺少记录也可能只是日志未开启。
- 调整后重新启动目标应用，再复查。不要同时更换线路、改规则和改 DNS，否则难以知道哪项起作用。
命令行工具也可能与浏览器不同。终端程序未必自动读取桌面系统代理，代理环境变量也不一定被所有工具支持。需要测试终端时，应查阅该工具的代理参数说明，不能直接把浏览器结果套用过去。
IPv6 与 WebRTC：补查旁路
设备可能同时具备 IPv4 和 IPv6 联网能力。若隧道只覆盖其中一种地址族，应用可能通过另一条路径发起连接。选择能分别展示这两类公网地址的工具，连接前后都检查；只看到一个地址，不能据此判断另一类流量已经接管。
检测到连接后的 IPv6 与直连基线相同，而客户端本应覆盖所有公网流量时，需要核对 IPv6 路由与支持范围。优先按客户端官方说明处理，不要把系统层面的关闭操作当成所有设备都适用的答案。没有显示 IPv6，也可能只是当前网络或测试工具不支持。
WebRTC 用于浏览器实时通信，其网络路径可能与普通网页请求不同。测试中出现局域网地址或经过隐藏处理的本地标识，不等于泄露了公网出口；若出现直连公网地址，则应继续检查浏览器、客户端的 UDP 接管和路由策略。
这些网页工具只能覆盖各自触发的请求。它们能发现线索，但不能证明设备上不存在任何旁路，也不能仅凭出口 IP 证明隧道加密方式。需要确认加密配置时，应查阅实际协议与传输设置；需要更深入定位时，可由有经验的人结合系统路由或抓包分析。
常见异常：按现象定位
排查时先区分“没经过预期出口”和“经过出口但访问失败”。线路是直连、中转还是 IEPL 专线，主要描述传输路径或线路组织方式，并不自动决定本机 DNS、浏览器和应用分流是否正确。换线路也不能修复所有本地接管问题。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 已连接，网页 IP 不变 | 测试域名是否直连、浏览器代理设置 | 核对规则并重新发起检测 |
| 浏览器有效，其他应用无效 | 应用排除、系统代理支持、隧道模式 | 查看应用请求记录，按需调整接管 |
| 出口变化，DNS 结果不符合预期 | 客户端 DNS 策略、浏览器安全 DNS | 明确解析目标，再逐项调整 |
| 出口正确，目标网站拒绝访问 | 网站错误提示、账户区域与出口限制 | 区分网站政策和线路问题 |
| 切换网络后结果改变 | 连接恢复、系统路由和新网络配置 | 重建连接并重新验证出口与解析 |
如果客户端没有可选线路或配置更新失败，应登录用户面板核对订阅状态与客户端兼容性。订阅链接用于获取线路配置，本身不是连接成功的凭证。更新后仍需选中线路并执行上述验证；也不要把完整订阅链接发给检测网站。
验证结论与日常复查
较可靠的结论应具体写成：目标浏览器的出口符合所选线路，DNS 结果符合设定策略，常用应用的请求匹配预期规则，适用的地址族也已检查。这样的记录比“全部正常”更有用，下次异常时能知道哪一环发生了变化。
更换客户端、修改分流规则、更新系统或切换网络后，可重新做一次对照。截图与日志应先脱敏，隐藏完整公网地址、用户名、订阅链接、访问中的敏感域名和认证信息。需要求助时，说明设备系统、客户端名称、工作模式及问题现象即可开始排查。