客户端显示「已连接」,只说明本地隧道进程起来了,不说明流量真的从线路出口出去。确认 VPN 是否生效,顺序是固定的:先看出口 IP 与归属地,再看 DNS 解析落在哪里,最后按应用逐个验证。三步都过,才算这条线路在当前设备上真的可用。

顺序不能颠倒,原因是排查要能定位。先测应用,一旦打不开,你无法区分是线路没生效、解析走错了,还是应用本身对出口地区有要求。把出口和解析这两层先钉死,剩下的问题一定在应用侧。

三步自查的顺序与判定标准

下表是完整的三步。每一步都有可观测的判定标准,遇到第一个不通过的行就停下,先解决它,再往下走。

顺序 查什么 通过标准 不通过时的典型表现
1 出口 IP 与归属地 显示的国家与所选线路一致 仍显示本地归属地,或与所选线路的国家不符
2 DNS 解析路径 解析请求由线路侧完成,不再落到本地运营商 解析服务器仍是本地运营商地址
3 应用层连通 目标应用能连续使用,不报地区限制 页面能打开但功能受限,或反复要求验证

第 2 步最容易被跳过。查完 IP 归属地就直接开始用,访问是通的,但页面加载慢、部分资源加载失败、登录时被要求额外验证——这类现象多半出在解析路径上,而不是线路本身。

自查期间只动一个变量:不要同时切线路、改分流规则、换客户端。一次改一处,通过或失败才能对应到具体设置。

第一步:查出口 IP 与归属地

出口 IP 是目标站点看到的那个地址,也是判断流量有没有走线路最直接的证据。两种查法,用途不同。

图形界面查法:打开浏览器的无痕窗口,访问任意显示来访 IP 的页面,页面上会同时给出 IP 与归属地。用无痕窗口是为了避开缓存与扩展——浏览器扩展里的代理设置会覆盖客户端写入的系统代理,常规窗口查出来的结果可能不是你以为的那条线路。

命令行查法:不受浏览器代理设置影响,适合排查「浏览器走了、别的程序没走」这类问题。

# 只取 IP,适合脚本核对
curl -s https://api.ipify.org

# 需要同时看归属地与运营商时,取 JSON
curl -s https://ipinfo.io/json

判定标准只有一条:归属地的国家与所选线路一致。城市一级不必强求,IP 归属地数据库本身有偏差,机房地址被标注到相邻城市甚至相邻国家都很常见。香港、东京、新加坡这类节点密集的地区,城市字段的参考价值有限,以国家字段为准。

IPv6 是常见的漏口

多数线路默认只接管 IPv4。如果本机同时持有一个可用的 IPv6 地址,而目标站点又支持 IPv6,浏览器会优先走 IPv6 直连。结果是 IPv4 出口在境外,实际请求却从本地发出。自查时看一眼 IPv6 那一栏:显示的是本地地址段,说明 IPv6 没有走线路,需要在客户端里关闭 IPv6,或改用能接管双栈的模式。

注意:改完设置要重连一次再查。部分系统在网卡状态变化后会重建默认路由,旧隧道不一定还挂在默认路由上。

第二步:查 DNS 是否泄漏

DNS 泄漏指的是:流量走了线路,域名解析请求却仍然发给本地运营商的 DNS 服务器。隧道接管的是 IP 层流量,而解析请求可能在隧道建立之前就发出,也可能被系统按网卡优先级送去了本地解析器。

后果有两层。一层是解析结果与出口地区不匹配:CDN 按解析来源调度,返回的节点离本地近、离出口远,表现是能打开但慢,或者部分资源加载失败。另一层是判定异常:目标服务同时看到境外出口 IP 和本地解析来源,风控上更容易要求二次验证。

平台 查看方式 看什么
Windows 命令提示符执行 ipconfig /all 「DNS 服务器」一行是否为本地运营商地址
macOS 终端执行 scutil --dns nameserver[0] 指向的地址
Linux 终端执行 resolvectl status 当前链路的 DNS 与加密解析状态
浏览器 设置里搜索「安全 DNS」 是否开启;开启后会绕过系统 DNS

再确认解析请求实际发往哪里:用 nslookup 或 dig 查一个固定域名,输出里的 Server 就是当前使用的解析器。它仍然指向本地运营商,就说明解析没有走线路。

nslookup example.com
dig +short example.com

浏览器的安全 DNS 会绕过隧道

