VPN连上了没生效?查出口IP、查DNS的完整验证教程

VPN 连上了没生效，不能只看客户端里的“已连接”。这个状态通常只说明客户端与远端节点完成了握手，或者本地代理端口已经启动。它没有直接证明浏览器、命令行工具和其他应用的流量都经过了目标线路。可靠的判断需要依次检查出口 IP、DNS 解析、IPv6 路径和分应用规则。

排查时不要频繁切换节点、协议和系统设置。一次只改一个变量，然后重复同一项测试。这样才能区分是节点问题、路由问题，还是某个应用绕过了代理。下面的方法适用于常见的系统 VPN、系统代理、TUN 模式，以及使用 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 配置的客户端。

为什么“已连接”仍可能没有生效

客户端建立连接后，还需要把流量送进对应的隧道或本地代理端口。这个过程涉及系统代理、路由表、虚拟网卡、DNS 设置和应用自身的网络实现。任何一环没有接管成功，都可能出现“客户端显示正常，但访问结果没有变化”。

不同连接模式的覆盖范围并不相同。系统代理主要影响愿意读取系统代理设置的应用。浏览器通常会读取，但部分命令行程序、游戏、下载工具或自行实现网络栈的软件可能忽略它。TUN 模式通过虚拟网卡处理更广泛的 IP 流量，但仍会受到路由排除项、局域网绕过、分流规则和系统权限影响。

协议名称本身也不能证明覆盖范围。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 描述的是客户端与节点之间如何传输数据。应用流量是否进入这条连接，仍由本地监听端口、系统代理、TUN 和路由规则决定。协议成功握手与全局流量接管是两件事。

先记录未连接时的网络基线

判断是否变化，必须先知道未连接时是什么状态。关闭客户端连接，确认系统代理和 TUN 已恢复，然后记录当前出口 IP、网络运营商信息、IP 类型以及大致地区。可以打开本站的 IP 检测页面完成这一步。

基线测试应使用之后准备验证的同一个应用。如果计划检查浏览器，就在该浏览器里记录。如果问题出现在命令行工具，则还需要从命令行单独测试。浏览器结果不能替代其他应用，因为二者可能使用不同的代理设置。

• ✅ 断开当前连接，并确认客户端不再占用系统代理或虚拟网卡。
• ✅ 在目标应用中打开 IP 检测页面，记录出口 IP、IP 类型和地区。
• ✅ 关闭可能改变网络路径的其他代理扩展或并行客户端。
• ✅ 保持接入网络不变，避免在测试过程中切换有线、无线或其他网络。
• ✅ 重新连接目标节点后，使用同一应用、同一检测页面复测。

如果断开后仍显示节点出口，说明系统代理、浏览器扩展、虚拟网卡或后台进程可能没有恢复。此时继续做连接测试没有意义，因为基线已经被旧配置污染。应先退出相关客户端，检查系统网络设置，再重新建立基线。

查出口 IP：确认网页流量走向

完成基线后连接目标节点，再次打开 IP 检测页面。为了减少缓存干扰，可以重新加载页面，或使用新的浏览器标签页。若出口 IP 从本地网络地址变为节点出口，并且网络归属与所选线路相符，可以确认这个浏览器标签页的网页请求已经经过代理路径。

出口 IP 变化是最直接的证据，但它只证明当前检测请求的路径。浏览器扩展可能只代理浏览器；系统代理可能只被部分程序读取；分流规则也可能让检测站点经过节点，而其他域名保持直连。因此还要继续检查实际发生问题的应用和目标域名。

出口 IP 没有变化时怎么查

1. 查看客户端是否仅启动了本地代理端口，而没有自动写入系统代理设置。
2. 确认浏览器没有设置独立代理。独立设置可能覆盖系统配置，也可能指向已经失效的旧端口。
3. 检查客户端当前模式。规则模式可能将检测域名判定为直连，可临时使用覆盖范围更明确的模式做诊断。
4. 如果使用 TUN，检查虚拟网卡是否成功创建，以及客户端是否取得修改路由所需的系统权限。
5. 查看运行日志，确认请求是否命中代理规则、直连规则或拒绝规则。

客户端从订阅链接导入配置后，通常会得到节点参数和分组规则，但导入成功不等于系统代理已经启用。有些客户端把“更新订阅”“选择节点”“启动本地服务”和“设置为系统代理”分成独立操作。排查时应确认这些状态，而不是反复重新导入订阅。

