VPN 是否生效：新手完整验证指南

判断 VPN 是否生效，不能只看客户端里是否出现“已连接”。这个状态通常只能证明客户端与远端节点完成了会话建立，不能证明浏览器、桌面软件和系统 DNS 都已按预期经过线路。可靠的验证应同时检查出口 IP、DNS 解析路径和具体应用的连接结果。

实际排查时，先记录未连接状态，再连接线路并重复相同测试。只有前后结果可以对照，才能区分线路未接管流量、分流规则主动直连、应用忽略系统代理，以及检测页面缓存旧结果等情况。下面的流程从最容易确认的出口地址开始，逐步深入到路由模式、协议和平台差异。

先理解“已连接”究竟表示什么

客户端显示已连接，通常表示本地软件已经与服务器建立加密会话，认证和协议握手也已经完成。对于 Shadowsocks、VMess、Trojan、VLESS 等常见代理协议，这个状态意味着本地代理入口可以向节点发送数据；对于基于 UDP 和 QUIC 特性的 Hysteria2、TUIC，状态同样主要反映传输会话是否建立。它并不自动等于所有系统流量已经进入会话。

流量是否真正经过线路，还取决于客户端采用哪种接管方式。系统代理会修改操作系统的代理设置，通常只影响遵循该设置的程序；TUN 模式通过虚拟网络接口接管更广泛的 IP 流量；浏览器扩展通常只处理浏览器内部请求。部分应用拥有独立网络栈、内置代理或自己的 DNS 机制，可能不会遵循系统代理。

用出口 IP 完成第一轮验证

出口 IP 是最直观的检查项。先断开客户端，打开一个能够显示公网地址和大致出口地区的检测页面，记录当前结果。随后连接目标线路，刷新检测页面。如果地址与出口地区发生符合线路选择的变化，可以确认这次网页请求已经经过远端出口。

测试时应尽量使用同一个浏览器、同一个检测页面和相近的网络环境。浏览器缓存、页面脚本没有重新执行，或网络在 Wi-Fi 与其他连接之间切换，都会让对照失去意义。仅点击普通刷新仍显示旧数据时，可以关闭检测标签页后重新打开，或者使用浏览器的隐私窗口再次检查。

1. 断开线路，记录当前公网出口地址和地区。
2. 关闭可能自动选择节点的功能，手动连接需要验证的线路。
3. 重新打开检测页面，不要只依赖之前标签页里的旧结果。
4. 比较连接前后的地址与地区，并确认结果符合所选节点。
5. 再用实际需要访问的应用测试，避免只验证浏览器。

如果出口地址没有变化，先检查客户端模式。处于“系统代理”模式时，检测浏览器必须遵循系统代理；若浏览器使用独立代理设置，可能绕过客户端。处于“规则”模式时，检测站点也可能被规则判定为直连，此时可以暂时切换到全局接管进行诊断。全局模式适合定位问题，不一定适合作为长期配置。

还要留意 IPv4 与 IPv6 的差异。有些网络同时提供两类地址，而客户端只接管其中一种。检测页面如果优先使用未被接管的地址，就可能暴露本地出口，或出现不同页面显示不同地区的现象。排查时应分别查看两类连接结果，并确认客户端、操作系统和当前节点对它们的处理方式一致。

检查 DNS 是否沿预期路径解析

访问域名之前，设备通常需要先把域名解析为 IP 地址。DNS 泄漏是指本应通过指定线路或指定解析器处理的查询，意外发送给本地网络提供的解析服务。此时网页内容可能经过远端出口，但域名查询仍留在本地路径。它不一定造成连接失败，却说明实际流量路径与配置预期不一致。

进行 DNS 检查时，应先连接线路，再打开 DNS 检测页面并发起新的查询。重点不是要求解析服务器一定与出口服务器位于同一城市，而是判断结果是否来自预期的解析方案。例如，客户端可能使用服务端解析，也可能明确指定公共解析器；只要结果与设置一致，就不能仅凭地理位置不同认定为泄漏。

浏览器的安全 DNS 功能也会影响结果。启用后，浏览器可能绕过操作系统的普通解析流程，直接向浏览器配置的解析服务发送加密查询。这样得到的检测结果可能与其他应用不同。排查阶段可以分别测试启用和停用该功能时的表现，但不要在不了解原设置的情况下长期修改。

