VPN 已连接却没有网络？逐层排查这四层

客户端显示已连接，浏览器一直转圈，每个网站都以超时收场。这种组合很常见，也并不矛盾：已连接只说明隧道完成了协商，仅此而已。域名解析、路由和服务器自身的出口各有各的失败方式，也各有各的责任人。按顺序逐层排查，在第一层失败处停下。

先看你来时的网络

用客户端自带的断开按钮关闭隧道，然后在策略允许时试两个互不相关的 HTTPS 网站。测试期间把敏感工作关掉。如果普通访问也失败，VPN 就不是第一嫌疑人。

在碰隧道之前，先看 Wi-Fi 链路、路由器以及任何要求登录的认证页面。按设计，kill switch 可能在断开时阻断流量，所以应按照其文档化的测试流程操作，而不是直接断定网络已死。换一个可信网络是有用的对照，而新的 VPN 出口也不会替你把过期的酒店登录补完。如果开放网络能用而隧道不能用，网络就被排除，下一层就是你的。

判断失败是不是域名解析

把报错原文记下来，因为解析失败、超时和证书告警分别指向不同的地方。要尽早抓住的模式是：从未访问过的主机名失败，而已经建立会话的应用仍在继续。这个模式说的是新查询，而不是隧道是否在转发数据包。一次查询就能看出解析器返回什么，运行只要一秒。再试第二个名字，免得一条缓存结果或一条损坏记录就定了诊断。

nslookup example.com

在 HTTPS 地址栏里输入任意 IP 并不是 DNS 测试，因为证书和虚拟主机通常取决于域名。内部名称可能需要组织自己的解析器，而不是公共替代品；自带安全解析器的浏览器也可能给出与操作系统查询不同的答案。两者不一致时，用户体验到的是浏览器解析器的结果，这个区别应当写进工单。

全隧道还是只走公司子网

有些配置文件只用于访问少数几个公司子网；另一些则设计为承载全部流量，背后必须有可用的出口。在假定指示灯覆盖所有应用和所有地址族之前，先读文档写明的用途。专用网络的配置文件可以完全按设计工作，而本不该使用它的浏览器依然失败。只读不改地查看路由表，并把 IPv6 也算进去，因为一条能用的 IPv4 路径并不能说明另一个地址族的情况。

更具体的路由可以在默认路由仍存在时胜出，所以路由表必须去读，不能想当然。相互竞争的虚拟网卡也可能占住你本以为在别处的流量，尤其是在装了第二个 VPN 客户端又忘了之后。不要把删除默认路由当作实验，那会把一次诊断变成第二次断网。

在能用的网站中只有一个失败，那是这个网站的问题，同时也证明隧道在转发流量。只有大文件传输时才出现的卡顿指向包大小，而不是可达性。

当服务器根本不做转发

如果两台设备、两个接入网络下所有目标都失败，隧道是通的，而出口没有转发。正是这一组合把服务器侧故障与某一处配置错误的单台设备区分开来。给运维发去转发、NAT 和回程路径的问题，而不是指示灯截图。

这三项覆盖了服务器侧的大多数原因，回答它们是运维的职责。OpenVPN 连接故障排查页面从服务器侧走的是同样的问题，所以请连同工单一起转过去。一张绿灯截图一个也答不上来。

登录之后翻客户端日志，找应用路由、DNS 设置或虚拟网卡时的失败。那个阶段的错误指向设备，而不是服务器。日志里从未出现的错误同样有信息量，因为它把怀疑推到了对面。

一次只查一层

改动之后重新连接，并重复那个确实失败的应用。单个页面能打开，比通往配置文件目标资源的可重复路径证明力更弱。两条命令把解析和可达性分开，第二条因主机而异。curl 那行哪里都能跑，然后再跑与你面前主机匹配的路由命令。

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

如果数字请求能通而域名不通，就留在 DNS 上。如果两者都不通，把路由表与隧道预期的默认值对照，并检查你实际在测的地址族。如果路由正确而请求仍然死在出口，剩下的问题归运维，而你留存的证据就是工单。