出口 IP 变化后仍打不开目标服务

这时问题已经从“是否走代理”缩小为“这条路径是否适合目标请求”。可能原因包括 DNS 返回异常、目标服务对出口网络有限制、分流导致相关子域名走了不同路径，或者浏览器保留了旧连接。先不要继续切换协议，应检查 DNS、规则命中和应用日志。

查 DNS：判断域名解析走了哪条路径

访问网站前，系统通常需要把域名解析为 IP 地址。网页连接经过节点，不代表 DNS 查询一定沿着相同路径发送。如果 DNS 仍交给本地网络处理，就可能出现解析结果与节点地区不匹配、部分域名返回异常，或域名请求暴露给本地解析服务的情况。

DNS 排查不能只看系统界面里填写了哪个服务器。很多系统会使用本地存根解析器，客户端也可能接管查询、返回虚拟地址，或者把查询封装进隧道。界面里出现本地地址，不必然代表泄漏；关键是客户端日志中的处理方式，以及最终由哪一侧完成递归解析。

浏览器与系统 DNS 可能不同

现代浏览器可以启用自己的加密 DNS。启用后，浏览器解析路径可能与操作系统不同。于是命令行查询正常，浏览器仍然异常；或者浏览器正常，其他应用仍使用本地网络提供的解析器。排查时需要分别测试，不要用单一结果代替整个系统。

可以在终端查询一个未被缓存的目标域名，并同时观察客户端日志。Windows 常用 nslookup，macOS 与 Linux 可使用 dig 或 nslookup。命令输出负责展示解析结果，客户端日志负责说明请求是否被接管、转发或按规则直连。

nslookup example.com

dig example.com

nslookup example.com 指定的解析服务

最后一行中的“指定的解析服务”应替换为实际准备测试的服务器地址。不要把公共解析服务本身当作代理。DNS 只负责解析域名，不会自动改变网页连接的出口。

避免 DNS 缓存造成误判

系统、浏览器和客户端都可能缓存解析结果。切换节点后立即查询同一域名，看到的可能仍是旧答案。更稳妥的做法是关闭相关标签页，清理应用内 DNS 缓存，重新连接后再查询。若不熟悉系统清缓存命令，可以重启目标应用；不要随意删除未知网络配置。

• ✅ 出口 IP 已变化，再开始检查 DNS，避免两个问题同时干扰。
• ✅ 分别测试浏览器与系统命令行，确认是否只有单个应用异常。
• ✅ 查看客户端日志，确认 DNS 请求命中了代理解析还是直连解析。
• ✅ 检查浏览器是否启用了独立的加密 DNS 设置。
• ❌ 不要仅凭系统界面显示本地存根地址，就直接判定发生 DNS 泄漏。
• ❌ 不要把域名能解析等同于网页流量已经进入隧道。

检查 IPv6 与分应用路由

部分网络同时提供 IPv4 与 IPv6。客户端可能只接管其中一种，也可能根据系统能力选择不同路径。如果 IPv4 经由节点，而 IPv6 保持本地直连，支持 IPv6 的网站可能优先使用未接管路径。这会造成同一浏览器里不同网站结果不一致。

检查时应在 IP 检测页观察当前暴露的是 IPv4、IPv6，还是二者同时存在。如果只接管部分协议栈，应在客户端中启用相应支持，或按客户端文档调整 IPv6 策略。不要仅在浏览器里隐藏结果，因为底层路由没有改变。

分应用代理的常见边界

分应用功能通常通过包含或排除应用来决定路由。配置时容易混淆“只有选中的应用经过代理”和“选中的应用不经过代理”这两种语义。更新客户端后，应用路径或进程名称也可能变化，旧规则因此不再匹配。

浏览器还可能启动多个辅助进程。把主程序加入规则，不一定覆盖由系统组件处理的请求。相反，TUN 模式通常按网络流量和规则匹配，不完全依赖应用是否读取代理设置，更适合检查不支持系统代理的软件。但 TUN 并不代表无条件全局接管，局域网、保留地址、直连域名和手动排除项仍可能绕过。

从客户端日志定位连接层问题

