Ubuntu 20.04 网络配置实战：Netplan 静态 IP 设置与故障排查

如果你刚装完 Ubuntu 20.04，想把网卡从自动获取改成固定 IP，翻遍系统却没有方向——顺手打开 /etc/network/interfaces，文件明明还在，内容也眼熟，可改完重启网络服务，系统提示这个服务根本不存在，网络纹丝不动。这不是你操作的问题，也不是不够细心，而是从 Ubuntu 18.04 开始，默认网络配置体系已经换成了 Netplan，老教程里的改法在 20.04 上基本失效。

这篇内容围绕 Ubuntu 20.04 的网络配置完整链路展开，目标是帮你把“从 IP 设置到连接外网”这条路上的关键节点全部打通：找到当前系统真正生效的配置文件、写对静态 IP 和网关、配好 DNS，最后通过命令验证外网连通性。适合刚转到 Ubuntu 20.04 的桌面用户、在虚拟机里折腾网络实验的开发者，以及第一次给 Ubuntu 服务器做固定 IP 规划的运维新手。文中所有步骤都在 Ubuntu 20.04 桌面版和服务器版上实测过，多数场景可以直接照抄。

1. 为什么 Ubuntu 20.04 的网络配置不能照着老教程抄

先聊一个很多人忽略的事实：Ubuntu 的网卡配置方式在 18.04 版本经历了一次结构性切换，20.04 完全继承了新方案。之前大家熟悉的 /etc/network/interfaces、ifupdown 工具链在 18.04 之后不再是默认配置入口，取而代之的是 Netplan。Netplan 用 YAML 文件统一描述网络接口、IP 地址、网关、DNS，然后把配置翻译给底层的 systemd-networkd 或 NetworkManager。换句话说，你写配置的对象已经变了，再去找旧文件当然处处碰壁。

1.1 配置入口与工具链的变化

我见过不少从 CentOS 7 或者其他 Linux 发行版转过来的朋友，第一反应是去编辑 /etc/network/interfaces，然后执行 service networking restart。在 Ubuntu 20.04 上，这套操作大概率得到两个结果：一是修改根本不生效，二是提示 networking.service 不存在。原因是系统里连 ifupdown 都没默认安装，Netplan 生成的配置会直接覆盖底层行为，你再怎么改 interfaces 都不会被理会。

新旧两代配置方式的差异，用一张表能看得很清楚：

这个切换不是 Ubuntu 拍脑袋决定的，而是老方案的痛点太多：多个网卡配置分散、重启服务时容易导致断连、与 NetworkManager 之间经常打架。Netplan 的思路是把所有网络接口配置收拢到统一的 YAML 描述层，再由一个“渲染器”去执行，配置管理上清晰很多。代价就是新手第一次接触时完全摸不到入口。

1.2 先搞清楚你的系统用谁做渲染器

Netplan 本身不直接配置网卡，它只是个“翻译官”，真正干活的是渲染器。桌面版和服务器版的默认渲染器并不一样，这是很多教程没讲清楚的地方。

• 桌面版 Ubuntu 20.04 默认使用 NetworkManager 作为渲染器，配置文件的文件名通常叫 /etc/netplan/01-network-manager-all.yaml。
• 服务器版默认使用 systemd-networkd，安装时生成的配置文件常见为 /etc/netplan/00-installer-config.yaml 或 /etc/netplan/50-cloud-init.yaml。

判断当前系统的渲染器很简单，直接看现有 Netplan 文件里 renderer: 后面的值就行。如果文件里只写了 network: {version: 2} 没有明确指定渲染器，可以用 ps -p 1 -o comm= 看 PID 1 是 systemd 还是别的，再配合 systemctl status NetworkManager 这样几个命令确认。

这个区别直接决定了你后面修改的方式。桌面版如果由 NetworkManager 管理，你完全可以直接用图形界面或 nmtui 改；服务器版由 systemd-networkd 托管，就必须确保 YAML 文件写法正确且能通过 netplan generate 的语法校验。

