VPN 连上了吗？出口 IP、DNS、分应用三步验证指南

「客户端显示已连接，网页却打不开」和「客户端显示已连接，流量其实没走线路」是两个不同的问题。判断 VPN 连上了吗，只看客户端图标没有意义：图标只说明本地与节点完成了握手，不保证每个请求都进入隧道。下面这套三步验证——出口 IP、DNS 归属、分应用测试——每一步都能独立给出结论，也能互相印证。

验证不需要额外工具，浏览器加客户端本身就能完成。顺序建议固定下来：先确认出口地址换了，再确认域名解析跟着换了，最后确认目标应用确实在用这条线路。

• 3 步 出口 IP / DNS 归属 / 分应用，逐项给出结论
• 120+ 国家与地区的线路覆盖
• 240+ IEPL 专线与中转线路可选
• 7 天 无理由退款

为什么「已连接」不等于流量真的走线路

客户端上的「已连接」表示本地程序与节点之间握手成功：会话建立、认证通过、密钥协商完成。它不保证系统里的每一个请求都会进入这条隧道。是否真的走线路，取决于客户端的工作模式、分流规则，以及应用自己的网络设置。

工作模式决定覆盖面

虚拟网卡（TUN）模式会创建一张虚拟网卡并接管系统路由表，TCP 与 UDP 默认全部进入隧道，只有命中分流规则放行的流量才直连。系统代理模式只修改系统的代理设置：遵循该设置的应用会走线路，自带网络栈、不读系统代理的软件则直接连出去。同一个客户端、同一条线路，两种模式下的覆盖面完全不同。

分流规则决定例外

分流不是故障，而是设计目标：国内域名与国内 IP 段默认直连，访问国内服务时不必绕远路。风险在于误判——目标域名被规则归到直连那一侧，表现就是「连上了但没走」。规则集长期不更新，误判会变多。

应用与缓存带来的干扰

浏览器可以有自己的代理配置，扩展也能接管请求；开启安全 DNS 后，域名解析可能完全绕开系统设置。切换线路之后，已经建立的长连接（HTTP/2、HTTP/3 会话）可能仍走旧路径。切换后先重启浏览器，再在系统层面清空 DNS 缓存：

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

出口 IP 核对：连接前后各查一次

出口 IP 是外界看到的你的地址，也是三步里最容易复现的一项：连接前后各查一次，对比结果。检测页面尽量选能同时显示 IP 归属地与运营商的那类，信息越全，判断越省事。

1. 断开客户端，打开检测页面，记录三项信息：出口 IP、国家 / 地区、运营商或 ASN。
2. 连接客户端，选择一条线路。以日本或新加坡线路为例，检测页应显示对应地区的地址。
3. 强制刷新检测页，不要用缓存页面，对比 IP 是否变化、归属地是否与所选线路一致。
4. 单独看 IPv6 一栏：如果显示你的 IPv6 地址仍属于本地运营商，说明隧道只接管了 IPv4，部分同时提供 AAAA 记录的站点会直接走 IPv6 出去。
5. 只在浏览器里做验证的场景，再看一次 WebRTC：它可能暴露本机地址或真实公网地址，与出口 IP 是两条独立路径。

检查项	正常表现	需要处理的表现
IPv4 出口	显示线路所在国家 / 地区的地址，与连接前不同	与连接前完全相同，或归属地仍是本地
IPv6 出口	没有 IPv6 地址，或显示线路侧地址	显示本地运营商的 IPv6 地址
WebRTC	只出现隧道内或线路侧地址	出现本机内网地址或真实公网地址
运营商 / ASN	显示为线路侧的机房或运营商	仍是本地宽带运营商

如果检测页列出了 IPv6 地址，而客户端并没有接管 IPv6，最省事的做法是在客户端里关闭 IPv6 转发，让域名回到 IPv4 路径上。代价是纯 IPv6 的站点无法访问，日常使用几乎感觉不到。

DNS 归属核对：解析路径在哪里

出口 IP 只回答「数据从哪里出去」，不回答「你查了哪些域名」。域名解析的路径决定了谁能看到你访问的站点清单，所以第二步单独查 DNS。

两条解析路径

隧道内解析：客户端把 DNS 查询一起送进隧道，由节点侧解析器完成；Fake-IP 模式则是先在本地把域名映射成虚拟地址（常见做法是 198.18.0.0/15 这类保留段），真正的解析发生在节点侧，连接按域名发起。本地解析：应用直接向路由器或运营商解析器查询，拿到地址后再决定走哪条路。这种情况下，即使网页流量进了隧道，域名清单仍留在本地网络里——这就是通常说的 DNS 泄漏。

怎么测

1. 打开一个 DNS 泄漏检测页面，它会列出为你的查询提供解析的解析器地址与归属地。
2. 连上线路后刷新几次，让检测页发起多个不同域名的查询。
3. 看解析器列表：正常情况下只应出现节点侧解析器；如果混进本地运营商解析器与你的城市，说明这些查询走了本地。

