怎么确认 VPN 真的生效了?查出口 IP 与 DNS 的完整方法

确认 VPN 是否真的生效，不能只看客户端里的“已连接”。这个状态通常只表示客户端与远端节点完成了握手，未必表示浏览器、命令行工具和其他应用的流量都已经进入指定线路。可靠的检查方法是先记录连接前的出口 IP，再连接线路并重新查询，同时检查 DNS 请求和不同应用的实际访问路径。

如果出口 IP 已改变，说明至少有一部分网络请求经过了远端线路；如果 DNS 仍由本地网络处理，或者某个应用显示的出口没有变化，则可能存在分流规则、系统代理、隧道权限或应用自身代理设置方面的问题。下面按从容易到深入的顺序逐项检查。

出口 IP 是最直接的检查入口

出口 IP 是目标网站看到的公网地址。未连接线路时，请求通常从当前网络直接发出；连接并正确接管流量后，请求会先到远端节点，再由节点访问目标网站，因此网站看到的出口地址和地区通常会改变。

可以先打开本站的 IP 查询 页面，记录当前显示的地址、网络服务商和地区。随后连接目标线路，刷新查询页面。为了避免浏览器缓存旧结果，建议重新打开页面，或者使用隐私窗口再次查询。若前后结果不同，且连接后的地区与所选线路相符，浏览器流量大概率已经经过该线路。

1. 断开客户端中的线路，关闭浏览器里可能单独启用的代理扩展。
2. 打开 IP 查询页面，记录当前出口地址与地区。
3. 连接目标线路，等待客户端明确显示连接完成。
4. 重新打开查询页面，不要只查看原页面中未刷新的旧结果。
5. 对比连接前后的出口地址、地区和网络服务商信息。

为什么线路已连接，出口 IP 却没有变化

最常见的原因是客户端只设置了系统代理，而当前应用没有遵循系统代理。部分命令行工具、游戏启动器、虚拟机和带有独立网络设置的软件会绕过系统代理。浏览器扩展也可能覆盖操作系统中的设置，让同一台设备上的不同浏览器走不同路径。

另一个原因是分流模式。规则可能把本地网站、局域网地址或特定应用设为直连。如果用于查询的网站恰好匹配直连规则，结果就不会改变。此时可以暂时切换到全局模式进行诊断；确认问题后，再恢复分流并检查具体规则，而不是长期依赖全局模式。

• ✅ 连接前后使用同一个查询页面，并主动刷新结果。
• ✅ 检查客户端当前是全局、规则分流还是仅代理指定应用。
• ✅ 暂停会改写代理设置的浏览器扩展，再进行对比。
• ❌ 不要把客户端中的连接时长当作流量已接管的证据。
• ❌ 不要只根据网页语言或搜索结果地区判断出口位置。

继续检查 DNS 解析 是否走对路径

访问域名之前，设备通常需要先把域名解析成可连接的地址。这个过程由 DNS 完成。即使网页流量经过远端线路，DNS 请求仍可能被发送到本地网络指定的解析服务，这就是常说的 DNS 泄漏。它不一定导致网页打不开，但会让本地解析方看到设备查询过哪些域名，也可能造成解析结果与出口地区不一致。

检查时，应观察连接线路后实际使用的 DNS 服务来源，而不只是查看系统设置里填写了什么地址。客户端可能通过隧道转发 DNS，也可能启用加密 DNS；浏览器还可能使用自身的安全 DNS 设置，绕开客户端或操作系统。因而，系统、客户端与浏览器三个层级都需要纳入判断。

DNS 检查结果应该怎样理解

检测页面显示的解析服务不一定与出口 IP 属于同一家网络，这是正常的。公共解析服务、加密 DNS 和节点侧转发都可能让两者显示不同机构。真正需要关注的是：连接前后解析路径是否按预期变化，以及是否仍出现明确属于当前本地网络的解析服务。

如果浏览器开启了独立的安全 DNS，它可能把查询直接发送给浏览器指定的服务。此时结果并不必然表示客户端失效，而是说明 DNS 路径由浏览器单独决定。要验证客户端的 DNS 接管能力，可以暂时关闭浏览器的独立解析设置，重新连接后再测试。完成诊断后，再根据隐私与兼容需求决定使用哪一层的 DNS 功能。

系统代理 与隧道模式为什么会产生不同结果

很多桌面客户端提供系统代理和隧道模式。系统代理会修改操作系统的代理入口，遵循该入口的应用会把请求交给客户端；不读取系统代理的应用则可能继续直连。隧道模式通常通过虚拟网络接口接管更多网络流量，因此对不支持系统代理的程序兼容性更好，但需要相应的系统权限，并可能与其他网络工具发生路由冲突。

这也解释了一个常见现象：浏览器中的 IP 已改变，命令行下载、游戏或开发工具却仍使用原出口。浏览器通常支持系统代理，而某些工具会直接建立连接。反过来，如果浏览器装有独立代理扩展，它也可能在系统没有连接线路时单独生效。

协议名称不决定接管范围

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 描述的是客户端与服务器之间如何传输数据。它们会影响握手、传输方式和网络适应性，但不会自动决定操作系统中的全部应用是否被接管。真正决定覆盖范围的是客户端如何把本机流量送入协议连接，例如系统代理、虚拟网络接口、应用级代理或路由规则。

