VPN 显示已连接,但网页打不开 🌐

状态写着已连接,图标亮着,然后一个网页都打不开。

这是最常见的 VPN 问题之一,也是最容易误判的一个 —— 因为四种完全不同的故障, 会产生几乎一样的表象。于是人们不停地换节点,而问题从来就不在节点上。

下面这套方法能让你在一分钟左右分辨清楚。

---

🔎 第一步:你到底是哪一种故障?

按顺序走,每一步都会排除掉一部分可能。

1. 有任何东西能打开吗? 如果所有网站都打不开、隧道却显示已连接,直接跳到 DNS 那一节—— 绝大多数情况下就是它。

2. 有的能用、有的不能,毫无规律? 那不是隧道死了。见时好时坏。

3. 关掉 VPN,同一个网站也打不开吗? 那问题在你的网络或对方站点。VPN 应用里改什么都没用。

4. 你的流量真的走了隧道吗? 别假设,先验证 —— 见下一节。

---

✅ 先确认流量真的在走隧道

「已连接」只说明隧道建起来了,并不等于你的流量正在用它。

1. VPN 关闭状态下,打开任意一个显示你公网 IP 的页面,记下地址。
2. 连接,然后刷新那个页面。
3. 地址应该变化。

如果没变,说明你的流量完全绕过了隧道 —— 这时候再怎么换节点都没用。常见原因:

• 当前网络自己配了代理。 Wi-Fi 上或系统里设置的代理,会对遵守该设置的应用生效, 把它们的流量绕过隧道送走。这一条坑了非常多人,因为 VPN 确实是在正常运行的。
• 分应用规则把你用来测试的那个应用排除了(在提供该功能的平台上)。
• 某条分流规则把这个目标判给了直连。

---

🎯 最常见的元凶:DNS

当所有东西同时失效时,先怀疑域名解析,而不是别的。

为什么它和「隧道死了」长得一模一样:如果域名解析不出来,你的设备根本不会去尝试连接目标。 没有连接发生、什么都加载不出来,而隧道自始至终都是好的。

十秒钟确认的方法: 直接用 IP 地址访问试试。如果数字地址能通、域名不行, 那你的隧道没问题,是 DNS 坏了。

接着查这几项:

• 你的配置为代理流量指定的解析器是哪一个,它在当前网络下可达吗?
• 你是不是刚改过 DNS 设置? 重新连接一次,让配置重新加载。
• 是不是缓存了一个失败结果? DNS 结果会被缓存,一个失败的缓存可能比修复本身活得更久。 重连后,在新的浏览器窗口里重试。

---

🎲 时好时坏的情况

有的网站能开、有的一直转圈;好了一阵,又坏了;毫无规律。

这几乎从来不是隧道坏了。绝大多数情况是下面两个原因:

你的节点分组正把连接派给死节点。 很多客户端会把连接分散到一组服务器上。 如果这个分组的策略不按健康状况排序,那么每一个成员都会分到一份真实流量 —— 包括那些从你的网络根本连不通的。大约每五次连接失败一次, 感觉上就是「网络不稳定」,而不是「有些节点是死的」。

健康数据过期了。 延迟测量是按周期刷新的,而很多客户端在隧道空闲时会停止刷新。 第二天早上重连,选择依据的可能是几小时前的数据 —— 那时候某个现在已经挂了的节点, 恰好看起来最快。

两者的解法是同一个:用按健康状况排序的选择策略,并在闲置之后重新测一次延迟。 AI Booster 默认就用按健康状况排序的策略,并在隧道连上的那一刻重新测量, 正是因为这种故障模式。

我们在同一份订阅上实测过两者的差距:数据在这里。

---

🔌 如果是压根连不上

这是另一个问题,另一套排查清单:

1. 刷新订阅。 过期的配置会留下一批已经无法通过认证的条目。
2. 关掉其它 VPN 应用。 大多数系统同时只允许一个 VPN 配置生效。
3. 重新授权系统 VPN 权限。 如果之前拒绝过,客户端可能只是失败而没有明确提示。
4. 换个网络。 Wi-Fi 换移动数据,或者反过来。这能把「这个节点挂了」和 「这个网络封了它」区分开 —— 有些网络会直接封锁特定的传输方式。
5. 手动指定某一个节点,不要用自动分组,这样结果指向的是一个确定的节点。

---

🔋 附:一息屏就断

在手机上,这通常是系统为省电把应用挂起了,而不是网络故障。 去系统的电池优化设置里为这个 VPN 应用放行;如果它提供了「连接中」的常驻通知, 保持开启也有帮助 —— 系统正是靠这个通知来决定要不要让它继续活着。

---

📋 一张表看完

一次只改一个设置,每改一次就重新测。 一口气改五项,你永远不会知道是哪一项起了作用 —— 而且多半会让其中四项停留在比原来更糟的状态。

---

延伸阅读:完整故障排除指南 · 节点选择是怎么工作的