2. 动手前先读透 Netplan 配置文件的写法

很多网络问题不是网络本身的问题，而是 YAML 写错了。Netplan 对缩进极其敏感，不允许使用 Tab，冒号后面必须有空格，列表项的缩进错一行，整个配置就应用不了。所以动手之前，先把 Netplan 文件的结构吃透。

2.1 从一份最小 DHCP 配置看起

服务器版安装完成后，默认的 /etc/netplan/00-installer-config.yaml 内容大致是这样：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: true

这里 version: 2 是 Netplan 的配置格式版本，照写即可。ethernets 下面定义的是物理网卡接口，ens160 是网卡名，dhcp4: true 表示这个接口通过 DHCP 自动获取 IPv4 地址。

在实际系统里，网卡名不一定叫 ens160，可能是 enp0s3、eno1、ens33，甚至是 eth0。查看当前机器真实网卡名用：

bash复制ip addr show

输出中 2: ens160: 这类标号就是网卡名。如果接口处于 DOWN 状态，还需要注意状态列是不是 UP，否则要先启用接口。

2.2 静态 IP、DHCP、DHCP 加静态 DNS 的三种常见写法

需要设置固定 IP 时，最常见的配置是下面这种：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: false
      addresses:
        - 192.168.31.120/24
      routes:
        - to: default
          via: 192.168.31.1
      nameservers:
        addresses:
          - 223.5.5.5
          - 119.29.29.29

192.168.31.120/24 是带前缀长度的 IP 写法，等效于传统写法里的 192.168.31.120 加子网掩码 255.255.255.0。想要等宽子网就用 /24，局域网是这个规模的九成以上都能直接套。

routes 段落里定义默认路由，这是网关的现代写法。早一点的 Netplan 版本支持 gateway4: 192.168.31.1 这种简化写法，但新版里已经标记为废弃，继续用会看到 deprecation warning，建议直接写 routes，兼容性更好。nameservers 里配置 DNS 服务器，按需填。

还有一种常见需求是：IP 需要 DHCP 自动获取，但 DNS 想手动指定，避免拿到路由器下发的不可用 DNS。写法和上面不同：

yaml复制network:
  version: 2
  ethernets:
    ens160:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 223.5.5.5
          - 119.29.29.29

这种“半自动”模式在办公网或路由器 DHCP 服务不稳定的场景下非常实用，可以避免反复修改。

2.3 多配置文件时的合并规则与网卡匹配写法

/etc/netplan/ 目录下可以同时存在多个 YAML 文件，Netplan 会把它们合并成一份完整配置。文件名前缀的数字决定加载顺序，比如 01-network-manager-all.yaml 会先于 99-custom.yaml 被读取。同一个属性如果多个文件都定义了，后加载的文件不会覆盖先加载的文件，而是可能导致冲突报错。

实际运维中，我习惯把自定义配置单独放在一个新文件里，比如 99-static-ip.yaml，而不是去改系统安装时生成的文件。这样系统升级或重新生成配置文件时不会把你手动配的内容冲掉。

网卡名段的写法也支持通配符。如果机器可能插多块网卡，名字不确定，可以用 en* 或 eth* 匹配一类接口。但我不建议在生产环境滥用通配符，否则容易同时匹配到多块网卡导致配置张冠李戴。最好是先 ip link 看清网卡名，再写具体名称。

3. 服务器固定 IP 配置实操：从查询网卡到外网连通

理论讲完，下面是完整实操。假设场景很常见：一台 Ubuntu 20.04 服务器，安装时用 DHCP 拿到了一个动态地址，现在需要把它改成固定 IP，并保证重启后依然生效、能正常访问外网。这类操作需要谨慎，尤其是远程 SSH 登录时，一旦写错 IP 或网关，可能直接把自己锁在机器外面。

