ubuntu20.04 是很多开发者、运维和实验室环境里最爱用的版本，但设置静态 IP 这件事，说简单是真简单，说恶心也是真恶心。尤其是刚从 Windows 或者更早的 Ubuntu 16.04 时代转过来的朋友，最容易在这上面栽跟头。因为从 Ubuntu 18.04 开始，系统默认把网络配置从/etc/network/interfaces换成了netplan这套基于 YAML 的工具，很多人还拿着老教程去改 interfaces 文件，改完systemctl restart networking，结果要么报错，要么 IP 压根不生效，甚至把 SSH 都给搞断。这篇文章就是要把这件事彻底讲透。我会从为什么要设置静态 IP 开始，再分析 netplan 这套配置体系的原理，然后手把手带你把 20.04 的静态 IP 配置好，最后再把我在真实环境中踩过的坑、排查过的故障全部列出来，做成速查表。不管你是刚装完系统需要固定地址，还是在虚拟机上折腾网络，或者管理一台远程服务器怕改配置连不上，这篇文章都能直接照着操作。
1. 为什么要设置静态 IP，动态分配会带来哪些麻烦
1.1 动态 IP 的隐患与静态 IP 的适用场景
绝大多数桌面版 Ubuntu 默认走 DHCP，也就是路由器自动分配地址。这个机制本身没毛病，笔记本需要在不同 WiFi 之间切换，手机需要随时随地拿地址，动态分配是最高效的。但一旦到了固定场景，动态 IP 就很麻烦。比如你有台机器专门跑着 Nginx 或者 MySQL，局域网里别的机器通过192.168.1.100这个地址连它，结果路由器租约一到期，IP 被重新分配成了192.168.1.105，所有依赖这个地址的连接全部断掉。再比如很多开发板、ARM 设备或者内网服务器，每次启动之后地址漂移，你连 SSH 都要先跑路由器后台看一眼当前分配到了什么，累不累？
需要静态 IP 的场景大概有这几类：一是局域网内的服务器、NAS、打印机，需要固定入口让其他设备稳定访问；二是SSH 远程登录的机器，地址一飘你就没法用ssh user@hostname这种方式快速连入；三是端口转发、内网穿透，你需要在路由器上把外网端口映射到内网某个固定地址，如果内网地址天天变，映射规则形同虚设；四是某些对网络敏感的服务，比如集群节点之间的通信、数据库主从同步、Docker 容器宿主机地址等，这些一旦地址漂移会导致整个服务不可用。
1.2 静态 IP 配置在 20.04 上的特殊性
Ubuntu 20.04 的静态 IP 配置路径和之前完全不同，这其实是很多人踩坑的第一道坎。在 18.04 之前，大家习惯了改/etc/network/interfaces，写下iface eth0 inet static然后指定地址、掩码、网关，重启网络服务就完事。但 18.04 之后的版本，系统引导阶段使用的网络配置工具变成了 netplan，它的配置文件放在/etc/netplan/目录下，后缀是.yaml。netplan 本身不是真正的网络管理软件，它更像一个转换层，负责把 YAML 配置转换成后端渲染器能识别的配置。20.04 默认的后端是NetworkManager（桌面版）或者systemd-networkd（服务器版），这个差异也导致同一个配置在不同版本上可能出现不同的行为表现。
一句话概括：在 20.04 上改静态 IP，核心操作就是写好 netplan 的 YAML 文件，然后应用。文件路径和写法就是成败的关键。
2. netplan 配置体系深度解析
2.1 netplan 工具与配置文件的完整概念
netplan 的概念其实不复杂，但很多人上来就改文件，改完发现不生效，就是因为没有搞清楚这套工具的完整工作流程。netplan 的配置路径是/etc/netplan/，这个目录下通常有一个.yaml文件，常见文件名有01-network-manager-all.yaml、00-installer-config.yaml或者50-cloud-init.yaml等等。具体文件名跟你安装系统的方式有关：桌面版安装器生成的文件叫01-network-manager-all.yaml，服务器版安装器生成的是00-installer-config.yaml，云镜像则会有50-cloud-init.yaml。
netplan 的核心流程是这样：你编辑 YAML 文件，然后执行sudo netplan apply，netplan 会通过netplan generate把 YAML 转换成后端渲染器（NetworkManager 或者 systemd-networkd）的配置格式，再通知后端重新加载配置。很多人只改文件不执行 apply，或者执行了sudo netplan try但没注意确认，这些都会导致白忙活一场。
YAML 文件的语法是这套体系的灵魂，也是最大的坑。YAML 对缩进极其敏感，空格数量和层级的任何错位都会导致解析失败。配置一个静态 IP，必需的元素有：网卡名称、DHCP 开关、IP 地址、网关、DNS 服务器。一个最小可用的配置长这样：
network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 8.8.8.8 - 223.5.5.52.2 逐个拆解配置项：IP、网关、DNS 的选择逻辑
很多人配置静态 IP 时只关注填了 IP，网关和 DNS 随便搞，结果内网能通、外网不通。这里我逐个字段说清楚。
首先是dhcp4: false，这个显式关掉 IPv4 的 DHCP。有些场景还会看到dhcp6，那是 IPv6 的开关，默认保持关闭或者自动即可，国内大多数场景用不到 IPv6 静态配置。然后是addresses，这里要特别注意写法：必须带 CIDR 前缀长度。192.168.1.100/24表示 IP 是192.168.1.100，掩码是255.255.255.0。很多人抄网上老教程，写成address: 192.168.1.100加netmask: 255.255.255.0这种格式，那是 interfaces 时代的写法，netplan 里完全不认，直接报错。
接着是routes，这个字段在 netplan 里负责定义路由。绝大多数家用路由器用192.168.1.1或192.168.0.1作为网关，但这不是固定的，一定要去路由器后台看清楚。曾经遇到过一个人把网关填成192.168.1.2，信誓旦旦说这是“路由器备用地址”，结果外网全不通。via就是网关地址，to: default表示这条是默认路由。如果你的网络环境比较复杂，可能需要多条静态路由，就在routes下列多个对象。
最后是nameservers。这里有个常见的误区：DNS 地址填成网关地址是可行的，但不一定靠谱。如果路由器自身的 DNS 转发能力不行，解析域名会非常慢。我的建议是填一个国内的可信 DNS 作为首要，比如223.5.5.5是阿里 DNS，119.29.29.29是腾讯 DNS，这两个在国内大部分网络环境下都很快。再填一个8.8.8.8作为备用，有些办公环境对海外访问有要求的话，备用地址能兜底。如果你是在企业内网，最好直接填写公司提供的 DNS 地址，否则解析内网域名会失败。
3. 实操：从零配置一个可用静态 IP
3.1 开始前必做的信息采集与备份
配置之前，先不要急着编辑文件。你手上必须有这几个信息：当前网卡的名称、当前网段、当前网关、当前 DNS、合法且未被占用的 IP 地址。怎么快速拿到这些？
打开终端，先跑一下ip addr或者ip a，查看当前的网络接口。我自己的机器上输出大概是这样的：
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.108/24 brd 192.168.1.255 scope global dynamic ens33注意看ens33这个名称，这就是当前活动网卡的名字。不同机器网卡名可能不同，常见的有eth0、ens33、enp0s3、wlan0（无线）。配置文件里必须写实际网卡名，写了不存在的名字，netplan apply会成功但实际什么都不生效，或者直接报网卡不存在。
然后跑ip route show查看默认网关：
default via 192.168.1.1 dev ens33 proto dhcp metric 100这里via后面的地址就是默认网关。最后查看 DNS，用systemd-resolve --status（20.04 上这个命令可能显示被弃用，但还能用）或者直接看/etc/resolv.conf：
cat /etc/resolv.conf拿到这些信息后，下一步是确定哪个静态 IP 可以用。最简单的办法是 ping 一下准备用的地址：
ping -c 2 192.168.1.100如果返回Destination Host Unreachable或者没有任何响应，说明这个地址当前没被占用的概率很大。但要注意，ping 不通不代表一定没人用，因为有些设备禁 ping。更保险的方法是去路由器后台看 DHCP 客户端列表，避开已经被分配的地址。
信息采集完成后，记得备份现有配置。这是几乎所有老手都会做的事，但很多人第一次操作时图省事跳过了。一行命令的事：
sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak这个备份会在事故排查时保命，因为没有比手忙脚乱恢复现场更痛苦的事了。
3.2 三种常见场景下的静态 IP 配置写法
这里我把三个最常用的场景分开写清楚：
场景一：Ubuntu Server（无桌面环境）或者虚拟机服务器版
服务器版最常见的配置文件是/etc/netplan/00-installer-config.yaml。如果你装系统时已经配置过网络，这个文件里可能已经有 DHCP 的内容，也可能直接是空的。一个完整的静态 IP 配置如下：
network: ethernets: ens33: addresses: - 192.168.1.100/24 dhcp4: false nameservers: addresses: - 223.5.5.5 - 8.8.8.8 routes: - to: default via: 192.168.1.1 version: 2场景二：Ubuntu Desktop（带桌面环境）
桌面版默认的01-network-manager-all.yaml内容非常精简，通常只有两行：
network: version: 2 renderer: NetworkManager你可以直接在原有ethernets下增加配置，关键是要保留renderer: NetworkManager。修改后的完整版：
network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 8.8.8.8场景三：无线网络（WiFi）
无线网卡的静态配置稍微有些区别，需要用到wifis字段而不是ethernets，同时需要在网络层下面配置接入点信息：
network: version: 2 wifis: wlan0: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 access-points: "你的WiFi名称": password: "你的WiFi密码"无线静态配置比有线更常出问题，因为无线网卡的驱动和网络管理器的配合情况各不相同，很多情况下即使配置写对了，也可能因为 wpa_supplicant 的问题导致连不上。如果你不是特别必要，无线设备建议用 DHCP 保留（路由器里绑定 MAC 地址和 IP），而不是在系统里硬配。这个在最后一部分会细说。
3.3 应用配置的正确姿势与验证清单
文件编辑完成之后，最关键的一步来了：应用配置。这里有几个不同的命令，各自用途不同，千万别搞混。
sudo netplan try是最安全的命令，它会先应用配置，然后给你 120 秒的确认窗口。在这段时间里如果配置有问题导致网络断开，你可以按回车回滚，或者等超时后自动恢复旧配置。这个命令非常适合远程 SSH 操作时使用，因为即使你把网络配崩了，它也能自动回到原来的状态。唯一要注意的是，执行这个命令后终端会卡住等你确认，有时候 SSH 连接断了你还没来得及按回车，要耐心等 120 秒超时。
sudo netplan apply是直接应用配置，没有任何回退机制。如果你确定配置没问题，用这个更快。但远程操作时，如果你不放心，建议先执行sudo netplan try确认无误后再用 apply。
还有一种情况需要注意：如果服务器上有cloud-init这个服务管理系统网络，它可能会在启动时覆盖你写的 netplan 配置。在 20.04 的云镜像上这是非常常见的问题。处理方法是在/etc/netplan/下新建一个文件，比如99-custom.yaml，在这个文件里写配置。netplan 会按文件名排序加载，编号越大的文件优先级越高，99-开头的文件能覆盖掉50-cloud-init.yaml的配置。
配置应用之后，不要急着关机或者做别的事，按下面几个命令验证一下：
ip addr show ens33确认inet后面已经是你配置的静态地址。然后用ip route show确认默认网关正确。接着ping -c 4 192.168.1.1测试网关连通性，ping -c 4 223.5.5.5测试外网连通性，最后nslookup www.baidu.com测试 DNS 解析是否正常。这四步全部通过，配置才算真正成功。
4. 我踩过的坑：排查实录与修复方法
4.1 最常见的“配置生效失败”大集合
静态 IP 配置的报错和异常现象五花八门，但归结起来无非就那几类。我把最经典的几个拿出来逐个分析。
坑一：netplan apply报错Invalid YAML
这是频率最高的问题，几乎全是缩进错误导致。YAML 严格要求缩进，不能用 Tab 键，必须用空格。很多人从网页复制配置到终端，或者手打时不小心按了 Tab，必然报错。处理办法是执行：
sudo netplan generate这个命令只做解析和转换，不实际应用。如果 YAML 写错了，它会明确告诉你第几行出错。最常见的错误是addresses下面列表项没有对齐，或者是routes下面漏了缩进。还有一个容易踩的小坑：YAML 文件末尾必须保留一个空行，有些编辑器会自动去掉这个空行，导致解析失败。
坑二：配置后能 ping 通 IP，但 ping 不通外部域名
这个现象说明静态 IP 本身没问题，是 DNS 或者网关配置有问题。先ping -c 4 223.5.5.5，如果通了，说明网关和路由没问题，纯粹是 DNS 设置不对；如果不通，先ping -c 4 192.168.1.1，网关不通就得检查routes的via地址是不是填错了。我见过最无语的情况是有人把网关填成了192.168.1.100——他自己的 IP，等于把包发给了自己，自然出不去。DNS 问题通常就是 nameservers 里填的地址本身不可达，可以临时用ping测试 DNS 地址是否能通。
坑三：虚拟机里设置了静态 IP，但主机连不上虚拟机
这个多半是虚拟机网络模式的问题。VirtualBox、VMware 里常见的网络模式有 NAT、桥接、仅主机。如果是 NAT 模式，虚拟机对外是一个独立的 NAT 网络，宿主机能不能访问要看 NAT 端口转发和防火墙规则，和静态 IP 没有直接关系。如果要用静态 IP 让宿主机稳定访问，建议把虚拟机网卡设置成桥接模式，这样虚拟机直接拿到局域网里的地址。在 VMware 里，桥接模式还要注意选择“复制物理网络连接状态”，否则虚拟机从休眠恢复之后可能断网。另外，VMware 安装 Ubuntu 后默认的网卡名可能是ens33而不是eth0，这个上面说过了，配置里一定写实际的名称。
坑四：配置没问题，但重启后静态 IP 丢失，又变回 DHCP
这个现象在桌面版尤其常见。原因往往是 netplan 配置里缺失renderer声明，或者声明成了systemd-networkd但桌面环境实际用的是 NetworkManager，两者冲突导致 NetworkManager 把 netplan 的配置覆盖了。解决方法是确认配置里有renderer: NetworkManager，而且不要多个 netplan 文件互相冲突。你可以用ls /etc/netplan/看一下有没有多个 YAML 文件，如果有，得确保它们之间没有互相矛盾的配置。
4.2 远程服务器配置静态 IP 必须掌握的“逃生门”
远程服务器的静态 IP 配置是高风险操作。你人在家里，服务器在机房，配置写错了，重启网络之后 SSH 断掉，你就再也连不上了。除非你有 IPMI 或者带外管理口，否则只能去机房搬服务器。我自己的经验是，远程配置一定要用下面这套流程，一次都没翻过车。核心思路是：不要先改配置文件再 restart，而是利用netplan try的超时回滚机制。
具体操作：先把配置写进 YAML 文件，但不要立刻apply。先执行sudo netplan try，这会在 120 秒内应用新配置。如果一切正常，你的 SSH 连接不会断，网络也不会挂，这时按回车确认。如果配置有问题导致网络中断，SSH 会卡住，不要慌，等 120 秒超时后系统自动回滚到旧配置，网络恢复后重新连 SSH 检查问题。
另一个更保险的做法是准备一个定时回滚脚本。如果netplan try超时后依旧无法恢复，可能是因为某些特殊配置导致系统自动回滚也失效了。这时候可以在配置应用前，用crontab加一个 5 分钟后执行的脚本，把备份的 YAML 文件恢复到原位置，然后执行netplan apply。如果 5 分钟内你没主动取消任务，脚本就会悄悄帮你把网络恢复原状。这个技巧是运维老手们偷偷在用的“保险丝”，虽然笨，但非常管用。
4.3 其他容易让人崩溃的疑难杂症
除了上面几个高频坑，还有一些低频但遇到就极其折磨人的问题。
症状：配置文件完全正确，但 apply 后网络服务报错，systemctl status systemd-networkd显示失败。
这种情况通常不是配置问题，而是系统里同时存在多个网络管理工具互相打架。在服务器版上，systemd-networkd和 NetworkManager 共存时，有时netplan apply会触发两个服务同时操作网络接口，导致冲突。解决办法是禁用其中一个。服务器版一般建议用 systemd-networkd，所以可以执行：
sudo systemctl stop NetworkManager sudo systemctl disable NetworkManager然后再sudo netplan apply。
症状：同一个配置文件，在实体机上没问题，但是在某台特定服务器上就是不生效。
排查到这一步就要怀疑是不是固件或者驱动层面的问题了。某些服务器板载网卡使用特殊的驱动（比如 Realtek 的 8168 系列），netplan 配置好后系统不会自动加载正确的驱动参数，导致网卡无法正常工作。这种情况下，先跑lspci | grep -i ethernet查看网卡型号，然后搜索该网卡在 Linux 下的驱动支持情况。必要时需要安装驱动或调整内核参数。不过这种事在 20.04 上已经不常发生了，大多数主流网卡内核都直接支持。
症状：从休眠或者挂起恢复后，静态 IP 变成了 169.254.x.x。
以169.254开头的地址是 APIPA 自动私有地址，说明网卡在唤醒后没有成功获取到有效网络配置。这通常涉及 NetworkManager 的管理策略。把 NM 的“自动连接”和“用户权限”改一下可以缓解，但最保险的方案是直接在/etc/netplan/下把接口的配置改为critical: true，这个参数告诉系统该接口是“关键接口”，唤醒时优先处理。
5. 不同场景的更优解：DHCP 静态绑定与静态度量的比较
5.1 路由器 DHCP 静态绑定方案
静态 IP 的配置不止有系统内一种做法。很多时候，尤其是局域网内设备数量较多时，直接在路由器后台做DHCP 静态绑定比在每台设备上修改静态 IP 更优雅、更稳妥。原理很简单：路由器在分配 DHCP 地址时，会按照 MAC 地址和 IP 的绑定表来分配固定地址。你在路由器后台把某台设备的 MAC 地址和一个 IP 绑定，它每次连接网络都会拿到同一个 IP，跟静态配置效果一样，但是这个 IP 依然是 DHCP 分配的，不会被其他设备抢走，也不会因为系统配置失误导致断网。
什么时候用这个方案？如果你的设备是无线连接，或者设备需要经常在不同网络之间切换，或者你不想维护每台机器的配置文件，直接用 DHCP 绑定最省心。尤其是树莓派、智能家居网关这类设备，用绑定方案基本一劳永逸。缺点也很明显：你必须在路由器后台操作，如果路由器不带这个功能（一些运营商赠送的光猫就没有），那还是老老实实去系统里设置。
5.2 两种方案的取舍逻辑与推荐
系统内静态 IP 和路由器 DHCP 绑定，不是替代关系，是互补关系。我的建议很简单：服务器、虚拟机、需要固定出口的机器，用系统内静态 IP；笔记本、手机、平板、智能设备，用 DHCP 绑定。前者的优势是不依赖路由器，配置跟着机器走，换一个网络环境只要配置对就能用，但劣势是需要维护每台机器的配置文件，而且如果管理不规范，很容易出现 IP 冲突——两台机器手滑配了同一个 IP，网络直接瘫痪。后者的优势是集中管理，IP 冲突几乎不会发生，配置改起来也方便，但劣势是依赖路由器，一旦路由器坏了或者被重置，绑定关系就全丢了。
实际使用中，我自己是混着用的。家里的 NAS 和服务器用系统内静态 IP，因为这些机器上跑的服务依赖固定的本机地址；虚拟机用路由器 DHCP 绑定，因为虚拟机经常被快照回滚，绑定在路由器上更稳定；开发板用 DHCP 绑定，省得每次烧录系统后都要重新配置。这套组合拳打下来，基本告别了“IP 又变了”这类问题。
5.3 给新手的配置建议：虚拟机上练习最安全
如果你是第一次接触 Linux 网络配置，建议先在虚拟机上练手。VMware 或者 VirtualBox 装一个 Ubuntu 20.04，快照一个干净的系统状态，然后随便折腾。配置写错了，直接回滚快照，比在实体机上反复重装系统效率高太多了。特别是虚拟机的网卡模式，你可以把虚拟机设成 NAT、桥接、仅主机三种模式分别试试，感受一下不同模式下静态 IP 的配置差异。这个练习做完，你对 Linux 网络栈的理解会上升一个台阶。树莓派之类的 ARM 开发板也适合用来练习，毕竟 SD 卡坏了重刷系统也就几分钟的事。但不管用什么机器练，都要养成先备份配置文件、再动手修改的习惯。
6. 配置之后：验证、持久化与日常管理小技巧
6.1 配置应用后的完整验证流程
很多人配完静态 IP，ping 通网关就以为完事了，其实还差得远。完整的验证要分四步走。
第一步验证链路层，执行ip link show ens33，确认网卡state UP，没有被禁用。第二步验证 IP 层，执行ip addr show ens33，确认地址、掩码准确无误，同时确认没有滞留的 DHCP 地址。第三步验证路由层，执行ip route show，确保默认路由default via指向正确的网关。第四步验证 DNS 和业务层，ping 网关、ping 外网 IP、nslookup 域名三步走完才算完整。如果这些都没问题，最后再做一个波动测试：重启网络服务，或者重启整个系统，确认重启后静态 IP 还在。这一步非常关键，因为有些配置静态 IP 生效了，但重启后失效，这种情况多半是配置文件的加载顺序或者多个配置文件冲突导致的。
6.2 netplan 文件模板与快速参考
为了让你以后配置更加顺手，我把常用配置整理成一个速查模板。下面这份可以直接复制修改用：
network: version: 2 renderer: systemd-networkd ethernets: ens33: dhcp4: false dhcp6: false accept-ra: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 119.29.29.29 search: - home.lan注意模板里加了一个search字段，这叫“搜索域”，当你访问server1这种短域名时，系统会把server1自动展开成server1.home.lan。内网有自建域名服务的话这个字段很实用。另外我还加了accept-ra: false，这个参数是关掉 IPv6 路由通告。在部分路由器上，IPv6 的 RA 消息会干扰纯 IPv4 的静态配置，导致路由表异常。不是所有环境都需要这个参数，但如果你配置完出现诡异的路由问题，可以试着加上它。
6.3 多网卡多 IP、临时 IP 等进阶配置思路
单网卡配单 IP 是基础操作，实际生产环境里还经常遇到更复杂的场景。比如一台机器有两块网卡，一块连内网，一块连外网，这种场景要在 netplan 里分别给两块网卡配不同网段的 IP。配置的关键是路由策略：默认路由只能有一条，你要根据访问目标来指定走哪个网卡。比如内网网卡ens33是192.168.1.0/24网段，外网网卡ens34是10.0.0.0/24网段，那么配置ens34这块卡时，不能给它设置default路由，而要设置走到10.0.0.0/24网段的静态路由。一旦两块网卡都写了to: default，系统只会用其中一条，另外一块网卡的默认路由会被自动丢弃，网络行为就会变得非常诡异。
还有一个实用技巧：临时给网卡加一个 IP，不想写死在配置文件里，可以用ip addr add 192.168.1.200/24 dev ens33。但这种地址重启后就会丢失。临时 IP 适合排查故障时做测试，比如怀疑某个 IP 被占用，可以先临时加上另一个测试地址来验证网络是否通，确认问题后把临时地址删掉。这种即时、不影响已有配置的方式，在生产环境里特别有用。
6.4 配置出现问题时的“三步恢复法”
最后放一个不管什么环境都适用的恢复流程。当网络配置被搞崩了，尤其是远程连接断开时，请按这个顺序操作。
第一步，如果还能操作（比如本机操作或者有 IPMI），立即执行sudo netplan revert。这个命令会回滚到最近一次成功应用的配置。第二步，如果revert不可用或者没有生效，尝试手动恢复备份文件。之前的备份在这里就发挥价值了：把.bak文件复制回去，然后sudo netplan apply。第三步，如果前面两步都失败，那就只能通过重启系统进入恢复模式，或者从 Live USB 启动后挂载硬盘修改配置文件。这个三步走下来，基本任何配置层面的问题都能解决。唯一要注意的是，如果问题出在网线、交换机、路由器这些硬件设备上，那再多的软件配置技巧都没用，该查硬件就查硬件，别在一个方向上死磕。
我在实际配置 Ubuntu 20.04 静态 IP 的过程中，最有感触的一点是：网络配置本身不难，真正难的是理解它背后那套“配置后生效、重启后保持、异常时回滚”的完整逻辑。netplan 这套工具虽然初期学习曲线有点陡，但一旦理解它的工作方式，后续不管遇到什么网络配置需求，都能举一反三。如果你配置之后还有拿不准的地方，别急着反复重启，先执行journalctl -u systemd-networkd看看系统日志，报错信息会直接告诉问题出在哪里。网络排障本来就是一件按图索骥的事，把排查顺序理顺了，大多数问题都能迎刃而解。
