客户端图标变绿、状态写着「已连接」,打开网页却还是原来的速度、原来的内容——这是「VPN 连上了但没生效」最典型的样子。问题通常不在线路本身,而在流量有没有真的被送进线路:系统代理模式只对读取代理设置的应用生效,分流规则可能把目标域名判成了直连,DNS 解析也可能根本没走线路。判断方法不复杂,顺序是固定的:先查出口 IP,再查 DNS,最后按应用逐个验证。三步走完,绝大多数「看起来连上了其实没走」的情况都能定位到具体原因。
为什么「已连接」不等于真的生效
客户端和线路之间建立连接,只说明控制通道通了:节点信息拿到了,认证过了,心跳也正常。流量有没有真的进入这条通道是另一件事,取决于三个变量——客户端的工作模式、分流规则,以及你正在用的那个应用是否读取代理设置。
常见的工作模式有三种,覆盖范围差别很大:
- 系统代理模式:客户端修改的是操作系统的代理设置(HTTP / SOCKS)。只有主动读取这项设置的应用才会走线路。大多数浏览器会读,终端、部分桌面软件和游戏启动器不会。
- TUN / 虚拟网卡模式:客户端在系统里创建一块虚拟网卡并接管路由表,多数应用的流量被整体接管,不再依赖应用自己去读代理设置。
- 全局 / 规则模式:这是「哪些流量走线路」的策略。全局把所有请求都送进线路;规则模式按域名、IP 段、地区列表逐条判断,命中直连规则的域名不会经过线路。
所以「已连接」只是必要条件。要判断是否真的生效,得看数据:出口 IP 变没变、DNS 解析走了谁、每个具体应用拿到的来源地址是什么。
同一个「没生效」现象,在系统代理模式和 TUN 模式下的原因完全不同。打开客户端设置,确认当前处于哪种模式,后面的排查才有方向。
查出口IP:对比连接前后的地址
出口 IP 是判断生效与否最直接的证据。流量走了线路,外部网站看到的来源地址就是线路落地的地址;没走线路,看到的还是本地宽带或蜂窝网络的地址。做法只有四步:
- 连接之前,先打开一个显示来源地址的页面,记下地址和归属地。
- 连接线路,等状态稳定 5~10 秒再操作。
- 刷新同一个页面,对比前后两次的地址。
- 换一个查询源再查一次,排除页面缓存造成的误判。
| 对比结果 | 说明 | 下一步 |
|---|---|---|
| 地址变了,归属地与所选节点一致 | 数据通道已经生效 | 继续查 DNS 与应用 |
| 地址完全没变 | 当前应用的流量没有进入线路 | 检查工作模式与分流规则 |
| 地址变了,归属地却不是所选地区 | 入口与落地可能不在同一地区,或页面显示的是 CDN 边缘地址 | 换查询源交叉验证,再看客户端的节点详情 |
出口 IP 与线路类型的关系
直连、中转与 IEPL 专线改变的是「从本地到落地」这段路径:直连由客户端直接连到境外节点,走公共国际出口;中转先连到国内中转服务器,再由它转发到境外落地;IEPL 专线走国际以太网专线链路,不经过公共互联网出口。三者影响的是延迟与丢包的稳定性,而出口 IP 由落地节点决定——换节点会换出口地址,把直连换成中转并不会改变归属地。
查 DNS:解析请求去了哪里
域名要先被解析成 IP 地址,连接才能建立。如果 DNS 查询没有走线路,而是交给了本地运营商的解析器,通常有两个后果:访问目标在解析阶段就暴露给了本地网络;解析结果可能指向就近但不可达、甚至被污染的地址,表现就是「连上了却打不开」或者「时好时坏」。
检查方式有两种:
- 打开一个 DNS 泄漏检测页面,看它列出的解析服务器。列表里如果出现本地运营商的地址,说明解析请求没有走线路。
- 用命令行确认。Windows 执行
nslookup example.com;macOS / Linux 执行dig +short example.com;macOS 还可以用scutil --dns查看当前的解析器顺序。
DNS 没走线路的三个常见原因
- 浏览器自己开了安全 DNS(DNS over HTTPS)。浏览器直连 DoH 服务器,绕过系统 DNS,客户端接管不到。处理:在浏览器设置里把安全 DNS 关掉,或改成「跟随系统」。
- 客户端只代理了 TCP,没有接管 UDP 53。处理:在客户端里打开 DNS 接管或远程解析相关选项。
- 分流规则把 DNS 请求判给了直连。处理:检查规则列表,让 DNS 跟随代理。
如果本地网络分配了 IPv6 地址,而线路只代理 IPv4,一部分流量可能绕过线路走 IPv6 直连。要么在客户端里开启 IPv6 支持,要么暂时关掉系统的 IPv6 再测一次。
按应用逐个验证:浏览器通了不代表终端通了
浏览器是最容易被代理覆盖的应用,所以只测浏览器,结论往往过于乐观。更稳妥的做法是挑三类典型场景各测一次。
- 浏览器:打开显示来源地址的页面,确认地址与所选节点地区一致。
- 终端:Windows 10 / 11 自带 curl,直接运行
curl https://api.ipify.org;PowerShell 用Invoke-RestMethod https://api.ipify.org;macOS / Linux 用curl -s https://api.ipify.org。 - 桌面软件与移动端:邮件客户端、同步盘、游戏启动器多数不读系统代理,需要在应用内单独设置,或者依赖 TUN 模式;手机上切换 Wi-Fi 与蜂窝网络之后,要重新确认一次。
终端与浏览器结果不一致怎么办
如果浏览器显示的是线路地址,终端返回的却是本地地址,基本可以确定当前是系统代理模式——终端默认不读系统代理。两种处理方式:开启客户端的 TUN 模式,让路由层接管;或者只给当前终端会话临时指定代理。
# 只给当前终端会话指定代理,端口以客户端界面显示的本地端口为准
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
# 再次确认出口地址
curl https://api.ipify.orgWindows PowerShell 里对应的写法是 $env:https_proxy="http://127.0.0.1:7890",只在当前窗口有效,关掉窗口即失效。
看起来连上了,其实没走的常见情况
下面这张对照表覆盖了新手最常遇到的几类情况。排查顺序建议从上往下:先确认整体是否生效,再处理单个应用或单个网站的例外。
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 出口 IP 前后完全一致 | 客户端处于系统代理模式,当前应用不读代理设置 | 切换到 TUN 或全局模式,或给该应用单独配置 |
| 浏览器正常,终端返回本地地址 | 终端默认不读系统代理 | 开启 TUN 模式,或设置 http_proxy / https_proxy 环境变量 |
| 个别网站不走线路,其他都正常 | 分流规则把该域名判成了直连 | 查看客户端的连接日志与规则命中,把域名加入代理列表 |
| 换了节点,出口地址还是原来那个 | 节点没有真正切换,或旧连接仍在使用 | 断开重连,并在客户端里确认当前选中的节点 |
| DNS 检测页出现本地运营商的解析器 | 浏览器安全 DNS 绕过系统解析,或客户端没有接管 DNS | 关闭浏览器的安全 DNS,开启客户端的 DNS 接管 |
| 换一个协议就能连,原来的连不上 | 网络环境丢弃了 UDP 数据包 | 改用可走 TCP 传输的协议对比测试 |
| 网页能开,语音通话仍走本地 | WebRTC 或应用自带的 P2P 直连绕过了代理 | 关闭浏览器的 WebRTC,或在应用内限制直连 |
| 状态显示已连接,实际完全无网络 | 系统里残留了旧代理设置,指向已经退出的软件端口 | 检查系统代理设置,重置为自动或关闭后重连 |
Hysteria2、TUIC 这类协议基于 QUIC,依赖 UDP;Shadowsocks、VMess、Trojan、VLESS 可以走 TCP 传输。遇到「节点正常却连不上」时,先换传输方式,再考虑换节点——公司网络与校园网丢弃 UDP 的情况并不少见。
三步自查清单与结论
把上面的内容压缩成一份可以照着做的清单,每次换网络环境、换节点之后重跑一遍:
- ✅ 连接前后各查一次出口 IP,地址发生变化,且归属地与所选节点地区一致。
- ✅ DNS 检测页列出的解析服务器里,没有本地运营商的地址。
- ✅ 终端
curl与浏览器返回同一个出口地址,不只是浏览器生效。 - ✅ 真正要用的应用逐个打开验证一次,而不是只测浏览器首页。
- ✅ 切换 Wi-Fi 与蜂窝网络之后重新确认一次,不沿用上一次的结论。
如果问题反复出现在同一段线路上,比如晚高峰持续丢包、UDP 类协议长期被拦截,那就不是客户端配置能解决的了,该考虑线路类型。VPNBF 提供 100+ 国家、230+ 线路,包含 IEPL 专线与中转线路,线路全程军工级加密,不限台数同时在线,支持 Windows / macOS / iOS / Android / Linux;注册只需用户名和密码,无需邮箱地址;7 天无理由退款,流量包永久不过期。
- 100+国家与地区
- 230+线路可选
- 不限台数同时在线
- 7 天无理由退款