3.1 先摸清当前网络现状

改配置之前，先收集三类信息：网卡名、当前 IP 段、网关地址。

bash复制ip addr show
ip route show

假设输出内容类似下面这样：

text复制2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.31.99/24 brd 192.168.31.255 scope global dynamic ens160

说明当前网卡叫 ens160，系统通过 DHCP 拿到了 192.168.31.99/24 这个地址。继续看路由：

text复制default via 192.168.31.1 dev ens160 proto dhcp metric 100

网关是 192.168.31.1。这时我们已经知道目标网段是 192.168.31.0/24，网关是 192.168.31.1。接下来只要在同一个网段里挑一个没被占用的固定地址就行，我这里选择 192.168.31.120 作为演示。

3.2 备份并编写 Netplan 配置

修改任何配置文件前都要先做好备份，网络配置尤其如此：

bash复制sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak

然后编辑配置文件：

bash复制sudo vim /etc/netplan/00-installer-config.yaml

把内容改为：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: false
      addresses:
        - 192.168.31.120/24
      routes:
        - to: default
          via: 192.168.31.1
      nameservers:
        addresses:
          - 223.5.5.5
          - 119.29.29.29

这里我特意把 renderer 明确写成 networkd，因为这是服务器版安装时的默认渲染器。如果你不确定自己的系统是不是 networkd，先看回第 1 章判断渲染器的方法。如果是 NetworkManager 渲染的，这里改成 renderer: NetworkManager 也可以，但更稳妥的做法是保留安装时的默认值，只修改网卡和 IP 部分。

3.3 应用配置的正确姿态：try 优先于 apply

应用配置前，最重要的一件事：如果你是 SSH 远程操作的，请务必优先使用 netplan try，而不是直接 netplan apply。

bash复制sudo netplan try

执行后系统会应用新配置，并等待你按回车确认。如果配置有问题，或者你把自己弄断网了，超时后会自动回滚到之前的可用配置。这一招在远程服务器上堪称救命稻草，等于给网络配置加了一层保险。如果是本地有显示器的机器，可以放心用 sudo netplan apply，但要留意终端输出的错误信息。

配置应用成功后，验证顺序应该由近到远：

bash复制ip addr show ens160
ip route show
ping -c 3 192.168.31.1
ping -c 3 223.5.5.5
ping -c 3 baidu.com

• ip addr show ens160 确认网卡是否已经绑定了 192.168.31.120。
• ip route show 确认默认路由存在，且 via 192.168.31.1。
• ping 网关 验证局域网链路通不通。
• ping 223.5.5.5 验证三层路由能否访问外网 IP。
• ping baidu.com 验证 DNS 解析是否正常、外网域名能否访问。

如果走到 ping baidu.com 这一步提示未知主机名，说明 IP 和路由都没问题，是 DNS 配置出错了，继续看下一章的排查链路。

4. 连不上外网时的排查链路：从物理层到 DNS 逐层定位

配置写完发现外网不通，是每个折腾网络的人都会遇到的事。我不喜欢靠猜，更习惯按“物理层 → 链路层 → 网络层 → DNS 层”的顺序逐层排查。这里整理几条最常见的故障链路，你可以直接对照现象排查。

4.1 网关 ping 不通：先查网卡状态和地址段

如果 ping 192.168.31.1 直接超时，优先做三件事：

第一，确认网卡 UP：

bash复制ip link show ens160

如果状态不是 UP，执行 sudo ip link set ens160 up 先启用接口。很多情况下 Netplan 配置没问题，但网卡没被激活，后续一切免谈。

第二，确认 IP 与网关在同一个网段。比如你把静态 IP 写成了 192.168.1.120/24，网关却填了 192.168.31.1，两者不在同一广播域，ARP 永远找不到网关的 MAC 地址，自然 ping 不通。这个问题在配置里最容易犯，写完后对比一次 addresses 和 via 的网段是否一致即可。