因此，看到协议已经握手成功，不代表所有请求都进入了该协议。诊断时应把“远端连接是否建立”和“本机流量是否导入连接”分开处理。前者失败通常表现为节点无法连接；后者失败则更容易出现客户端显示正常，但出口 IP 不变或只有部分应用生效。

按应用逐个验证，找出部分生效的位置

如果浏览器检查正常，下一步应按实际使用场景逐个验证。不要假定同一设备上的软件会共享完全相同的网络路径。浏览器、终端、游戏平台、虚拟机和容器都可能拥有独立的代理、DNS 或路由环境。

1. 先测主要浏览器：关闭代理扩展后查询出口 IP，再恢复扩展并复测，用于判断扩展是否覆盖系统设置。
2. 再测另一个浏览器：如果结果不同，优先比较两者的代理扩展和安全 DNS 设置。
3. 检查命令行工具：查看工具是否读取系统代理，或是否配置了独立的代理环境。不要仅凭浏览器结果推断终端流量。
4. 检查虚拟环境：虚拟机和容器可能使用独立网关。宿主系统的代理配置不会必然传入其中。
5. 最后验证目标应用：完全退出后重新打开，避免旧连接继续沿用切换线路前建立的会话。

长连接尤其容易干扰判断。某些应用在切换线路前已经建立连接，线路切换后仍尝试复用旧会话。此时客户端可能已经接管新请求，但旧会话尚未重建。退出应用、断开线路、重新连接，再启动应用，可以让测试条件更清晰。

• ✅ 同时记录浏览器、目标应用和 DNS 的结果，不混为一个结论。
• ✅ 修改分流规则后彻底重启目标应用，让旧连接失效。
• ✅ 检查规则顺序，确认更宽泛的直连规则没有提前命中。
• ✅ 虚拟机与容器应在各自网络环境中独立验证。
• ❌ 不要根据客户端流量计数增加就判断目标应用已经走线路。

常见的“已连接但没生效”情况

订阅已导入，但节点配置没有更新

订阅链接用于向客户端提供节点与规则信息。成功导入只表示客户端读取到了配置，不表示当前节点一定可连接，也不表示后续变更已经同步。遇到节点信息异常时，可以手动更新订阅，重新选择线路，再检查出口 IP。更新前若自行修改过配置，还应留意客户端是否覆盖了本地改动。

分流规则把目标域名设为直连

规则模式会按域名、地址范围、应用或其他条件决定路径。若目标服务被直连规则匹配，客户端仍会显示连接状态，但该请求不会经过远端线路。诊断时可暂时使用全局模式对比。如果全局模式有效，问题通常位于规则集、规则顺序或域名匹配，而不是节点本身。

浏览器代理扩展覆盖了系统设置

扩展可以把浏览器请求发送到另一代理，也可以设置为直连。此时浏览器结果可能与系统中的其他应用完全不同。应先停用扩展，使用系统路径测试，再单独启用扩展。这样可以明确是哪一层在控制浏览器流量。

多个网络工具同时修改路由

两个客户端同时启用系统代理或虚拟网络接口时，后启动的软件可能覆盖前者设置，路由优先级也可能发生变化。诊断阶段只保留一个网络工具运行，确认出口和 DNS 正常后，再逐个恢复其他工具。这样比反复更换节点更容易定位冲突来源。

休眠或网络切换后保留旧状态

设备从休眠恢复，或者从一个网络切换到另一个网络后，客户端界面可能仍显示已连接，但底层连接已经失效。此时应主动断开并重新连接。如果仍无变化，可以退出客户端后重新打开，并再次确认系统代理或虚拟网络接口是否恢复。

不同平台的检查重点

Windows 上应重点检查系统代理是否残留，以及隧道模式使用的虚拟网络接口是否正常。客户端异常退出后，系统代理偶尔可能仍指向已经停止工作的本地端口，表现为断开线路后网页也无法访问。重新打开客户端并正常断开，通常比直接删除网络配置更稳妥。

macOS 的不同客户端可能使用系统代理或网络扩展。若权限未完整授予，界面可能能够导入订阅和选择节点，但流量接管不完整。可以在系统网络设置中确认对应配置是否启用，再分别检查浏览器与不读取系统代理的应用。

移动端客户端通常通过系统提供的 VPN 接口建立隧道。若同时启用了应用分流，应确认目标应用是否被包含在规则中。切换网络后，重新连接并复测出口 IP 与 DNS，可以排除旧网络会话造成的干扰。

Linux 环境差异较大。桌面应用可能读取图形环境中的代理设置，命令行工具则可能依赖各自配置或环境变量。使用虚拟网络接口时，还要检查路由和 DNS 是否由客户端正确更新。浏览器测试成功后，仍应在实际使用的终端工具中单独验证。

形成一套可重复的验证流程

一次可靠检查应包含基线、连接后结果、DNS 路径和应用级结果。先在断开状态记录出口，再连接目标线路复测；随后检查 DNS 是否仍由本地网络处理；最后打开真正需要使用的应用，确认它没有被直连规则或独立设置绕过。

如果出口和 DNS 都符合预期，但目标服务仍无法使用，问题可能不在客户端是否生效，而在目标服务自身策略、线路质量、账号区域、缓存或应用会话。此时继续重复连接没有太大意义，应把检查范围转向目标应用，并保留已经确认正常的网络条件。