企业官网建设流程全解析

"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 外网必然不通，问题在路由而不是 DNS；ping 223.5.5.5通但ping www.baidu.com不通，那就锁定在 DNS 层；nmcli device status里如果设备显示unmanaged，说明 NetworkManager 根本没接管这块网卡，你在 GUI 上怎么点都没用。

注意：排查阶段尽量别改配置，先把输出拍照或者复制到记事本里。修好之后回头对比，你才知道到底是哪一条变了。

1.3 症状对照速查表

把常见现象和第一嫌疑人对上号，能省掉一大半瞎试的时间。

表格里我特意把"本机能上网、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 status

nmcli 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 apply

netplan apply是一个"重活"，它会短暂中断网络。如果你是通过 SSH 远程操作，直接 apply 风险很大——配置一写错，你的连接立刻断，而且断完之后你再也连不回去，只能去机房或者虚拟机控制台。

提示：远程改网络配置时，一定用sudo netplan try。它会应用配置并启动一个 120 秒的倒计时，期间网络是通的，你确认没问题按回车，配置正式生效；如果你不按，或者配置把网络弄断了导致你连不上，120 秒后自动回滚到之前的配置。这个机制救过我至少三次。

3. 不同场景下的断网成因逐个拆解

同样是"突然没网"，场景不同，成因分布差异极大。把场景先确定下来，排查范围能瞬间缩小一半以上。

3.1 虚拟机断网：VMware 与 VirtualBox 的三种网络模式

虚拟机是 Ubuntu 断网求助里占比最高的一类。核心原因就一个：虚拟机的网络依赖于宿主机上的一层虚拟交换和 NAT 服务，这层服务比虚拟机本身脆弱得多。

VMware 和 VirtualBox 都提供三种主要模式，行为差异很大：

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 再 up：

sudo 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 22

ss这条命令如果看不到 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

第二步，手动要一次 IP：

sudo 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 autoinstall

dkms 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.ifnames=0 biosdevname=0，但我不建议这么做——改完之后所有老配置都得跟着改，属于给自己找麻烦。用原名就行。

5.2 rfkill 把无线网卡锁住了

现象是无线网卡在，驱动也在，但就是搜不到任何 Wi-Fi，ip link set也起不来。这时候看这个：

rfkill list

如果输出里有Soft blocked: yes或者Hard blocked: yes，那问题就在这儿。Soft blocked是软件层面锁的，可能是飞行模式开着，或者某个按键组合触发了无线开关：

rfkill unblock all

Hard 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 常见问题速查表

把上面几节的结论汇总成一张表，出问题的时候可以直接对着找。

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 共享也不通，那基本可以确定是系统这边的问题，直接往驱动和配置方向查。这个方法我用了很多次，一次就能把排查范围砍掉一半。