浏览器安全 DNS 是常见干扰项

Chrome、Edge、Firefox 都提供安全 DNS（DoH）开关，开启后浏览器会直接向 DoH 服务商发起加密查询。TUN 模式下这些查询本身也进入隧道，只是解析器换成了 DoH 服务商；系统代理模式下，请求可能完全绕开隧道直连出去。排查时先把这个开关关掉，或者确认它走的是隧道。

处理办法

• 在客户端里开启 DNS 接管（DNS 劫持），把发往 53 端口的查询重定向到隧道内的解析器。
• 关闭浏览器的安全 DNS，或把它指向隧道内的解析器。
• 不要同时运行两个代理工具，它们会互相抢路由表与 DNS 设置。

分应用与分流规则测试

前两步验证的是系统层面，第三步验证的是应用层面。分应用代理让你指定哪些应用走线路，分流规则决定哪些域名走线路，两者都会让同一个 IP 检测页给出不同答案。

分应用代理的验证方法

1. 在同一台设备上，用两个不同的应用访问同一个显示出口 IP 的页面。
2. 一个是被代理的应用（通常是浏览器），一个是未被代理的应用。
3. 前者的出口 IP 应该是线路侧地址，后者应该仍是本地地址。两者都符合预期，说明分应用设置生效。
4. 如果两者显示同一个地址，回去检查客户端的应用列表：桌面系统按进程名匹配，移动系统按应用包名匹配，重装或改名后需要重新选择。

分流规则的匹配顺序

规则自上而下逐条匹配，命中即停，所以顺序本身就是配置的一部分。常见类型如下：

规则类型	匹配对象	典型用途
DOMIN	完整域名	精确放行或代理单个域名
DOMAIN-SUFFIX	域名后缀	覆盖一个站点及其全部子域
DOMAIN-KEYWORD	域名中的关键词	批量匹配同类站点
IP-CIDR	IP 地址段	按地址范围分流
GEOIP	IP 归属国家 / 地区	国内直连、国外走线路
RULE-SET	外部规则集合	引用持续维护的规则列表
MATCH	剩余全部流量	兜底规则，放在最后一条

验证分流是否按预期工作，最直接的办法是看连接日志：多数客户端提供实时连接列表，每条记录会写明命中了哪条规则、走的是代理还是直连。目标域名显示 DIRECT，说明是规则放行，不是线路故障。规则集有更新时间，长期不更新会把新域名判错；在客户端里手动更新订阅与规则集，是最省事的修复方式。

「看起来连上了其实没走」的常见情况

下面这些现象在排查里出现频率最高，按现象、原因、处理三列对照即可。

现象	可能原因	处理
客户端显示已连接，浏览器仍是本地 IP	浏览器使用自有代理设置，或扩展接管了请求	关闭浏览器代理类扩展，统一由客户端接管
部分网站打不开，另一些正常	目标域名命中直连或 REJECT 规则，规则集过期	在连接日志里看规则命中，更新订阅与规则集
IPv4 已切换，IPv6 仍是本地	隧道未接管 IPv6，本地网络又提供了 IPv6	客户端内关闭 IPv6 转发，或让隧道接管 IPv6
检测页出现本地 DNS 解析器	浏览器安全 DNS 直连，或系统代理模式下本地解析	开启 DNS 接管，关闭浏览器安全 DNS
连接成功但请求全部超时	节点出口异常、MTU 与分片问题、UDP 被阻断	换线路、切换协议（TCP / QUIC）、调整 MTU
切换线路后仍显示旧 IP	长连接复用与 DNS 缓存	清空 DNS 缓存，重启浏览器，断开重连

还有一件事要分清：验证只能说明流量走了线路，不能说明线路质量。线路类型决定的是稳定性——直连线路由客户端直接连海外节点，全程走公网，晚高峰容易受拥塞影响；中转线路先连近端入口再转发到出口，路径可控一些，但后半段仍依赖公网；IEPL 专线走专线通道，不经过公网，抖动与丢包更小。三步都通过、速度仍不理想时，问题在选线，不在验证。

排查清单与判断标准

把上面三步压缩成一份清单，逐项对照即可：

• ✅ 出口 IP 与所选线路的归属地一致，且与连接前不同
• ✅ 检测页没有出现本地运营商的 IPv6 地址
• ✅ 被代理域名的解析器位于节点侧，没有混入本地解析器
• ✅ 连接日志显示目标域名命中代理规则，而不是 DIRECT
• ✅ 被排除代理的应用确实显示本地地址，说明分应用设置生效
• ❌ 检测页显示的仍是本地宽带地址，清空缓存、重启浏览器后不变
• ❌ 解析器列表里同时出现本地运营商与本地城市
• ❌ 连接日志里目标域名全部命中 DIRECT 或 REJECT

常见疑问