• 只有浏览器结果异常：检查浏览器安全 DNS、扩展和独立代理设置。
• 所有应用都出现本地解析：检查客户端 DNS 接管、TUN 配置和系统网络优先级。
• 切换节点后仍保留旧解析：清理系统与浏览器 DNS 缓存，再发起新的域名请求。
• 结果来自明确指定的公共解析器：对照客户端设置判断，不要只按地区猜测。

在规则分流环境中，DNS 还会参与域名分类。部分客户端先解析域名再匹配 IP 规则，部分客户端优先依据域名规则决定直连或代理。如果规则集过旧、域名被错误分类，可能出现页面主体走线路、图片或登录接口走直连的混合状态。此时需要查看连接日志里的域名、匹配规则和最终出站，而不是反复更换节点。

验证浏览器与桌面应用是否分别生效

通过网页确认出口后，还应测试实际使用的软件。浏览器、下载工具、游戏、命令行程序和商店应用对系统代理的支持并不一致。有些程序自动读取系统代理，有些只支持自己的代理配置，还有一些更适合通过 TUN 虚拟接口接管。只测一个网页，容易漏掉分应用差异。

可先选择一个能够显示网络地区或连接状态的网页服务，在不同浏览器中分别打开，再测试目标桌面应用。如果一个浏览器的出口变化而另一个没有，问题通常位于浏览器代理设置、扩展或安全 DNS。如果浏览器正常但桌面软件仍走本地网络，优先检查该软件是否忽略系统代理，以及客户端是否提供 TUN 或应用级分流。

分流规则本身并不是故障。规则模式通常会让本地服务直连，让指定域名或地区经过线路。因此，看到不同网站使用不同出口，可能正是配置的预期行为。验证时应先明确目标：是希望所有流量统一经过线路，还是只让特定应用和域名经过线路。目标不同，正确结果也不同。

若客户端支持连接日志，可以在打开目标应用的同时观察新出现的连接记录。日志通常会显示目标域名或地址、命中的规则以及最终选择的直连或代理出站。日志比单纯观察“已连接”更有诊断价值，但其中可能包含访问域名，分享截图前应先检查并遮盖不希望公开的信息。

理解直连、中转与 IEPL 线路的验证差异

线路名称描述的是设备到出口之间采用的路径，不会改变验证的基本原则。直连通常表示设备直接连接远端节点，路径结构简单，但质量更依赖当前网络到节点的公网路由。中转线路会先连接入口或中继节点，再由中继转发到出口，用于调整跨网路径或改善某些网络环境下的连接表现。

IEPL 通常指运营商提供的国际以太网专线能力。在代理服务的线路结构中，它常用于入口到服务商侧交付点之间的专用传输段，最终访问目标网站时仍可能从出口接入公共互联网。不同服务商对线路名称的使用方式可能不同，因此应结合线路说明理解，不能仅凭名称推断整条路径的所有细节。

无论使用直连、中转还是 IEPL，出口 IP 检测看到的通常都是最终出口，而不是中继节点。中转是否存在，也不能只靠普通网页检测准确判断。对普通使用者而言，更重要的是确认最终出口地区正确、目标应用确实走线路、DNS 路径符合设置，以及切换线路后旧连接能够重新建立。

线路切换后，一些应用会继续复用已经建立的长连接，所以出口检测页面已经更新，应用内部会话却仍保持旧路径。此时应关闭应用内的活动页面，必要时完全退出应用后重新启动。若客户端提供断开时阻止流量的选项，还应单独验证线路意外断开后，应用是停止联网还是回落到本地网络。

订阅导入成功但流量没有经过节点怎么办

订阅链接的作用是向客户端提供节点和相关配置。成功导入只能说明客户端能够读取订阅内容，不代表节点可连接，也不代表系统流量已经被接管。更新订阅后，应确认当前实际选中的节点、代理模式、系统代理或 TUN 状态，以及规则集是否完成加载。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 对客户端能力及传输参数有不同要求。较旧的客户端可能能够显示订阅中的节点名称，却不能完整识别某些协议字段。遇到节点一直超时、握手失败或连接后没有流量时，应先使用服务提供方支持的客户端版本重新导入，而不是手工猜测加密方式、传输层或证书参数。

