Ubuntu 突然没网了这句话我在工位、技术群和论坛里大概见过上千次。上一秒还在 ssh 会话里跑编译下一秒apt update就卡在正在连接或者直接甩一句无法解析域名。有意思的是绝大多数情况下网卡硬件没坏、路由器也好好的出问题的是系统这一侧的网络管理链条——从内核认不认这块网卡到谁负责发 IP再到谁负责解析域名中间任何一环断了用户看到的现象都叫没网。这篇东西就按我平时修机器的顺序把这条链拆开怎么在五分钟内判断毛病出在哪一层虚拟机、双系统、笔记本休眠唤醒、远程 SSH 连不上这些场景各自踩过什么坑临时救急和长期配置分别怎么做。刚装完 Ubuntu 的新手能照着抄命令手上管着几台开发机的老手也能挑走几个少走弯路的细节。1. 断网先分层Ubuntu 网络故障的三种形态和五分钟定位法修网络最忌讳的就是一上来就systemctl restart NetworkManager或者直接重启机器。重启确实能解决一部分问题但它把现场也一起销毁了下次同样的问题还会再来一次。我习惯先把故障归类因为没网这个描述太粗了粗到没法指导任何操作。1.1 三种典型形态没网卡、没 IP、有 IP 出不去第一种形态是系统压根没认到网卡。表现是ip a里只有lo看不到enp3s0、wlp2s0这类接口或者接口存在但状态是DOWN。这种基本跟 DNS、网关无关问题在驱动、内核模块、硬件识别或者虚拟机网络适配器配置这一层。第二种形态是网卡在但没有拿到 IP。ip a能看到接口状态UP但下面没有inet 192.168.x.x这一行。原因通常是 DHCP 没跑起来、netplan 配置里dhcp4没开、静态地址写错或者虚拟机 NAT 服务挂了。第三种形态是IP 有了出不去。ip a正常ip route里有默认路由但 ping 网关不通或者 ping 外网不通。这时候要分清是二层链路问题、路由问题、DNS 问题还是被本机防火墙和残留规则挡了。这三种形态对应完全不同的排查路径。你要是拿着是不是 DNS 坏了的思路去查第一种能查到天亮。1.2 我常用的五分钟分层排查命令下面这套命令是我放在笔记里、随时复制的按顺序敲下来基本能定位到层。# 1. 看网卡是否存在、是否 UP、有没有 IP ip -br a # 2. 看默认路由和网关 ip route # 3. 看网关通不通把 192.168.1.1 换成你自己的网关 ping -c 3 192.168.1.1 # 4. 看公网 IP 通不通用国内公共 DNS避免解析干扰 ping -c 3 223.5.5.5 # 5. 看域名解析通不通 ping -c 3 www.baidu.com # 6. 看 DNS 服务器是谁、解析走哪条路 resolvectl status # 7. 看 NetworkManager 眼里的设备状态 nmcli device status这七条命令的信息量非常大。ip -br a用的是简表格式一眼就能看出哪个口有地址ip route里如果没有default via那一行说明系统不知道怎么出网这时候 ping 外网必然不通问题在路由而不是 DNSping 223.5.5.5通但ping www.baidu.com不通那就锁定在 DNS 层nmcli device status里如果设备显示unmanaged说明 NetworkManager 根本没接管这块网卡你在 GUI 上怎么点都没用。注意排查阶段尽量别改配置先把输出拍照或者复制到记事本里。修好之后回头对比你才知道到底是哪一条变了。1.3 症状对照速查表把常见现象和第一嫌疑人对上号能省掉一大半瞎试的时间。现象第一嫌疑人优先验证命令ip a只有 lo驱动未加载 / 虚拟机网卡未连接lspci -k | grep -A3 -i net接口存在但一直 DOWN网线、虚拟交换机、rfkill 阻塞rfkill list、ip link show接口 UP 但没有 IPDHCP 失败 / netplan 配置错误sudo dhclient -v enp3s0有 IP 但 ping 网关不通网段写错 / 桥接模式选错物理网卡ip route、虚拟机网络设置ping IP 通、域名不通DNS 配置被覆盖resolvectl status本机能上网、SSH 连不上sshd 未启动 / 防火墙 / IP 变了ss -tlnp | grep 22重启后配置全丢netplan 文件权限或语法问题sudo netplan generate表格里我特意把本机能上网、SSH 连不上单独列了一行因为这类故障特别容易误导人——你在虚拟机里浏览器能打开网页就默认整机网络正常实际上很可能只是 IP 从 DHCP 换了一个或者 sshd 压根没开机自启。这两种情况跟网络本身半毛钱关系都没有。2. 桌面版与服务器版的网络栈差异到底谁在管你的网卡搞清楚谁在管网卡这件事比记住十几条命令更重要。Ubuntu 上同时存在好几套网络管理组件它们互相之间是有分工也有冲突的配置写错地方就会出现我明明改了但一点用没有的情况。2.1 NetworkManager、systemd-networkd 和 netplan 的分工大概的分工是这样的netplan 是配置的入口你在/etc/netplan/下写 YAML它负责把这套配置翻译成后端能懂的格式NetworkManager 和 systemd-networkd 是后端真正去操作网卡、发 DHCP 请求、配置地址的是它们。Ubuntu 桌面版默认后端是 NetworkManager服务器版默认是 systemd-networkd。这个区别非常关键如果你在桌面版上按服务器版的教程去重启systemd-networkd你会发现命令执行成功了但网络状态一点变化都没有因为管事的压根不是它。反过来也一样。判断当前谁在管事看这几个地方# 看 netplan 文件里 renderer 写的是什么 grep -r renderer /etc/netplan/ # 看两个后端服务的运行状态 systemctl is-active NetworkManager systemd-networkd # 看设备被谁接管 nmcli device statusnmcli device status输出里STATE列如果是unmanaged说明 NetworkManager 主动放弃了这个设备通常是因为 netplan 里把这个接口的 renderer 指给了 systemd-networkd。这时候你在桌面右上角的网络图标里找不到这个连接属于正常现象不是坏了。2.2 netplan 配置写错长什么样netplan 是 YAML 格式YAML 这东西对缩进极其敏感多一个空格少一个空格就是两种结果。而且它的报错信息不算友好很多人看到一堆红色输出就慌了。实际上常见的就三类问题缩进层级不对、字段名跟版本不匹配、文件权限太开放。字段名这块有个大坑。Ubuntu 22.04 之后gateway4这个字段已经被标记为废弃虽然还能用但会打印警告新写法是routes加to: default。网上大量老教程还在用gateway4你照着抄能通但每次netplan apply都会刷一堆 deprecated 警告看着心里没底。我建议直接按新写法来。network: version: 2 renderer: NetworkManager ethernets: enp3s0: dhcp4: false addresses: - 192.168.1.50/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [223.5.5.5, 114.114.114.114]这段配置里addresses后面的/24是掩码长度别漏routes是列表每一项要缩进对齐nameservers里的地址用方括号数组写法更紧凑。写完先别急着 apply用sudo netplan generate做一次语法检查它不会动网卡只做解析报错会清楚地告诉你哪一行有问题。还有一个容易被忽略的点/etc/netplan/下的文件权限必须是 600属主 root。权限太开放的话netplan 会拒绝应用并给出一句Permissions for ... are too open。很多人从别处拷贝配置文件过来权限带过来是 644就卡在这里。2.3 检查与重启网络服务的正确姿势重启服务这件事要分情况。如果是 NetworkManager 管设备重启它是有意义的如果设备归 systemd-networkd 管那就要重启后者。# NetworkManager 场景 sudo systemctl restart NetworkManager # systemd-networkd 场景 sudo systemctl restart systemd-networkd # 让 netplan 重新生成并应用配置 sudo netplan applynetplan apply是一个重活它会短暂中断网络。如果你是通过 SSH 远程操作直接 apply 风险很大——配置一写错你的连接立刻断而且断完之后你再也连不回去只能去机房或者虚拟机控制台。提示远程改网络配置时一定用sudo netplan try。它会应用配置并启动一个 120 秒的倒计时期间网络是通的你确认没问题按回车配置正式生效如果你不按或者配置把网络弄断了导致你连不上120 秒后自动回滚到之前的配置。这个机制救过我至少三次。3. 不同场景下的断网成因逐个拆解同样是突然没网场景不同成因分布差异极大。把场景先确定下来排查范围能瞬间缩小一半以上。3.1 虚拟机断网VMware 与 VirtualBox 的三种网络模式虚拟机是 Ubuntu 断网求助里占比最高的一类。核心原因就一个虚拟机的网络依赖于宿主机上的一层虚拟交换和 NAT 服务这层服务比虚拟机本身脆弱得多。VMware 和 VirtualBox 都提供三种主要模式行为差异很大模式虚拟机拿到的 IP能否被宿主机访问能否访问外网典型用途NAT虚拟网段如 192.168.x.x需要端口转发依赖宿主机日常开发、上网桥接与宿主机同网段可以直接访问直接走物理网络需要被局域网其他机器访问仅主机虚拟网段无网关可以不能隔离测试NAT 模式下最常见的问题是 VMware 的 NAT Service 和 DHCP Service 这两个系统服务被停掉了——可能是系统更新后没自启也可能是安全软件清理启动项时误伤。症状很典型虚拟机里ip a显示网卡在但没有 IP手动sudo dhclient enp3s0能拿到地址重启就又没了。解决办法是去宿主机的服务列表里把这两个服务改成自动启动并手动拉起来。桥接模式的坑在桥接到哪块物理网卡。宿主机如果同时有有线和无线两块网卡VMware 默认可能选了无线那块而虚拟机的 DHCP 请求在无线网卡上经常会失败。手动在虚拟网络编辑器里把桥接目标指定成有线网卡问题就消失了。另外桥接模式下虚拟机拿到的 IP 跟宿主机同级如果宿主机所在的网络有准入控制新设备可能直接被拦下这种就不是配置问题得找网管加白名单。VirtualBox 除了模式之外还有一个专门的坑虚拟机的网络适配器设置里有两个勾选框——启用网络连接和连接方式旁边的高级项有时候虚拟机克隆之后 MAC 地址冲突就会表现为时通时不通。在高级设置里点一下刷新 MAC 地址重新生成一个通常就好了。3.2 双系统重启后断网Windows 快速启动留下的坑这台机器装的是 Windows 和 Ubuntu 双系统从 Windows 重启进 Ubuntu 之后没网再重启回 Windows 又好了——如果你遇到这个现象八成不是 Ubuntu 的问题。根因是 Windows 的快速启动和休眠。这两个功能关闭系统时并不会真正断电网卡处于一种半死不活的状态Windows 的驱动也没把设备彻底释放。Linux 启动时看到的是一块状态异常的网卡初始化就失败了。表现往往是网卡认得到但ip link set enp3s0 up之后依然不能收发数据dmesg里能看到一堆 reset 或者 firmware 相关的报错。处理办法有两步。第一步在 Windows 的电源选项里关掉启用快速启动并且养成从 Windows 用重启而不是关机再开机的习惯——重启会走完整的关机流程网卡能被正常释放。第二步如果关掉快速启动还是偶尔出现检查 Windows 网卡属性里允许计算机关闭此设备以节约电源这类节能选项把它取消勾选同时关掉网卡的唤醒功能。在 Linux 这一侧也可以加个保险把网卡的 Wake-on-LAN 关掉# 查看当前状态 sudo ethtool enp3s0 | grep -i wake # 关闭 wol sudo ethtool -s enp3s0 wol d这个设置不持久重启就没了想固化可以写成开机执行的脚本或者在 NetworkManager 连接配置里加ethernet.wake-on-lan: ignore。3.3 休眠唤醒、插拔网线和换网口之后的失联笔记本合盖休眠再打开网卡没了或者把网线从墙上的 A 口换到 B 口网络不通了。这两类都属于链路状态变化后没有正确重建。休眠唤醒的问题一部分是驱动本身的 bug一部分是 NetworkManager 在恢复时没有重新触发 DHCP。可以尝试在唤醒后手动把接口 down 再 upsudo ip link set enp3s0 down sudo ip link set enp3s0 up sudo dhclient -v enp3s0如果这招能恢复说明是自动重连逻辑的问题可以考虑换一个 NetworkManager 版本或者在/etc/NetworkManager/conf.d/下加配置调整重连行为。实测下来Intel 网卡在这方面的表现普遍比某些 Realtek 网卡稳笔记本如果是 r8169/r8168 系列驱动唤醒失联的概率会高一些可以试试换成官方提供的驱动包。换网口不通这件事更朴素如果是同一台交换机上的不同端口通常没事如果换到了不同网段的口那必须重新获取 DHCP因为原来的 IP 已经不属于新网段了。这时候sudo dhclient -r enp3s0 sudo dhclient enp3s0先释放再获取比干等 NetworkManager 自动发现要快得多。3.4 能 ping 通 IP 但打不开网页DNS 那一层的问题这是最经典的一类假断网。ping 223.5.5.5通ping www.baidu.com报名称解析暂时失败问题百分百在 DNS。Ubuntu 从 18.04 起默认用 systemd-resolved 做本地解析缓存/etc/resolv.conf通常是一个指向/run/systemd/resolve/stub-resolv.conf的软链接里面的地址是127.0.0.53——这是本地存根不是真实 DNS。很多人一看这个地址就以为配错了跑去手改/etc/resolv.conf重启之后被覆盖回来白折腾。正确的检查方式是看 resolved 的实际状态resolvectl status输出里会列出每个接口正在使用的 DNS 服务器。如果这里是空的说明 DHCP 没有下发 DNS或者 netplan 里没写nameservers。想让结果持久化就在 netplan 里加nameservers字段或者改/etc/systemd/resolved.conf里的DNS行然后重启systemd-resolved。还有一种更隐蔽的情况DNS 配置是对的但本机的/etc/hosts被人改乱了某个域名被硬编码到一个不存在的 IP表现就是只有这一个站点打不开其他都正常。这种时候cat /etc/hosts一定要看一眼。3.5 远程 SSH 突然连不上先别怪系统用 Xshell 或者终端连 Ubuntu 突然连不上很多人第一反应是服务器网络炸了实际上相当一部分情况是本地视角的问题。先确认服务本身在不在systemctl status ssh ss -tlnp | grep 22ss这条命令如果看不到 22 端口的监听那问题跟网络没关系是 sshd 没起来或者端口被改了。再看防火墙sudo ufw status verbose如果是虚拟机里的 Ubuntu还要考虑一层虚拟机的 IP 变了。DHCP 租约到期换地址是家常便饭昨天还是.128今天变成.131你拿着旧地址当然连不上。这也是为什么我建议开发机的 Ubuntu 一律配静态 IP省得天天猜地址。还有一种情况是宿主机上的虚拟网卡VMware 的 VMnet8、VirtualBox 的 Host-Only 适配器状态异常重新禁用再启用宿主机的这块虚拟网卡比折腾虚拟机里面的配置快得多。4. 一套可以照着敲的修复流程前面讲的都是判断思路这一节给一套可以直接执行的流程。目标很明确先让网络能通再让配置持久化最后做验证。4.1 应急三步先恢复上网再找原因当你什么都不知道、只想赶紧恢复的时候按这个顺序来。第一步看接口状态ip -br a如果目标接口是DOWN先拉起来sudo ip link set enp3s0 up第二步手动要一次 IPsudo dhclient -v enp3s0-v会打印详细过程你能看到它有没有收到 DHCP 回应、拿到了什么地址、网关和 DNS 分别是什么。如果这一步能拿到地址网络大概率立刻恢复至少能上网了。如果卡在DHCPDISCOVER一直没回应那就是二层或者虚拟网络层面的问题得回到上一节去查。第三步如果dhclient不管用重启管事的那个服务sudo systemctl restart NetworkManager # 或者 sudo systemctl restart systemd-networkd三步走完还不行再回头去看dmesg里网卡相关的报错方向就转向驱动和硬件了。4.2 用 netplan 写一份稳妥的静态 IP 配置临时恢复之后把配置固化下来才是一劳永逸。开发机、虚拟机、需要被其他机器访问的机器我都建议用静态 IP。编辑/etc/netplan/下的配置文件先确认文件名通常是01-network-manager-all.yaml或者50-cloud-init.yaml这类。改之前先备份sudo cp /etc/netplan/01-network-manager-all.yaml ~/netplan.bak然后按第 2 节里给的模板写。几个参数的选择依据说明一下IP 选在 DHCP 池之外比如路由器 DHCP 池是.100到.200那你就选.50这种掩码/24对应 255.255.255.0家用的场景基本都够网关填路由器地址不确定就用ip route看当前 DHCP 分下来的是哪个DNS 用223.5.5.5和114.114.114.114这两组国内公共地址稳定性和响应速度都够用。写完执行sudo chmod 600 /etc/netplan/01-network-manager-all.yaml sudo netplan generate sudo netplan try如果 120 秒内一切正常回车确认然后sudo netplan apply让它彻底生效。注意虚拟机里改静态 IP千万记得把 IP 选在虚拟机自己的虚拟网段里。VMware NAT 模式默认是192.168.x.0/24里的一段具体是多少在虚拟网络编辑器里看别凭感觉写。4.3 环境变量和配置文件写坏引发的假断网有一类故障特别容易被误判用户自己在/etc/environment、~/.bashrc、~/.profile里加了几行写错的环境变量导致某些命令的行为完全反常看起来像是网络问题。举个我实际遇到过的例子有人在~/.bashrc里 export 了一个指向本机不存在端口的地址结果所有走这个变量的命令行工具安装、下载全部失败报的是连接被拒绝。他以为是网络炸了折腾了一下午路由器最后发现是那行自己加的配置。判断方法很直接新开一个干净的 shell绕过所有配置文件试一下。env -i bash --noprofile --norc在这个干净环境里执行原来的命令如果成功那就说明是你的配置文件写坏了去检查最近改过的那几个文件。/etc/environment尤其要注意它不支持 shell 语法不能写export不能写变量引用写错会导致登录时环境异常。另外/etc/hosts、/etc/resolv.conf、/etc/nsswitch.conf这三个文件被改乱也会造成类似症状排查时顺手看一眼内容是否正常成本极低。4.4 内核升级后无线网卡驱动消失的处理这一条专门给笔记本用户。现象是更新完系统重启无线网卡直接不见了ip a里没有wlp开头的接口lspci能看到硬件但lspci -k后面没有Kernel driver in use这一行。原因通常是内核升级了但配套的模块包没跟上。Ubuntu 把一部分驱动拆在linux-modules-extra里如果你只升级了内核镜像没升级这个包驱动模块就缺失了。# 看当前内核版本 uname -r # 安装对应版本的额外模块包 sudo apt install linux-modules-extra-$(uname -r)装完重启网卡一般就回来了。如果你用的是第三方 DKMS 驱动比如某些无线网卡型号需要自己编译的驱动内核升级后还要重新构建dkms status sudo dkms autoinstalldkms status里显示installed但没显示当前内核版本就说明没构建成功需要重新装一遍。这类问题在升级内核之前就该有心理准备所以我的习惯是升级内核之前先确认手里有有线网或者手机 USB 共享网络可以用不然一旦无线驱动掉了连下驱动的路都没有。5. 疑难杂症排查实录常规问题讲完了剩下这些是我踩过或者帮别人解决过的非典型故障共同特点是现象迷惑性强容易把人带偏。5.1 网卡名变了配置全部失效Ubuntu 从某个版本开始使用可预测网卡命名网卡名从eth0变成了enp3s0、eno1这种。如果你的 netplan 配置里写的是eth0而系统实际叫enp3s0那配置会被静默忽略——不报错就是不生效网络当然不通。确认实际名称ip -br a ls /sys/class/net/把 netplan 里的接口名改成实际名称即可。还有一类情况是硬件变化后名字跟着变比如加了块 PCIe 网卡、换了插槽名字从enp3s0变成enp4s0。所以配置里写死的接口名在硬件变动之后要重新核对。如果确实想要回eth0这种传统命名可以在 GRUB 里加内核参数net.ifnames0 biosdevname0但我不建议这么做——改完之后所有老配置都得跟着改属于给自己找麻烦。用原名就行。5.2 rfkill 把无线网卡锁住了现象是无线网卡在驱动也在但就是搜不到任何 Wi-Fiip link set也起不来。这时候看这个rfkill list如果输出里有Soft blocked: yes或者Hard blocked: yes那问题就在这儿。Soft blocked是软件层面锁的可能是飞行模式开着或者某个按键组合触发了无线开关rfkill unblock allHard blocked: yes是硬件开关通常是笔记本上的物理无线开关或者某个 Fn 组合键软件解不开得物理操作。很多人在这一步卡很久因为不知道笔记本侧面还有个小拨片开关。另外如果rfkill list里压根没有无线设备那说明驱动没加载问题回到驱动那一层。5.3 MTU 和 IPv6 造成的能连但不通这一类故障是网络是通的但就是打不开某些东西。典型表现是ping小包没问题一到传输大文件、访问某些站点就卡住或者超时。MTU 不匹配是常见原因。路径中间某个环节的最大传输单元比本机设的小大包被丢弃又没有正确回 ICMP就会出现这种现象。探测方法是逐步用不同大小的包去 ping看从多大开始不通ping -M do -s 1472 223.5.5.5-M do表示不允许分片-s 1472加上 28 字节的头部正好是 1500。如果不通就往下调找到能通的边界再加上 28 就是这个路径实际支持的 MTU。把接口 MTU 调到这个值sudo ip link set dev enp3s0 mtu 1400另一个来源是 IPv6。某些环境下 IPv6 地址配下来了但实际不通系统又优先走 IPv6就会表现为访问缓慢或部分站点打不开。临时验证可以关掉 IPv6 试试如果关掉就正常了再考虑调整优先级而不是永久关闭。5.4 防火墙规则残留装过 Docker 或者用过一段时间 iptables 的机器iptables -t nat -L -n里可能残留一堆规则的链和转发规则某些规则会把流量导到已经不存在的接口或者网段表现就是部分流量有去无回。排查时先看规则sudo iptables -t nat -L -n -v sudo iptables -L -n -v如果确认是残留可以备份后清空再重建。但要特别小心Docker 依赖这些规则来工作直接iptables -F会把容器的网络一起干掉docker ps里容器还在跑但完全不通。稳妥的做法是先停 Docker 服务清理规则重启 Docker 让它自己重建。5.5 常见问题速查表把上面几节的结论汇总成一张表出问题的时候可以直接对着找。症状关键词可能原因处理动作是否需要重启只有 lo无其他接口驱动未加载装linux-modules-extramodprobe建议重启接口 DOWN网线、rfkill、虚拟网卡未连接ip link set up、rfkill unblock all否无 IPDHCP 失败、netplan 未生效dhclient -v、netplan try否ping IP 通、域名不通DNS 失效检查resolvectl status、netplan DNS否双系统从 Windows 切过来没网快速启动占用网卡关快速启动改用重启切换否休眠唤醒后失联重连逻辑异常接口 down/up 后重新 dhclient否SSH 连不上但本机能上网sshd 未启动或 IP 变了systemctl status ssh、核对当前 IP否容器内网络异常iptables 规则冲突停 Docker 后重建规则否内核升级后无线消失模块包未同步升级安装对应版本 modules-extra需要重启大文件传输卡死MTU 不匹配探测后调整接口 MTU否6. 我的避坑习惯与长期稳定建议修网络这件事效率高低主要不取决于你知道多少命令而取决于你动手之前有没有给自己留后路。这一节讲的都是习惯层面的东西看着不起眼但能省下大量时间。6.1 动网络配置之前必做的三件事第一件确认自己有第二条路能进这台机器。虚拟机就打开控制台窗口物理机就准备好显示器和键盘或者是 iLO、IPMI 这类带外管理。远程 SSH 改网络配置一旦断线又没有第二条路你就只能等人去现场。第二件备份当前可用的配置和状态。不只是备份 netplan 文件把ip a、ip route、resolvectl status的输出也存一份。恢复的时候有参照比凭记忆写靠谱得多。mkdir -p ~/net-debug ip a ~/net-debug/ip-a.txt ip route ~/net-debug/route.txt resolvectl status ~/net-debug/dns.txt lo 2/dev/null; cp /etc/netplan/*.yaml ~/net-debug/ 2/dev/null第三件优先用netplan try而不是netplan apply。这个前面说过但值得再说一遍因为这是远程操作唯一的自动兜底机制。6.2 备份、回滚与远程作业的保命操作如果非要在远程 SSH 会话里改网络我一般会开两个终端窗口一个用来操作另一个什么也不做只是保持着连接。配置改完如果两个窗口都还在说明没问题如果操作的那个断了、另一个还在说明只是新会话受影响还能抢救。更稳妥的做法是写一个定时回滚脚本在改配置之前启动它# 5 分钟后自动恢复备份的配置 sudo sh -c (sleep 300; cp ~/net-debug/01-network-manager-all.yaml /etc/netplan/; netplan apply) 改完确认没问题再把这个后台任务杀掉。这是在没有netplan try的场景下比如手动改 iptables的通用保命手法思路就是让系统自己在若干分钟后回到已知可用的状态。回滚的时候注意一点先把配置文件恢复再netplan apply顺序别弄反。如果先 apply 再恢复文件等于白白断一次网。6.3 几个让网络少出事的小调整第一个把版本号固定住。apt upgrade会把内核、NetworkManager、驱动一起升级出问题的概率成倍增加。生产或者长期使用的开发机我一般只做安全更新内核升级手动控制节奏并且升级前确认无线或有线有备用方案。第二个给无线网卡关掉省电。无线网卡的省电模式在某些路由器下会导致周期性掉线表现就是每隔十几分钟断一次又自动连上。可以在 NetworkManager 连接配置里把wifi.powersave设为 2禁用nmcli connection modify 你的WiFi名称 wifi.powersave 2 nmcli connection up 你的WiFi名称第三个记录变更。听起来很老派但我确实在~/net-debug/下留了一个changes.md每次改了网络相关的配置就记一行什么时候、改了什么、为什么改。半年后回头看很多莫名其妙的问题都能从里面找到线索。第四个知道哪些配置是改了就没的。/etc/resolv.conf在 systemd-resolved 启用时是软链接手改会在重启后失效ip、ethtool这些命令的修改都是临时的重启即还原。要持久化必须落到 netplan、NetworkManager 的 connection 配置或者 systemd 服务里。搞不清这一点就会出现我明明改了重启又坏了的死循环。最后分享一个小技巧如果你不确定某个故障到底是系统的问题还是网络环境的问题最快的验证方式是拿一台手机开热点用 USB 共享网络给这台 Ubuntu。如果 USB 共享能上网说明系统网络栈是好的问题在原来的网络环境或者那块网卡上如果 USB 共享也不通那基本可以确定是系统这边的问题直接往驱动和配置方向查。这个方法我用了很多次一次就能把排查范围砍掉一半。