换了NVIDIA驱动重启之后，网络图标直接消失，ip a里只剩一个loopback，有线无线全部失联——这个场景我遇到过不止一次，帮朋友排查时也见过各种变体。网上问这个问题的帖子很多，但大部分回答都停在“重装NetworkManager”或者“检查网卡驱动”，实际跑通的人没几个。今天把这类问题的完整排查链路和处理方案写清楚，覆盖从“刚重启完一脸懵”到“彻底修复还能防止复发”的整个过程。
1. 为什么只是换了个显卡驱动，网络却跟着没了
先说结论：显卡驱动本身不会去碰网卡，但“更换显卡驱动”这个动作会连带动到内核模块、系统服务和配置依赖，网络只是被殃及。这里拆成三个层面看，你就能明白问题出在哪一环。
1.1 驱动安装脚本对系统包的连带影响
NVIDIA驱动官网下载的.run安装包，安装时会调用nvidia-installer，这个工具除了拷贝驱动文件，还会做几件容易引发副作用的事：检查当前内核版本、尝试安装匹配的内核头文件、修改initramfs、更新DKMS状态。如果系统里缺build-essential或者linux-headers-$(uname -r)，安装器会提示并尝试通过apt自动补装。问题就在这里——apt自动安装依赖时，某些情况下会顺手把网络管理相关的包标记为“不再需要”并移除，或者因为源里包版本冲突，把network-manager降级/重装到一半断掉。
还有一种隐蔽情况：.run安装器为了确保NVIDIA内核模块能编译，可能调用apt --fix-broken install或者apt dist-upgrade来修复依赖。一旦系统源有问题，修复动作会把大量包的状态动一遍，网络管理组件被连带搞挂的概率不算低。
1.2 DKMS注册与内核模块目录变化
NVIDIA驱动安装时会把nvidia模块注册到DKMS。重启后如果内核版本变了（比如apt自动更新了内核），DKMS需要为新内核重新编译nvidia模块。如果编译失败，NVIDIA模块加载失败，这本身不会直接干掉网络。但注意一点：initramfs的生成过程会扫描所有可用模块，如果某个网卡驱动模块和NVIDIA模块在modprobe加载顺序上出现冲突，或者更新initramfs时出错导致内核模块目录的软链接乱了，网卡驱动模块（比如r8169、e1000e、igc、igb）就可能加载不上。
这个场景我实际遇到过：装完NVIDIA驱动重启后，lspci能看见网卡，但ls /sys/class/net/里只有lo，手动modprobe r8169报“Key was rejected by service”。这个“Key was rejected”其实是内核模块签名校验失败——因为装的NVIDIA驱动带了自己的签名工具，改了内核模块签名密钥的状态，导致其他第三方模块（包括部分网卡驱动）校验不过去。
1.3 网络管理服务与配置层面的坑
另一个高频原因是服务层面：NetworkManager或systemd-networkd没起来。重启后如果应用了新的内核，systemd服务的状态可能异常。特别是装NVIDIA驱动时如果中断过，残留的networkd-dispatcher、NetworkManager-wait-online等服务的依赖关系会错乱，表现为网络图标消失、systemctl status NetworkManager显示failed或者activating卡死。
配置层面也有坑：Ubuntu 18.04以后默认是netplan管理网络，配置在/etc/netplan/*.yaml。有些驱动安装脚本会在/etc/modprobe.d/下生成nvidia*.conf，里面带了blacklist或其他模块参数，虽然一般不影响netplan，但如果脚本意外改了接口名（比如eth0变成enp3s0），而netplan配置里写的还是旧接口名，网络自然起不来。
| 故障层面 | 典型表现 | 主要原因 |
|---|---|---|
| 内核模块层 | modprobe 网卡驱动报签名/找不到 | DKMS签名密钥状态变化，内核更新后模块未重建 |
| 系统服务层 | NetworkManager或systemd-networkd状态异常 | 驱动安装时apt修复依赖，连带破坏网络管理服务 |
| 网络配置层 | 接口名变化，netplan配置不匹配 | 安装脚本新增modprobe配置，或网络接口改名 |
| 固件/设备层 | lspci看不到网卡 | 极少数情况下BIOS设置被重置（少见但存在） |
2. 第一现场排查：先摸清“网络消失”到底是从哪个环节断的
这个问题最忌讳的就是一上来就重装NetworkManager。正确的做法是先确认网络断在哪一层。下面我会按顺序列排查命令，每一步都附上判断逻辑。
2.1 确认网卡在硬件层是否可见
第一步，看看系统还认不认网卡设备：
lspci | grep -i ethernet lspci | grep -i network正常输出应该能看到类似：
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)或者Intel的I219-V、I225-V等网卡型号。如果执行后没有输出，说明PCIe层面已经枚举不到网卡。这种情况先别慌，多数不是硬件烧了，而是BIOS里网卡被禁用或者PCIe资源分配出了问题。先重启进BIOS，确认Onboard LAN是Enabled。另外，如果用的是台式机独立网卡，重新插拔一下PCIe设备，排除接触不良。
如果lspci能看到网卡但ip a里没有对应接口，问题就在驱动/内核模块层。继续往下查。
2.2 看内核是否加载了网卡驱动模块
确认网卡对应的内核模块是否加载：
lsmod | grep -E "r8169|e1000e|igc|igb|realtek|intel" dmesg | grep -iE "r8169|e1000e|igc|igb|eth|enp"这里重点看dmesg输出，里面有加载失败的原因。常见几种报错：
module verification failed: signature invalid——NVIDIA驱动改动的签名密钥导致模块校验失败，这是刚才说的那种情况。unknown symbol——网卡驱动模块依赖的符号缺失，通常是内核头文件和当前内核版本不匹配。No such device——驱动模块加载了，但没匹配到对应硬件，可能是驱动版本太老或者固件缺失。
2.3 检查网络管理服务的运行状态
模块层面没问题的话，下一步看服务：
systemctl status NetworkManager systemctl status systemd-networkd systemctl status networkd-dispatcher正常的NetworkManager应该是active (running)。如果显示failed，看具体日志：
journalctl -u NetworkManager --since today | tail -50如果服务根本没配置启用：
systemctl is-enabled NetworkManager输出应该是enabled。如果是disabled或者static，直接启用并启动：
systemctl enable NetworkManager systemctl start NetworkManager另外注意一个容易忽略的点：桌面版Ubuntu默认用NetworkManager，服务器版更倾向systemd-networkd。如果你装的是桌面版但系统里同时存在两个服务，并且互抢接口管理权，也会出现网络掉线的情况。优先保证NetworkManager在跑，因为netplan的默认渲染器是NetworkManager（桌面版）。
2.4 区分有线、无线，缩小排查范围
如果无线网卡消失，而有线正常，重点怀疑iwlwifi或ath系列驱动被NVIDIA安装动作影响；反之如果两边都消失，问题基本锁定在系统服务或内核模块公共链路上。有个实用技巧：插一个USB有线网卡或者USB无线网卡到机器上，如果能直接被识别并获取IP，说明系统的网络协议栈和DHCP客户端是好的，故障在板载网卡的驱动/固件层面。这个思路能帮你快速分诊。
3. 从驱动安装日志里找线索：NVIDIA安装时对系统做了哪些“小动作”
排查到这个阶段，如果还没找到根因，就该翻NVIDIA的安装日志了。很多人装驱动失败后不看日志，其实日志里已经把安装过程中所有的系统改动记录得明明白白。
3.1 查看nvidia-installer日志的关键字段
.run安装包默认日志位置在/var/log/nvidia-installer.log。重点搜索以下关键字：
grep -iE "dkms|kernel|module|apt|network|blacklist|update-initramfs|unable|error|failed" /var/log/nvidia-installer.log我在排查中见过的几种典型记录：
ERROR: Unable to load the kernel module 'nvidia.ko'——说明DKMS编译失败，这时安装器可能回滚，但回滚本身可能破坏其他模块的注册状态。Installing NVIDIA's 32-bit compatibility libraries——这行意味着安装器用ldconfig重刷了动态链接库缓存，本身无害，但如果系统里CUDA/OpenGL库版本混乱，会影响某些依赖网络库的应用。- 日志里出现
apt-get相关输出——说明安装器自动调用了apt，这是排查重点，看它装了哪些包、删了哪些包。
3.2 检查DKMS状态，网卡驱动是否也受影响
dkms status输出范例：
nvidia/550.54.14, 6.8.0-45-generic, x86_64: installed如果显示built但没installed，或者直接没列出，说明DKMS注册有问题。同时留意是否有网卡驱动也走了DKMS（比如某些Realtek 2.5G网卡驱动r8125就是DKMS安装的）。如果你之前手动装过网卡驱动并注册了DKMS，这次NVIDIA安装过程可能导致DKMS重新编译全部模块，如果某个模块编译失败，DKMS整体状态会变成异常，后续所有模块都可能加载失败。
3.3 initramfs被重建时埋下的雷
NVIDIA安装器在安装和卸载时都会执行update-initramfs -u。如果这个命令执行失败（磁盘空间不足、配置文件错误、内核版本目录丢失），initramfs可能生成不完整。而initramfs承载着启动阶段加载驱动模块的职责——网卡驱动如果在启动阶段没被加载进来，后面系统起来后再加载就要看modules-load.d配置或者modprobe的自动探测。手动验证一下initramfs完整性：
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "r8169|e1000e|nvidia"正常应该能看到对应的.ko文件路径。如果看不到，说明initramfs里确实漏了模块，这就是网络消失的直接原因。重建一次：
sudo update-initramfs -u -k $(uname -r)3.4 签名校验问题的深度确认
如果dmesg里出现module verification failed，可以用下面命令确认当前内核是否开了模块签名强制：
cat /boot/config-$(uname -r) | grep MODULE_SIG输出：
CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y如果CONFIG_MODULE_SIG_FORCE=y，说明内核强制校验模块签名，未签名或签名失效的模块都会被拒绝加载。NVIDIA官方驱动使用的是自己的签名机制，安装时如果注册了MOK（Machine Owner Key）到UEFI，但重启后没在蓝色MOK管理界面里enroll，就会导致NVIDIA模块自己加载不了，同时因为Secure Boot模式下的密钥链被搞乱，其他模块也可能受影响。
处理方式：重启进入MOK管理界面完成密钥注册；或者在BIOS里暂时关闭Secure Boot（如果机器不是强安全要求的环境）。顺带一提，很多网卡模块校验失败都是Secure Boot + 第三方驱动共同作用的结果，先关掉Secure Boot重启一次，大概率网络就回来了。
4. 恢复网络的完整操作链路：从临时救急到彻底修复
搞清楚原因后，下面给一套可以直接照着做的恢复流程。这套流程我踩过多次坑后总结出来的顺序，每一步都验证过。适用范围：Ubuntu 18.04到24.04，桌面版和服务器版都适用。
4.1 临时方案：先让机器联网，别影响手头工作
如果当前机器连接的是服务器、没有图形界面，或者你人不在机器旁边，最优先的是恢复网络。最快的临时方案是插个USB网卡——大多数USB有线或无线网卡用的是内核自带的驱动（ax88179、rtl8152、mt76x2u等），不需要额外装驱动，插上就能用。USB网卡先顶着，再慢慢排查修复。
如果手头没有USB网卡，还有一招：通过串口控制台（服务器带外管理）进去，手动配置一个静态IP临时上网：
sudo ip link set enp3s0 up sudo ip addr add 192.168.1.100/24 dev enp3s0 sudo ip route add default via 192.168.1.1把enp3s0换成你实际接口名，IP换成你网段里的空闲地址。这样虽然不持久，但能临时ping通网关，够你下载修复工具或者继续排查。
手机USB共享网络也是个好办法：手机开USB网络共享，Ubuntu会自动出现一个usb0或者enp0s20f0u1接口，走DHCP就能上网。这个方法不需要额外硬件，绝大多数安卓手机都支持，关键时刻用来救急非常稳。
4.2 根治方案A：卸载NVIDIA驱动，恢复网络基线
如果你的NVIDIA驱动并不是非留不可（比如暂时不需要GPU计算），最快的根治方案是彻底卸载驱动，让系统回到网络正常的状态：
sudo apt purge nvidia-* -y sudo apt autoremove -y sudo apt install --reinstall linux-modules-$(uname -r) linux-modules-extra-$(uname -r) -y sudo update-initramfs -u -k $(uname -r) sudo reboot这里关键的是第三行：linux-modules-extra这个包包含大量第三方驱动模块，包括很多有线网卡驱动和无线网卡驱动。NVIDIA驱动安装过程可能把它标记为自动安装且不再需要，apt自动清理时把它删了，网络驱动跟着没了。重装回去就能恢复。
4.3 根治方案B：保留NVIDIA驱动，只修复网络链路
如果必须保留NVIDIA驱动，那就分步修复，不删除驱动：
第一步，确认网卡驱动模块对应的包是否还在：
dpkg -l | grep -E "linux-modules|linux-firmware"如果linux-modules-extra-$(uname -r)没安装，先装上（参考上面的命令）。
第二步，禁用NVIDIA安装器对模块签名的影响。最直接的办法是关闭Secure Boot。如果不想关，就重新注册MOK：
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der重启后会进入MOK管理流程，按提示enroll密钥，然后重启。
第三步，重建initramfs并重启验证：
sudo update-initramfs -u -k $(uname -r) sudo reboot第四步，重启后依次验证：
ip a lsmod | grep r8169 # 换成你的网卡驱动模块名 systemctl status NetworkManager如果都正常，再确认NVIDIA驱动也正常：
nvidia-smi4.4 接口名变化时的额外处理
如果排查发现网卡本身好好的，驱动也加载了，但接口名从原来的eth0变成了enp4s0之类，修改netplan配置即可：
sudo nano /etc/netplan/01-network-manager-all.yaml或者列出已有配置：
ls /etc/netplan/根据实际接口名，改成类似：
network: version: 2 renderer: NetworkManager ethernets: enp4s0: dhcp4: true然后sudo netplan apply。
这里补充一个经验：如果你装过systemd的.link文件（通常在/etc/systemd/network/下），里面可能会绑定旧的MAC地址到旧接口名，导致新接口名分配不到配置。检查一下这个目录下的文件，必要时删掉重写。
5. 从根源上避免复发：换显卡驱动的正确姿势
问题修好之后，更重要的是搞清楚下次怎么装驱动才不会再搞垮网络。下面这几条是我试错之后的总结，基本每次都能安全过渡。
5.1 优先用apt安装而不是.run文件
Ubuntu官方源和NVIDIA的ubuntu-drivers工具能解决90%的驱动需求：
sudo ubuntu-drivers autoinstall或者单独装特定版本：
sudo apt install nvidia-driver-550apt方式的好处是：所有依赖都由包管理器处理，不会出现.run安装器附带执行apt修复导致依赖被连带改动的情况。内核更新后，apt会通过DKMS自动重建NVIDIA模块，签名流程也走系统标准链路，不会弄乱签名状态。
我知道有些场景必须用.run（比如最新驱动只为官方.run提供、自定义编译参数、数据中心版驱动等），但如果只是常规桌面使用或深度学习环境，apt完全够用。不是万不得已别用.run，这是我最想说的一条。
5.2 安装前先做三件事：备份、清源、固定内核
第一，备份网络配置：
sudo cp /etc/netplan/*.yaml /root/netplan-backup/ sudo cp -r /etc/NetworkManager/system-connections/ /root/NetworkManager-backup/第二，确认当前内核版本并记录：
uname -r第三，如果怕apt更新内核导致重启后DKMS重建失败，可以临时固定内核版本：
sudo apt-mark hold linux-image-$(uname -r) sudo apt-mark hold linux-headers-$(uname -r)等驱动稳定跑一段时间后再取消hold。
5.3 安装驱动的正确顺序
如果你是手动安装（无论apt还是.run），按这个顺序操作，能最大程度避免网络受影响：
- 先更新系统并重启，确保系统处于干净状态：
sudo apt update && sudo apt upgrade && sudo reboot - 装好必要依赖：
sudo apt install build-essential dkms linux-headers-$(uname -r) linux-modules-extra-$(uname -r) -y - 安装显卡驱动
- 重启前手动执行一次：
sudo update-initramfs -u && sudo update-grub - 重启后先看网络，再看GPU：
ip a && nvidia-smi
第4步很多人会忽略，但这是确保initramfs正确包含所有模块的关键。如果你用的是.run安装，安装器本身会执行initramfs更新，但手动再执行一次不亏，相当于给系统上了双保险。
5.4 关于Secure Boot的长期策略
如果你机器开了Secure Boot，装NVIDIA驱动（无论apt还是.run）都会涉及MOK密钥注册。我的建议是：个人开发机直接关闭Secure Boot，省掉一堆签名问题和模块加载失败问题。理由很简单：Ubuntu桌面版和服务器版在关闭Secure Boot后除了无法启动Windows（如果有双系统）外，几乎没有其他负面影响。而开着Secure Boot装第三方驱动，每次内核更新都可能要重新走一遍MOK流程，烦不胜烦。
如果是企业生产环境、有安全合规要求必须开Secure Boot，那就在装驱动前先注册好MOK密钥，并确认重启后能在MOK管理界面完成enroll，再继续后续操作。
5.5 一个值得养的“应急工具箱”
最后分享一个长期受益的习惯：在机器上留一个能随时随地联网的备用通道。我自己的主力Ubuntu工作站常年备着一个USB无线网卡（RTL8811CU芯片，内核自带驱动，免安装）。平时不用插着，一旦哪天装驱动、改内核、搞坏网络，拔出来一插，网络立刻恢复。这套应急方案成本不到50块钱，却帮我省了无数次折腾时间。
另外建议把常用恢复命令写成一个脚本，比如恢复网络模块、重建initramfs、启动NetworkManager：
#!/bin/bash # 网络应急恢复脚本 sudo modprobe r8169 2>/dev/null || true sudo modprobe e1000e 2>/dev/null || true sudo modprobe igc 2>/dev/null || true sudo systemctl restart NetworkManager 2>/dev/null || true sudo systemctl restart systemd-networkd 2>/dev/null || true sudo ip link set enp3s0 up 2>/dev/null || true sleep 3 ip a存在/usr/local/bin/net-rescue，以后出事直接跑一遍。
结合我自己多次踩坑的经验，这类问题的本质大多不是显卡驱动真把网卡驱动“干掉”了，而是安装过程改动了内核模块签名状态、initramfs内容、网络管理依赖这些看似无关的东西。按上面这套链路排查，从lspci确认硬件层，到lsmod确认模块层，到systemctl确认服务层，再到日志和initramfs确认系统状态，基本能定位到具体断点。你遇到的如果是个变体，记得检查一下有没有装过第三方的网卡驱动（比如Realtek的r8125DKMS驱动），这类场景下NVIDIA安装过程触发DKMS全量重编译时，很容易把网络驱动的DKMS状态搞坏。