• 确认订阅内容已经更新，当前选择的不是已移除或失效配置。
• 确认客户端支持节点所使用的协议和传输参数。
• 检查系统代理或 TUN 是否真正启用，而不只是节点按钮处于连接状态。
• 临时使用更直接的路由模式测试，以排除规则误匹配。
• 查看连接日志，区分节点握手失败、DNS 失败和路由直连。
• 恢复规则模式后，再逐个验证浏览器与目标应用。

如果客户端同时提供“延迟测试”和“连接测试”，还要理解两者并不等价。节点能够响应探测，只表示探测请求可达；真实网页和应用还涉及 DNS、TCP 或 UDP 连接、TLS 握手、路由规则及目标服务自身状态。因此，节点列表显示可用后仍应完成出口 IP 和实际应用验证。

不同平台上的重点检查项

Windows

Windows 客户端常见系统代理与 TUN 两种接管方式。系统代理适合遵循操作系统代理设置的软件，但部分命令行工具、商店应用或独立网络程序可能绕过它。TUN 覆盖范围通常更广，但可能受到其他虚拟网卡、安全软件和路由优先级影响。排查时可查看系统代理是否被写入，并确认退出客户端后设置是否正确恢复。

macOS

macOS 客户端可能通过系统代理或 Network Extension 建立隧道。系统设置中的 VPN 状态与客户端状态应保持一致。如果其他网络工具也安装了网络扩展，规则可能发生竞争。遇到只有部分应用生效时，先停用重复的代理配置，再重新连接并检查出口与 DNS。

iOS 与 iPadOS

移动系统上的客户端通常通过系统提供的 VPN 接口接管流量。状态栏标识说明配置处于连接状态，但应用内已有会话仍可能短暂复用旧连接。切换线路后，可完全关闭目标应用再打开。浏览器内容过滤、私密中继类功能或其他 VPN 配置也可能改变观察结果，应避免同时启用用途重叠的网络配置。

Android

Android 客户端可能支持按应用分流。若某个应用被排除，它会继续使用本地网络，即使其他应用已经经过线路。还应检查系统是否限制客户端后台运行；客户端被暂停后，已有的 VPN 标识和实际连接状态可能不同步。诊断时应保持客户端前台运行，并核对按应用规则。

平台差异不会改变核心验证顺序：先确认客户端会话，再对比出口 IP，随后检查 DNS，最后逐个测试目标应用。不要在尚未确定问题层级时同时修改节点、协议、DNS 和分流规则，否则很难知道是哪项调整真正解决了问题。

已连接但无法访问时的排查顺序

当客户端显示已连接，但网页打不开或目标应用仍使用本地出口时，最有效的方法是一次只改变一个变量。先确认本地网络在断开线路时可正常使用，再检查节点连接；随后检查接管模式、DNS 和分流规则。这样可以把问题定位到本地网络、节点会话、系统路由或单个应用。

1. 断开线路，确认本地网络本身能够正常解析和访问常用页面。
2. 重新连接当前节点，查看客户端日志是否出现握手或认证错误。
3. 更换同类线路测试，区分单个节点问题与客户端配置问题。
4. 检查系统代理或 TUN 状态，并暂时排除其他网络工具的干扰。
5. 使用出口 IP 页面确认检测请求是否进入远端出口。
6. 检查 DNS 结果，再查看规则日志中的匹配与最终出站。
7. 完全退出目标应用后重新打开，避免旧会话继续复用原路径。

如果出口 IP 正确，但某个服务仍显示原地区，可能是该服务保留了账户地区、缓存、定位权限或旧会话信息，并不一定代表线路失效。反过来，如果页面可以打开，也不能据此断定流量一定经过线路；直连同样可能访问成功。最终仍应以出口结果、DNS 路径和应用日志的组合证据判断。

验证完成后，把临时改成全局的路由模式恢复为日常配置，并再次测试关键应用。若需要向技术支持提交问题，建议提供平台与客户端版本、节点协议、接管模式、发生问题的应用类型，以及去除敏感内容后的错误日志。清晰描述“哪个应用没有经过线路”会比只说“VPN 不工作”更容易定位。