为什么「已连接」不等于流量走了线路
打开客户端,状态变成「已连接」,只说明本机与线路服务器之间的隧道建立成功。流量有没有真的进入这条隧道,还要看客户端的工作模式、分流规则和应用自身的网络行为——这三件事与「已连接」是分开的。
工作模式通常分两类。系统代理模式只改写系统的代理设置,只有读取这份设置的应用才会把请求交给隧道:浏览器一般会读,部分桌面应用不读。TUN / 虚拟网卡模式会在系统里建一张虚拟网卡并接管路由表,绝大多数应用的流量都会被送进隧道,包括不读系统代理的应用。同一个订阅,在两种模式下验证结果可能完全不同。
第二层是分流规则。规则列表把域名或 IP 分成直连、走代理、拒绝几组;如果目标域名被判定为直连,即使隧道完全正常,这次访问走的也是本地出口。规则集过旧,或不同客户端内置的默认规则不同,就会出现「同一个网站,有的设备走了线路、有的没走」。
第三层在应用自己身上。部分应用内置独立网络栈,不读系统代理;部分应用优先使用 IPv6,而隧道只接管了 IPv4;基于 UDP 的流量(QUIC、语音通话、部分游戏)在只支持 TCP 转发时会被回退或直连。这些情况都会造成「客户端显示已连接、应用却仍是本地出口」。
判断是否生效,不看客户端状态,只看三个外部证据:出口 IP 的归属地、DNS 解析服务器的归属地、目标应用的实际可用性。
三步自查:出口 IP → DNS → 应用实测
三步按「从外到内」的顺序排列:先确认流量有没有进隧道,再确认隧道内的解析是否干净,最后确认具体应用在真实场景下能不能用。
- 断开与连接各查一次出口 IP,对比国家 / 地区与运营商归属。
- 查 DNS 解析由哪台服务器完成,确认解析请求没有落到本地运营商。
- 对真正要用的应用逐个实测,而不是只打开一个网页看看。
三步是递进关系,任何一步不通过,都说明「已连接」还没有转化为「已生效」。定位到具体是哪一步出问题,再决定是换线路、改模式,还是更新规则。
第一步:查出口 IP,看地区是否与所选线路一致
查出口 IP 的工具很多,重点是「对比」:先断开连接查一次并记录结果,再连接线路、用无痕窗口查一次,两次放在一起看。命令行方式适合需要反复验证的场景。
# 查当前出口 IP(Windows / macOS / Linux 通用)
curl -s https://ifconfig.me
# 需要地区与运营商信息,可以换用返回 JSON 的查询接口
curl -s https://ipinfo.io/json页面方式更直观:打开任一 IP 查询页,同时看 IPv4 与 IPv6 两项。只有一项变了,说明另一项还在走本地出口。
| 连接后看到的出口 | 说明 | 处理 |
|---|---|---|
| 与所选线路的国家 / 地区一致 | 流量已进入隧道 | 继续第二步 |
| 仍是本地运营商与本地城市 | 流量没有进隧道 | 检查工作模式与分流规则 |
| 是所选国家,城市与线路标注不同 | 出口池调度,属正常现象 | 无需处理 |
| IPv4 变了,IPv6 仍是本地地址 | IPv6 未接管,存在泄漏 | 开启 IPv6 接管,或临时关闭系统 IPv6 |
查 IP 前先关掉浏览器里的代理类插件,并用无痕窗口重新打开查询页。插件代理会覆盖系统代理,页面缓存也会让你读到上一次的结果。
第二步:查 DNS 解析,确认没有泄漏
DNS 泄漏指的是:网页流量走了隧道,但域名解析请求仍然发给了本地运营商的 DNS。它有两个后果——访问意图暴露给本地解析方;解析结果指向离本地最近的节点,导致片库不符或速度异常。DNS 泄漏不会让客户端掉线,所以只看连接状态永远发现不了。
检查方法有两种。浏览器里打开 DNS 泄漏检测页,页面会列出本次解析用到的服务器及其归属地;命令行里看解析服务器的地址,同样可以判断。
# macOS / Linux:查看解析服务器
dig example.com | grep SERVER
# Windows:查看解析服务器与解析结果
nslookup example.com判读标准很直接:解析服务器的归属地应与线路所在地区一致,或显示为隧道内部的 DNS 地址。如果显示的仍是本地运营商的解析服务器,说明解析请求没有走隧道。
改过 DNS 设置或切换线路之后,先刷新系统 DNS 缓存再复查,否则看到的还是旧结果。
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux(systemd-resolved)
sudo resolvectl flush-caches第三步:分应用验证,别只看浏览器
浏览器是最容易走代理的应用,因为它会读取系统代理设置。真正决定体验的往往是别的应用。验证时按实际使用场景来,而不是随便打开一个网页就算通过。
| 应用类型 | 验证动作 | 生效表现 |
|---|---|---|
| 浏览器访问国际网站 | 打开目标站点并登录 | 页面正常,地区提示与线路一致 |
| 流媒体播放页 | 打开播放页并播放一分钟 | 片库与线路地区一致,播放不中断 |
| AI 类工具 | 发起一次长对话 | 会话保持,不出现地区限制提示 |
| 应用商店 / 系统更新 | 查看商店区域与下载来源 | 区域与线路地区一致 |
命令行与开发工具单独验证
git、包管理器这类命令行工具默认不读系统代理,需要设置 HTTP_PROXY / HTTPS_PROXY 环境变量,或者改用 TUN 模式由虚拟网卡接管。验证方式与浏览器一致:在命令行里查一次出口 IP,与浏览器里看到的结果对比,两边不一致就说明有一边没走隧道。
「看起来连上了其实没走」的几种常见情况
下面这些现象在排查中出现频率最高,按「现象 → 原因 → 处理」对号入座即可。
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 浏览器显示本地地区,其他应用正常 | 浏览器装了代理类插件,覆盖了系统代理 | 关闭插件后重测 |
| 浏览器正常,桌面应用提示地区不符 | 该应用不读系统代理 | 切换 TUN 模式,或在应用内单独填写代理 |
| 刚连上可用,过一会儿失效 | 分流规则把目标域名判为直连,或规则集过期 | 更新订阅与规则集后重测 |
| 多数站点正常,个别站点仍显示本地地址 | 该站走 IPv6,而隧道只接管了 IPv4 | 开启 IPv6 接管,或临时关闭系统 IPv6 |
| 网页能开,语音 / 游戏 / QUIC 流量异常 | 当前模式不支持 UDP 转发 | 切换支持 UDP 的协议或线路类型 |
| 换一个客户端后结果不同 | 两端默认模式与规则集不一致 | 统一模式与规则集后重新对比 |
换个客户端,结果为什么不一样
订阅链接只承载线路信息——服务器地址、端口、协议参数,不承载「怎么用」的策略。同一个订阅导入不同客户端,默认模式可能是全局、规则或直连;规则集也可能一份来自客户端内置、一份来自订阅方,匹配顺序不同,结果就不同。
协议差异同样会影响验证结果。Shadowsocks、VMess、Trojan、VLESS 以 TCP 为主,部分实现支持 UDP 转发;Hysteria2、TUIC 基于 QUIC,天然走 UDP,在 UDP 受限的网络里可能连不上或表现不稳。如果出口 IP 与 DNS 两步都通过、只有某类应用异常,先怀疑协议与 UDP 支持,而不是线路本身。不同线路类型(直连、中转、IEPL 专线)的差异,可以参考节点页的说明。
平台之间也有区别:桌面端可以建虚拟网卡接管全部流量;移动端受系统限制,通常按配置文件或按应用接管;路由器端整网接管,但要单独确认 DNS 是否也被转发。
判断是否生效,以出口 IP、DNS 解析、目标应用三项同时通过为准。只凭客户端状态或某一次网页能否打开下结论,都会误判。
一张可复用的自查清单
把上面的步骤压缩成一份清单,换设备、换线路、换客户端之后照着走一遍即可。更完整的客户端导入操作见使用教程。
- ✅ 断开连接,记录本地出口 IP 与 DNS 解析服务器,作为对照
- ✅ 连接线路后,用无痕窗口复查出口 IP,确认与所选线路地区一致
- ✅ 同时查看 IPv6 地址,确认没有绕过隧道
- ✅ 刷新 DNS 缓存后复查解析服务器归属地
- ✅ 对真正要用的应用逐个验证,不只看浏览器
- ✅ 更换线路、客户端或规则集后,把这套步骤重新走一遍
这套步骤一次只需要几分钟,却能把「感觉连上了」和「确认生效了」分开。先定位是哪一步不通过,再决定换线路、改模式还是更新规则,比反复重连有效得多。
常见问题
客户端显示已连接,但网页打不开,是不是没生效?
已连接只代表隧道建立成功。网页打不开可能是分流规则把目标域名判成了直连、解析请求没有走隧道,或者线路当前拥塞。按出口 IP → DNS → 应用三步排查,通常能定位到具体环节,再决定是改模式、更新规则还是换线路。
只有一个应用不走线路,需要换线路吗?
通常不需要。先看这个应用是否读取系统代理、是否内置独立网络栈,再考虑切换 TUN 模式或在应用内单独填写代理。线路本身的问题会影响所有应用,而不是只影响某一个。
换设备之后还要重新验证吗?
要。验证结果与设备上的工作模式、规则集、DNS 设置绑定,和账号本身无关。同一订阅在新设备上导入后,建议把三步自查重新走一遍,尤其是移动端与桌面端之间切换时。
为什么移动端和桌面端的结果不一样?
移动端对后台流量与虚拟网卡的限制更多,通常按配置文件或按应用接管;桌面端可以整机接管。对比之前,先确认两端的模式与规则集是否一致,否则结论没有可比性。