第三，确认没有别的进程抢占或禁用接口。桌面版如果同时开了 NetworkManager 又用 networkd 渲染器，可能出现接口被 NetworkManager 接管、导致 Netplan 配置失效的怪现象。检查方式：

bash复制nmcli dev status

如果网卡状态显示为 unmanaged，说明 NetworkManager 主动放过了这个接口，交由 systemd-networkd 管理，这种状态反而是符合预期的。如果显示 connected，说明它正在被 NetworkManager 管理。

4.2 网关通但域名不通：先解析再换 DNS

经常遇到的现象是 ping 223.5.5.5 通，但 ping baidu.com 报 ping: baidu.com: Temporary failure in name resolution。这说明 IP 层没问题，故障点在 DNS。

Ubuntu 20.04 默认由 systemd-resolved 管理 DNS，/etc/resolv.conf 其实是一个指向 /run/systemd/resolve/stub-resolv.conf 的软链接。所以网上流传的“直接编辑 /etc/resolv.conf 写 nameserver”在 20.04 上效果非常有限，重启或重新应用网络配置后就会被覆盖。正确的修改姿势只有两个：要么改 Netplan 文件里的 nameservers，要么用 resolvectl 临时设置。

查看系统当前实际生效的 DNS：

bash复制resolvectl status

排查时建议先手动指定一个可靠的公共 DNS 测试，比如 223.5.5.5 和 119.29.29.29，确认能正常解析后再考虑是不是上游 DNS 真的有问题。

4.3 默认路由缺失或多条路由冲突

还有一种很迷惑的情况：IP 配好了、DNS 也对，但外网就是不通，连 223.5.5.5 都超时。这时基本可以断定默认路由出了问题。

bash复制ip route show

如果输出里没有 default via 192.168.31.1 dev ens160，或者默认路由指向了一个不存在的网关，外网自然不可达。导致默认路由消失的原因，常见的是 YAML 里 routes: 段写错、via 地址填错、或者配置文件没有成功应用。

如果机器插了多块网卡，且每块都启用了 DHCP，系统可能拿到多个默认路由，数据包走错出口也是常事。处理办法是显式给某个接口配置 metric 值控制优先级，或者让内网网卡不要获取默认路由。

5. 虚拟机和 Docker 环境里的高频“假故障”

很多朋友是在虚拟机里装 Ubuntu 20.04 练手，遇到网络问题会怀疑自己配置错了，但实际有一大半是虚拟机网络模式和 Docker 的锅。这两个场景都与宿主机网络模式强相关，值得单独拿出来聊。

5.1 虚拟机克隆后网卡失效的根因与修复

VMware 或 VirtualBox 里克隆一台 Ubuntu 20.04 虚拟机，开机后经常发现网卡没有 IP，ip link 看到的网卡名也变了，比如从 ens160 变成了 ens224。根因很简单：克隆出来的新机器沿用了原系统的 Netplan 配置，但配置里写入的是旧网卡名，新环境里网卡名称不匹配，DHCP 和静态配置都不会被应用。

修复方式很直接，先看到当前实际网卡名：

bash复制ip link show

再把 /etc/netplan/ 下配置文件里的接口名改成新看到的名称，然后 sudo netplan apply。如果希望以后克隆不再出这个问题，可以把配置里的接口名改写成通配符形式。

5.2 桥接与 NAT 模式下静态 IP 的地址段差异

虚拟机网络模式选错，引发的现象是：虚拟机网络时通时不通，或者配置静态 IP 之后宿主机能访问、虚拟机却上不了外网。

三种常用模式的地址规律要记牢：

NAT 模式下想设置静态 IP，必须和该模式的网段保持一致，网关也要填对应值。桥接模式下则要看成宿主机网段相同、网关一致，但如果所在局域网没有 DHCP 服务器，就老老实实手动配一个没被占用的同网段地址。