如果出口和 DNS 都不符合预期，日志比反复切换节点更有效。日志通常可以区分订阅解析失败、节点握手失败、本地端口冲突、证书或时间异常、路由写入失败，以及请求被哪条规则处理。阅读时应从连接动作发生的时间点开始，避免被较早的历史错误干扰。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 的握手方式不同，错误文字也不完全一致，但排查顺序相近：先确认配置完整，再确认节点可达，然后确认本地监听成功，最后查看目标请求是否进入对应出站。若握手成功但日志中没有目标请求，问题多半在本地接管或分流规则，而不是远端协议。

订阅链接导入失败时，应先检查链接是否完整、客户端是否支持订阅所包含的配置格式，以及订阅更新是否被当前网络阻断。成功导入后还要选择有效节点并启动连接。只看到节点列表并不表示节点已经被使用。

不同平台的检查重点

Windows 上需要关注系统代理残留、虚拟网卡状态和应用是否使用 WinHTTP 或自身代理设置。macOS 上应核对当前网络服务的代理配置，并确认系统扩展或网络扩展获得了所需权限。Linux 的桌面代理设置与终端环境变量可能相互独立，浏览器生效不代表终端命令生效。

移动平台通常由系统 VPN 接口统一承载流量，但省电策略、按应用 VPN、始终开启连接和局域网访问设置仍会改变结果。遇到后台恢复后失效，应重新打开客户端查看隧道状态和最近日志，而不是只看状态栏图标。

几种“看起来连上了”的典型情况

浏览器正常，下载工具仍走本地出口

这通常是系统代理覆盖范围问题。浏览器读取系统代理，而下载工具使用直连网络栈。应检查下载工具是否支持代理，或使用能覆盖该类流量的 TUN 模式，再分别验证两个应用的出口。

切换节点后网页地区没有变化

先排除页面缓存和旧连接复用，再检查规则模式是否让检测域名直连。如果日志里没有检测请求，说明浏览器可能没有进入当前客户端。若日志显示请求已走新节点，但地理信息未更新，应以出口 IP 和网络归属为主，不要只看地区文字。

开启连接后完全无法访问网络

如果启用了断线保护或类似的阻断策略，节点握手失败时，本地直连也可能被主动阻止。这种表现并非“流量偷偷直连”，而是保护规则在连接不可用时停止放行。应查看握手错误、本地时间、网络权限和节点可达性。

只有部分域名失败

优先检查域名分流、DNS 返回结果和相关子域名。一个服务可能使用多个域名，主站与接口请求可能命中不同规则。只把主域名加入代理列表，不能保证全部资源使用相同路径。日志中的规则命中记录通常能直接指出分歧。

直连、普通中转与 IEPL 专线结果不同

直连表示设备直接连接远端节点，路径受公网路由影响。普通中转先连接中转入口，再转发到出口。IEPL 专线通常把入口与出口之间的传输放在专用链路中，但用户到入口、出口到目标服务仍是完整路径的一部分。线路类型会影响路由稳定性，却不会替代本地代理和 DNS 检查。即使使用专线，本地应用没有进入隧道，出口仍不会改变。

一套可重复执行的验证顺序

完整排查不需要同时修改大量设置。以下顺序从最容易观察的现象开始，逐步进入系统和客户端内部。每完成一步都记录结果；一旦发现异常，就停在该层处理，不必提前调整后面的协议参数。

1. 断开连接，记录目标应用的出口 IP、IP 类型与网络归属，建立基线。
2. 连接目标节点，在同一应用中重新检测出口，确认请求是否改变路径。
3. 使用浏览器和系统工具分别检查 DNS，结合客户端日志判断解析方式。
4. 检查 IPv4 与 IPv6 是否都按预期接管，避免双栈环境出现路径分离。
5. 在实际发生问题的应用中重复测试，确认系统代理、TUN 或应用内代理的覆盖范围。
6. 查看规则命中与出站日志，区分直连、代理、拒绝和解析错误。
7. 最后再切换节点或协议，并保持其他条件不变，以便比较变化来源。

如果问题仍然存在，可以在客户端内整理连接时间、平台、连接模式、协议类型、错误日志和已完成的检查项，再通过站内 FAQ 或故障支持渠道继续定位。明确说明“哪个应用、哪个域名、出口是否变化、DNS 如何处理”，比只描述“连不上”更容易找到故障层级。