VPN 已断开，互联网仍被阻断：是开关还是过时规则？

隧道关闭、浏览器停摆，而同一 Wi-Fi 上的其他设备都还能上网，这就排除了路由器。这种情形有三种可能的来源：被要求阻断的安全开关、已卸载客户端留下的状态，以及从未恢复的解析器或路由。从浏览器窗口看它们一模一样，却需要不同的修复方式。在运行网络重置之前，先确定你遇到的是哪一种。

两种截然不同的被阻断网络

有意的阻断是一项功能：没有活动隧道时，客户端会丢弃流量，以免任何数据绕出受保护路径。意外阻断则是客户端退出后残留的规则、设备或解析器设置。前者靠连接或有意关闭策略来修复，后者靠清理残留来修复。

区别体现在报错里，而不是浏览器里。有意的阻断通常表现为立即拒绝或静默卡住；而残留的解析器会造成域名解析失败，即使直接对字面地址 ping 能通也依然存在。两者都和 Wi-Fi 连接损坏不同，后者也会影响其他设备。按这个区别安排检查顺序：先测字面地址，再测域名。

客户端在断开时承诺了什么

阅读客户端自身的设置来理解断开的含义，因为不少产品把暂停和完全停止区分开来。暂停按设计会让阻断保持原状，而停止可能会解除它。一些移动平台把同一思路表述为常开规则：只要没有连接 VPN 就阻断流量。

在组织要求防护的场景里，修复方式是重新连接正确的配置文件，而不是绕过阻断。检查服务器名是否仍能解析，以及能否通过部署文档所列的例外访问端点，因为一次失败的重连看起来和持续阻断完全一样。

中断卸载留下的过时状态

一次中断的卸载，或在隧道运行时移除的软件包，可能留下防火墙链、路由规则、解析器条目或虚拟适配器。进程已经消失，影响却还在。

先从应用支持的清理和修复路径入手，然后在删除之前查明 每个残留对象是由哪个组件安装的。关闭主机防火墙会恢复浏览，但同时移除了无关的防护。全局网络重置更糟，因为它会丢弃可用的办公或 Wi-Fi 设置，却说不清原因。

如果装了两个客户端，就要确定谁拥有策略。两个所有者正是阻断在两者都被移除后仍能存活的原因。

验证断开后的状态，而不只是能否浏览

浏览恢复只是一个很弱的验收测试。要验证所需策略完好无损，并且没有其他东西被悄悄削弱。

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

把路由规则、解析器和防火墙策略与一台干净的已断开机器作对比。然后按正常流程重连再断开，并重复读取，让预期状态被写下来，而不是靠记忆。

把这份前后对照留在工单里。下一个看到浏览器被阻断的人，比起又一条“哪个客户端最好”的意见，更需要它。