Windows 装了 VPN，Linux 启动却上不了网：该查什么

在 Windows 里装了 VPN，重启进入 Linux 后有线连接却是死的。显而易见的故事自己就写好了：VPN 留下了什么。这个故事是错的，因为两次启动运行的是各自独立的内核，驱动、路由表与解析器都互不相干。Windows 的网络过滤器不会在 Linux 内部执行，所以故障要么在 Linux 的网络栈里，要么在两次启动真正共享的东西上，比如硬件、固件或路由器。

症状与错误的结论

观察中有用的部分是时间：故障出现在某次改动之后。没用的部分是把因果直接跳到 Windows 的 VPN 上，它根本不可能在另一个操作系统里运行。把这两者分开，就是全部工作。动线缆之前先把时间线写下来。

两次启动真正共享的是物理网卡、线缆、交换机端口以及上游的一切。这些才是真实的共同变量，值得在检查完 Linux 网络栈之后再查一遍。

用四条命令给 Linux 网络栈做快照

先以只读方式开始，在改动任何东西之前记录状态：ip -br link 看接口是否存在，ip -br address 看地址，ip route 看 IPv4 路由，在关心 IPv6 的地方再用 ip -6 route。ip 工具的参考文档会区分这些对象，而接口出现在列表里，并不等于它有可用的地址或可用的路由。

把输出存进文件，以便之后与能正常启动时的输出对比。无法复现的快照，只是对某个状态的记忆。

是链路、地址、路由还是名字？

四种互不相同的故障，从浏览器里看却一模一样。设备可能完全不存在、存在但没有载波、已连接但没有预期地址，或者有地址却没有通往目的地的路由。原始地址能用而域名解析失败是第五种情况，它属于解析器而不是驱动。

每种情况指向不同的工作：设备缺失查驱动或固件，没有载波查线缆或交换机，地址缺失查 DHCP 或静态配置，路由缺失查路由或策略。解析器问题则指向 systemd-resolved、NetworkManager 或本地 DNS 配置。

查一下这个 Linux 安装有没有自己的 VPN 或持久化的防火墙配置。本地隧道或 nftables 规则集是 Linux 一侧的责任方，它比一个根本没在运行的 Windows 程序更可能解释故障。

然后对比启动切换

Windows Fast Startup 是一种混合关机，它保留内核会话状态，而不是执行完整启动。微软关于电源状态的文档把它与重启、完全关机区分开，所以同一套硬件在两种切换下表现可能不同。

如果故障取决于从一个操作系统切到另一个，那么在保存工作之后，把有记录的重新启动或完全关机与正常路径做对比。结果跟着切换走，才值得去查驱动、设备或固件状态；它本身并不能证明 Fast Startup 造成了某次具体的网卡故障。

记录上一次使用网卡的是哪个操作系统、切换类型、Linux 里的链路状态，以及第一个失败的操作。可重复的冷启动与热切换差异，远比在不知道哪一层坏掉的情况下把两个系统里的 VPN 软件都卸掉更有价值。

不该改什么

不要把重置两边的网络栈当作第一步。那样会毁掉对比，而且往往什么也修不好，因为真正的责任方从未被确认。不要为了修 Linux 去重装 Windows 的 VPN，也不要因为某次启动切换与故障相关就乱改固件设置。

ip 工具的参考文档记录了上面用到的链路、地址与路由对象。先读 Linux 一侧，留住快照，然后再决定是否需要查共享的硬件层。