5.3 宿主机网络配置是怎么影响 Docker 容器的

如果你在同一台 Ubuntu 20.04 上跑 Docker，宿主机网络配置出错时，容器同样会遭殃。Docker 默认创建的 docker0 网桥使用 172.17.0.0/16 网段，并通过 iptables NAT 让容器访问外网。这一整套链路依赖两个宿主机的底层能力：一是 ip_forward 转发开关，二是宿主机本身能正常访问外网。

如果宿主机配了静态 IP 后外网不通，容器大概率也跟着不通，报错往往表现为 docker pull 超时。排查时先保证宿主机能 ping 通外网域名，再检查：

bash复制sysctl net.ipv4.ip_forward

输出为 1 是正常的。如果为 0，临时开启用 sudo sysctl -w net.ipv4.ip_forward=1，永久开启则编辑 /etc/sysctl.conf。还需要注意自定义网桥网段不要和宿主机现有局域网段冲突，比如某办公网恰好使用了 172.17.0.0/16，Docker 默认网桥就会和它产生路由竞争，这时候就得调整 Docker 的 default-address-pools。

6. 改错之后如何安全回滚与恢复 DHCP

网络配置最怕的不是不会配，而是配错了不知道怎么回来。这里把几种常见的“后悔药”方法整理出来，关键时刻能省下不少时间。

6.1 用备份文件回滚和恢复出厂 DHCP

只要你在改配置前执行过备份，回滚就非常简单：

bash复制sudo cp /etc/netplan/00-installer-config.yaml.bak /etc/netplan/00-installer-config.yaml
sudo netplan apply

如果没有备份，又想快速恢复 DHCP 自动获取网络，可以直接把配置文件内容改成：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: true

然后 sudo netplan apply。这个配置在绝大多数家庭和办公网里都能让它重新拿到地址，相比手动调试静态 IP 的细枝末节，先恢复连通再慢慢排查永远是第一原则。

6.2 版本更新后 gateway4 语法不再推荐

如果你参考的旧教程里写了 gateway4: 192.168.31.1，在 Ubuntu 20.04 上依然能生效，但会看到类似 “gateway4 has been deprecated” 的提示。20.04 自带的 Netplan 版本虽然兼容 gateway4，但新的推荐写法是 routes 段。这个变化很多人没意识到，升级系统后某天突然配置失效，排查半天才发现是语法层面的兼容问题。建议新写的配置一律使用 routes 方案，不要给自己埋这种远期雷。

6.3 桌面版用户完全可以走 NetworkManager 路线

如果你用的是桌面版 Ubuntu 20.04，且机器的网络一直由 NetworkManager 管理，还有一个更省事的备选方案：直接在终端里输入 nmtui 打开文本图形界面，按提示选择网卡、填写 IP 和网关，保存后立即生效。

bash复制sudo nmtui

选择“Edit a connection”，找到对应的有线连接，将 IPv4 配置从 Automatic 改为 Manual，然后填写 Addresses、Gateway、DNS servers，最后 OK 保存并重启连接。

用 nmtui 的方式管理网卡时，Netplan 文件里 renderer: NetworkManager 必须保持不变，对应接口不应再在 Netplan 里定义静态 IP，否则两套配置会互相覆盖。我见过不少人又用 Netplan 又用 NetworkManager 图形界面改同一块网卡，结果两边都以为自己拿到了最终发言权，最后网络时好时坏。记住一个原则：一个网卡只交给一个管理器，不要双轨制。

我个人在实际操作中养成的习惯是：无论桌面版还是服务器版，改任何 Netplan 配置前都先备份；能用到 netplan try 的地方绝对不直接 netplan apply；每台机器只用一套管理工具，不混用 Netplan 和 NetworkManager 去管同一个接口。这套习惯帮我在远程服务器上避免了好几次把自己关在门外的尴尬，也希望你在遇到网络配置问题时，能少走几步弯路。