Chrome、Edge、Firefox 都内置了「安全 DNS」,也就是 DNS over HTTPS。开启后浏览器自己做加密解析,不读系统 DNS 设置。这时即使客户端接管了系统解析,浏览器的解析请求仍可能直接发到浏览器指定的解析服务,与出口地区不一致。自查阶段先关掉它,确认线路本身没问题,再决定要不要开。

通过标准:系统解析器显示为线路侧地址(或与出口地区一致),且 nslookup 的输出不再是本地运营商地址。两条都满足,再进第 3 步。

第三步:按应用逐个验证

出口和解析都正常,不代表每个应用都能用。不同程序读取代理设置的方式不一样,这一步按你实际使用的程序逐个过。

  1. 浏览器:用无痕窗口打开目标站点,确认页面完整加载、登录状态正常。装了扩展的,先在无痕模式下排除扩展影响。
  2. 桌面客户端:一部分程序只读系统代理,一部分只认 SOCKS,还有一部分完全不读系统代理,必须靠 TUN 模式接管。判断方法很简单:退出客户端之后程序还能照常联网,说明它本来就没走代理。
  3. 命令行工具:多数命令行程序只认环境变量。curl 需要 http_proxy 与 https_proxy,或者干脆用 TUN 模式让它无感接管。
  4. 移动端:iOS 与 Android 都会在后台回收连接。从后台切回来先看一眼客户端状态,再打开应用;长时间挂后台之后直接使用,经常是断的。
  5. 地区判定严格的服务:这类服务同时看出口 IP、解析来源与账号历史地区。三处对不上,网络通了也会被拦。

通过的标志是能连续使用一段时间,不出现资源加载失败,不反复要求验证。只打开首页看一眼,不算通过。

「看着连上了其实没走」的几种常见情况

下面这些情况,客户端界面都显示已连接,流量却没有按预期走线路。按出现频率排列。

  • ❌ 系统代理没有写入成功。客户端显示连接,但系统代理开关是关的,浏览器仍走本地网络。查系统代理设置里是否指向本地回环地址加端口。
  • ❌ 只接管了 TCP,浏览器走 QUIC。HTTP/3 走 UDP 443,线路只转发 TCP 时,浏览器会绕过代理直连。可以在浏览器里关闭 QUIC,或改用能接管 UDP 的模式。
  • ❌ IPv6 直连。见第一步,IPv6 未接管时系统会优先走本地地址。
  • ❌ 分流规则把目标域名判成了直连。规则集过期、域名归属库不全,都会让目标站点走直连。
  • ❌ 多网卡优先级错误。装了虚拟机或插了第二个网卡之后,默认路由可能从另一块网卡出去。
  • ❌ 隧道已断但界面没刷新。心跳失败后客户端有时仍显示已连接,重连一次再看。
  • ✅ 反过来也成立:三步都通过而应用仍不可用,问题在应用自身的地区策略,不在线路。

分流模式:为什么有的站点走了、有的没走

客户端一般提供三种模式:全局、规则(分流)、直连。全局模式下所有流量都走线路,自查最容易通过;规则模式按域名或 IP 归属决定走向,灵活,但也最容易出现「部分走、部分不走」。

  • 全局:所有流量走线路。适合自查与临时使用,长期用会浪费流量,本地服务也可能变慢。
  • 规则:按规则集判断,命中直连的走本地,其余走线路。规则集需要定期更新,过期后会误判。
  • 直连:等同于关闭。用来确认问题是不是线路本身造成的。

排查时把模式临时切到全局,再查一次出口 IP。全局下通过、规则下不通过,问题就在规则集,不在线路。

自查通过之后

三步都过,说明这条线路在当前设备、当前网络下可用。接下来要看的是长期表现:晚高峰是否稳定、长时间连接会不会掉线、从 Wi-Fi 切到手机热点之后能不能自动恢复。这些没有一次性判定方法,只能实际用一段时间观察。

90+ 国家覆盖,换线路对比出口归属地时有足够样本
190+ 线路,IEPL 专线、中转与直连三种类型
14 天 无理由退款,首次付费后 14 天内可申请

如果自查反复不通过,先换一条线路再测。出口被目标服务限制、路由绕远,这类问题不是改客户端设置能解决的。VPNEH 目前覆盖 90+ 国家、190+ 线路,月订阅 ¥9.9 起含 60GB;首次付费后 14 天内可申请无理由全额退款,自查阶段可以换着线路试。

结论:确认 VPN 是否生效,按出口 IP、DNS、应用三步走,每一步都有可观测的判定标准。出口看国家是否一致,DNS 看解析器是否还在本地,应用看能否连续使用。任何一步不通过,先解决那一步,不要跳步往下测。