Ubuntu 20.04网络配置实战：Netplan、静态IP与DNS排错指南

装完Ubuntu 20.04，第一件事往往就是配置网络。但这台系统跟以前的版本有个很大的区别：你翻遍 /etc/network/interfaces 也找不到传统配置入口，取而代之的是一个叫 /etc/netplan 的目录。很多从16.04、18.04过来的老用户第一次面对这个变化时都挺懵的，我前前后后帮同事处理过几台服务器和虚拟机的网络问题，越来越觉得：只要理解了Netplan的运作逻辑，Ubuntu 20.04的配置网络反而比老版本更清晰、更不容易出错。

这篇文章会围绕Ubuntu 20.04配置网络这个主题，把从网卡识别、Netplan配置语法、静态IP和DHCP的取舍、DNS排错，到VMware虚拟机、WSL、开发板这些特殊环境下的常见坑全部梳理一遍。适合刚装好系统不知道怎么下手的新手，也想给那些“明明照着教程配了却还是上不了网”的朋友一些可复现的排查思路。我尽量用实际场景来说话，少讲空泛的理论。

1. 为什么到了20.04，配置网络的“老办法”突然全失效了

1.1 Netplan到底是什么：它不是一个网络管理工具，而是一个翻译器

很多人误以为Netplan是Ubuntu 20.04里的另一个“网络管理服务”，其实它不是。Netplan本身不负责收发数据包、不维护连接状态，它只是一个配置转换器——在系统启动阶段，或者在管理员执行 sudo netplan apply 时，把 /etc/netplan/ 下的YAML配置“翻译”成后端服务能识别的配置文件。

这个后端服务有两个：systemd-networkd 和 NetworkManager。20.04服务器的默认渲染器是 systemd-networkd，桌面版默认是 NetworkManager。Netplan的活就是把YAML里的 ethernets、wifis、bridges 等描述，转换成 systemd-networkd 的 .network 文件，或者 NetworkManager 的 keyfile。

想通这一层，很多奇怪现象就能解释了：为什么你改了 /etc/systemd/network/ 下的文件重启后失效？因为重启时Netplan又按照YAML重新生成了一遍后端配置，把你手改的覆盖掉了。所以正确做法是：日常配置只动 /etc/netplan/ 下的YAML，后端文件由Netplan来生成。

1.2 两种渲染器的区别，以及选错导致的奇怪现象

看当前用的什么后端，最直接的方法是先看配置文件里的 renderer 字段：

bash复制cat /etc/netplan/01-network-manager-all.yaml
# 或
cat /etc/netplan/00-installer-config.yaml

如果机器上同时有 NetworkManager 和 systemd-networkd 在运行，不会直接打架，因为Netplan生成配置时会根据renderer字段决定写哪套文件。但如果你明明装了桌面版，配置文件里写的却是 networkd，就会出现“有线网卡能通，Wi-Fi列表死活出不来”的情况——因为 systemd-networkd 本身不管无线连接，无线需要 wpa_supplicant 这个额外组件协同，而桌面环境里这套东西通常由 NetworkManager 统一打理。

两种渲染器的主要区别，我用一张表整理：

如果你是非桌面服务器，老老实实用 networkd 就行，性能更轻、行为更透明。如果是笔记本或者桌面机，建议保留 NetworkManager，不要为了统一配置方式把渲染器改成networkd，否则你的无线管理会非常别扭。调试时可以用下面命令确认当前哪个在接管：

bash复制ps aux | grep -E "NetworkManager|systemd-networkd" | grep -v grep

2. 动手前必须搞清楚的三个基础：网卡名、连接状态、配置文件

2.1 网卡命名为什么不是eth0了

Ubuntu 20.04沿用了“可预测网络接口命名”规则，网卡名不再是你熟悉的 eth0，而是像 enp3s0、ens33 这样带总线位置信息的名称。开头几段字母的含义很直接：en 表示以太网，wl 表示无线局域网，p 表示PCI总线位置，s 表示插槽。比如 wlp2s0 就是PCI 2号槽上的无线网卡。

用下面命令列出当前所有网卡：

bash复制ip link show

输出里 lo 是回环接口，不用管。剩下的带 MAC 地址的那个就是物理网卡。如果你是虚拟机，常见名字还有 ens33、ens160、enp1s0，看具体虚拟化平台。网卡名在Netplan配置里是最常用的匹配字段，写错了会出现一种很微妙的现象：netplan apply 不报错，但静态IP压根没生效——因为系统没找到叫那个名字的网卡，YAML里的配置等于白写。所以配置前先把网卡名抄准确，这是排错成本最低的一步。

2.2 配置前先看清楚当前网络状态

不要蒙头就开改。先花一分钟确认现状，能省很多排查时间：

bash复制ip addr show                 # 看网卡当前IP
ip route show                # 看默认路由（网关）
resolvectl status            # 看DNS从哪里来

这几个命令分别回答三个问题：我现在有没有IP？出网走哪个网关？域名解析用的什么DNS。正常联网状态下，ip addr 里能看到 inet 字段，比如 192.168.1.100/24；ip route 里能看到 default via 192.168.1.1；resolvectl status 会列出当前DNS服务器。

如果当前网络本来就是通的，只是想把DHCP改成静态IP，先记录下现在从DHCP拿到的IP、网关和DNS。这些就是你静态配置的最佳参照——跟路由器上的实际网段保持一致，出错概率最小。

2.3 Netplan配置文件在哪，多个文件怎么合并

/etc/netplan/ 目录下可能有一个或多个YAML文件，最常见的两种情况：

• 服务器安装器生成的：00-installer-config.yaml
• 桌面版预装的：01-network-manager-all.yaml
• 云镜像或特殊版可能还有：50-cloud-init.yaml（这种会被cloud-init接管，Netplan手改后可能被覆盖）

多个文件存在时会按文件名顺序合并，后面的文件对相同键值有覆盖权。这个机制有点绕，但平时你只需要关心自己创建的那个文件就行。建议不要乱动系统生成的文件，新建一个类似 /etc/netplan/99-custom.yaml 来放自己的配置，优先级最高，也方便出问题时整个删掉回滚。

配置文件的格式是YAML，缩进极其严格，报错往往就出在缩进和空格上。一个典型的文件头部长这样：

yaml复制network:
  version: 2
  renderer: networkd

network 是根键，version固定为2，renderer指定后端。别小看这个头部，少了 network 根键，整个文件不会被识别；version写1或者不写，很多新字段会直接报错。

3. 核心实战：静态IP配置从入门到半精通

3.1 服务器场景下的最小可用配置

假设你的网卡叫 enp3s0，要在局域网里固定成 192.168.1.100，网关 192.168.1.1，DNS用公共DNS。配置文件可以这么写：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: 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

逐个说关键字段。dhcp4: false 的作用是关闭IPv4的DHCP自动获取，避免出现“我明明配了静态IP，系统过一会儿又自己拿了一个IP”的灵异事件。addresses 就是你的IP，必须带上掩码，/24对应255.255.255.0，这是Netplan的硬性要求，不带掩码会直接语法报错。routes 里 to: default 表示默认路由，也就是所有去往未知网段的数据包都走 via 指向的网关。nameservers 是DNS列表，写在前面的优先级更高，国内网络写223.5.5.5、119.29.29.29这类公共DNS是比较稳的选择。

如果你不确定网段是什么，参考一下路由器后台的设置，或者看别的机器上 DHCP 分配出来的IP、子网和网关。强行配一个跟实际局域网网段对不上的IP，结果是网卡显示有地址，但Ping不通任何地方。

3.2 应用配置的正确姿势：generate、try、apply

配置写完不能直接干等重启，要用Netplan提供的一套命令来应用。我最推荐的次序是：

bash复制sudo cp /etc/netplan/99-custom.yaml /etc/netplan/99-custom.yaml.bak
sudo netplan generate
sudo netplan try
sudo netplan apply

generate 只做语法检查并把YAML翻译成后端配置，不会改变当前网络状态。如果这里有报错，说明YAML格式有问题，改好再跑。try 是安全应用模式：它会尝试应用新配置并等待你确认，默认120秒不回车就自动回滚到上一个可用配置。这个命令对远程服务器尤其重要——你不想因为一个网关写错，把自己锁在机器外面。确认没问题之后按回车让它生效，最后执行 apply 让配置正式写入。

远程SSH操作时的安全套路是这样的：先用scp把改好的YAML传上去，再执行 sudo netplan try，这时候千万别关SSH窗口。等120秒超时自动回滚也好，或者确认网络仍然在线后按回车也好，比直接 apply 稳妥太多。我亲眼见过有人远程 apply 把网关写错，结果IP还在但路由全断，只能跑机房去接显示器救回来。

检查配置是否生效，用 ip addr show enp3s0 看IP，再用 ping -c 3 网关IP 和 ping -c 3 223.5.5.5 分别验证局域网和外网连通性。注意：能Ping通局域网不等于能上外网，外网联通还依赖DNS和默认路由。

3.3 桌面版用NetworkManager时的配置方式

在桌面版20.04上，默认的01-network-manager-all.yaml 内容很少，基本就是把所有网卡都交给 NetworkManager 托管：

yaml复制network:
  version: 2
  renderer: NetworkManager

这种状态下你如果在Netplan里直接给有线网卡写静态IP，经常会发现“配置了但不生效”，或者“重启后又变回DHCP了”。原因在于：你绕过NetworkManager去改后端，而NetworkManager又有自己的一套连接配置，两边互相不认。桌面版的正确做法是直接用NetworkManager自己的工具来改：

bash复制nmcli con show     # 查看当前连接名，比如 "Wired connection 1"
nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "223.5.5.5 119.29.29.29"
nmcli con up "Wired connection 1"

这条命令链的含义分别是：把连接方式改为手动、设置IP和掩码、设置网关和DNS、重启这个连接让修改生效。改完之后 nmcli con show "Wired connection 1" 能查看到完整配置。如果你觉得命令行麻烦，在“设置 -> 网络 -> 有线 -> IPv4”里手动填也是一样的效果，底层写的是同一个位置。

桌面版想用Netplan写静态IP也可以，把渲染器改成 networkd 就绕开了NetworkManager，但代价是图形界面的网络管理、Wi-Fi扫描这些功能都会失效，对笔记本用户来说代价太大，不建议。一句话总结：你机器上谁在管网络，就用谁的工具去配置，跨工具操作是桌面版配置最常见的坑。

4. DNS解析出问题：最常见的“假网络故障”

4.1 能ping通IP却上不了网，先查DNS

“网络连接显示正常，但浏览器打不开网页”这个症状太典型了。先用一句话判断问题方向：Ping通公共IP说明物理链路和路由没问题，Ping不通域名说明DNS解析环节出了岔子。Ubuntu 20.04的DNS体系比较特殊，得先讲清楚。

默认情况下，/etc/resolv.conf 不是一个普通文件，而是一个指向 /run/systemd/resolve/stub-resolv.conf 的软链接。stub-resolv.conf 里写的DNS是 127.0.0.53，这是 systemd-resolved 提供的本地解析器地址，所有需要解析域名的程序都会把查询请求发给这个本地地址，再由 systemd-resolved 根据实际配置转发给上游DNS。如果直接往 /etc/resolv.conf 里写死一个公网DNS，重启后会被覆盖，因为这是软链接指向的动态文件。

排查步骤，按顺序来：

bash复制cat /etc/resolv.conf                    # 确认是不是指向stub
resolvectl status                       # 看当前系统实际用的上游DNS
nslookup baidu.com 127.0.0.53           # 测试本地解析器是否正常工作
ping -c 3 223.5.5.5                     # 测试外层网络是否通

如果 nslookup 能查出域名但浏览器不行，可能是浏览器的DNS设置或者代理问题；如果 nslookup 本身报超时或REFUSED，那基本就是 systemd-resolved 的上游DNS挂了或不可达。还有人遇到过一种情况：路由器给内网设备下发的DNS指向路由器自身IP（比如192.168.1.1），但路由器那个DNS转发服务不稳定，表现为“时通时不通”“偶尔解析很慢”。这种问题你在机器上怎么查都查不出来，因为IP、路由全对，DNS也配了，纯粹是上游垃圾。解决办法是直接把DNS改成公网地址，绕开路由器自带的转发。

4.2 永久修改DNS的正确方式

要在Netplan里配DNS，前面示例文件里已经有标准写法：

yaml复制      nameservers:
        addresses:
          - 223.5.5.5
        search:
          - lan

addresses 指定DNS服务器，search 指定域名搜索后缀。search 字段的作用是：你访问一个不带域名的主机名时，系统会自动补上 .lan 后缀去搜索。比如你把search配成lan，那么 ssh nas 会自动变成尝试解析 nas.lan。这个字段平时用处不大，但在局域网里有内网主机名的场景特别方便。

改完执行 sudo netplan apply，然后验证：

bash复制resolvectl status

重点看当前生效的DNS列表是不是你写的那几个。如果这里显示的还是DHCP下发的地址，说明你的接口可能同时开着DHCP并且没把DNS覆盖掉。这种情况下可以在接口配置里加一行 dhcp4: true 配合 nameservers 同时存在，或者干脆像我前面那样用静态IP。需要注意：Netplan在 DHCP 开启时，nameservers 字段和 DHCP 下发的 DNS 之间谁优先级高，在不同版本里表现不完全一样。为了避免这种不确定性，关键机器我更推荐直接静态IP，把DNS也完全掌控在自己的配置文件里。

另外提一下 /etc/systemd/resolved.conf 这个文件，它最顶层可以设置 FallbackDNS，作用是当所有其他地方配的DNS都失效时系统会自动用这里的地址。这算是个兜底配置，适合日常经常换网络环境、又不想每换一次网络就改一堆配置的场景。

5. 无线网络配置：服务器版没有图形界面怎么办

5.1 用Netplan配置Wi-Fi的完整步骤

如果你在Ubuntu Server（无桌面环境）上想连Wi-Fi，没有图形界面可点，只能靠netplan或nmcli。假设你的无线网卡叫 wlp2s0，Wi-Fi名字叫 MyWiFi，密码是 mypassword，Netplan配置如下：

yaml复制network:
  version: 2
  renderer: networkd
  wifis:
    wlp2s0:
      dhcp4: true
      access-points:
        "MyWiFi":
          password: "mypassword"

dhcp4: true 表示Wi-Fi连接用DHCP自动获取IP，这是路由器场景下最省事的默认方式。access-points 下面就是要连接的ESSID，SSID和密码都需要用引号包住，尤其是密码里有特殊字符时，不包引号YAML会解析失败。

写完保存后执行 sudo netplan generate && sudo netplan apply。观察连接情况：

bash复制ip addr show wlp2s0
iw dev wlp2s0 link   # 查看无线连接状态

能拿到IP并且 iw dev 显示 Connected to 说明连接成功。如果 iw dev 里什么都没有，先确认无线网卡没被软件开关禁用：

bash复制rfkill list
rfkill unblock wifi

rfkill 是Linux里的无线开关管理工具，有些机器默认把wifi锁住了。unblock之后重新 netplan apply。这是一个非常容易被忽略的坑，尤其是从Windows物理机上装Ubuntu时，硬件无线开关可能在系统层面被锁住。

5.2 隐藏SSID、5GHz频段和信号不稳的处理

如果路由器隐藏了SSID，需要在配置里加一行。另外强制走5GHz频段时，不同驱动表现差异很大，Netplan层面能做的有限，更依赖驱动固件。比较常见的做法是在netplan里指定band和channel：

yaml复制        "MyWiFi":
          password: "mypassword"
          hidden: true
          band: 5GHz
          channel: 149

band 指定5GHz频段，channel 建议跟路由器5GHz设置里保持一致，比如149、36、161都常见。注意并不是所有无线网卡驱动都支持这种指定，不生效的话优先检查驱动和固件，不要反复折腾Netplan字段。信号弱导致的DHCP超时是另一个常见坑：表现是无线网卡连上了，但 ip addr 拿不到IP。这种时候先移动位置或靠近路由器重试，如果还是不行，手动配静态IP试试，能排除一部分DHCP交互异常的问题。路由器5GHz频段在国内需要遵循法规选择允许的信道，149这个信道在市面上大部分路由器的“自动”模式下都能用。还有个经验：TP-Link、小米这些家用路由器上，把无线模式设为“11ax混合”时，某些老网卡会出现频繁掉线，网卡驱动层面修不了的，试着切回“11ac混合”往往就好了。

6. 不同环境下的网络配置差异：VMware、WSL、开发板

6.1 VMware虚拟机里NAT和桥接的正确打开方式

在VMware里装Ubuntu 20.04做开发测试，很多人会选择在虚拟机里改静态IP，但环境不同，配置逻辑差很多。VMware虚拟网络编辑器里有三种模式：NAT、桥接、仅主机。NAT模式是虚拟机通过宿主机共享上网，默认网关通常不是192.168.1.1，而是VMnet8网段的网关地址（一般是192.168.x.2）。你需要在VMware的虚拟网络编辑器里看当前NAT网段，比如VMnet8是192.168.111.0，那么虚拟机IP要配成192.168.111.x，网关配192.168.111.2。

桥接模式则是虚拟机直接和宿主机在同一个局域网，Guest的网卡桥接到宿主机的物理网卡上，虚拟机看起来就像局域网里的一台独立电脑，IP要跟物理局域网同一网段。这里有个笔记本用户特别容易踩的坑：宿主机的物理网卡如果有两个（有线+无线），VMware默认桥接方式可能选的是有线网卡，但你实际用Wi-Fi上网，桥接选错网卡的结果就是虚拟机有IP但出不了网。在“虚拟机 -> 设置 -> 网络适配器 -> 自定义 -> 桥接模式”旁边可以把桥接到哪块网卡改对。

此外，在VMware里如果启用了“复制物理网络连接状态”这类选项，网络行为会变得更复杂。我的建议是：纯学习环境用NAT最简单；需要让局域网其他机器直接访问虚拟机（比如调试开发板、跑web服务给同事看），就选桥接，但务必确认桥接的物理网卡和宿主机实际上网网卡一致。

6.2 WSL里的Ubuntu：网络不需要你手动配

WSL2里的Ubuntu 20.04是跑在微软的虚拟化平台上，网络由Windows统一管理，底层是NAT式的虚拟交换机。你在WSL里看 ip addr 会得到一个172.x.x.x的内网IP，这个IP由Windows侧动态分配，每次重启可能变化，不要指望它稳定。WSL里默认不用配Netplan，直接DHCP就能用。如果你在WSL里改了Netplan，最常见的后果是网络完全不可用，因为WSL启动时使用的是Windows侧的网络栈，Netplan生成了systemd-networkd配置但WSL不一定以systemd方式启动全套网络服务。

WSL里常见的网络问题其实出在Windows侧：DNS解析失败、防火墙拦截、代理设置残留等。排查思路：先在Windows的cmd里 nslookup baidu.com 看解析是否正常，再在WSL的Ubuntu里 curl baidu.com 看有没有输出。WSL里不小心设置了 http_proxy 这类环境变量指向一个不存在的地址，也会出现“网络明明通但所有命令都超时”的怪象，用 env | grep -i proxy 查一下。

WSL还有一个做开发板交互时的痛点：Windows宿主和WSL的IP是NAT关系，开发板和WSL不在同一网段，直接通信受限。常见解法是在Windows上用端口转发，或者干脆在Windows原生用SSH工具连开发板，不经过WSL。

6.3 开发板与Ubuntu主机互联：网线直连的静态IP技巧

开发板（树莓派、香橙派、各类ARM板卡、飞控开发板）和Ubuntu主机之间用网线直连，是嵌入式开发里特别常见的场景。直连没有路由器，两台设备需要自己协商网段，所以必须在Ubuntu主机上配一个和开发板同网段的静态IP。比如开发板默认IP是192.168.1.1/24，那么Ubuntu主机的有线网卡就配成192.168.1.100/24，然后SSH登录：

bash复制ssh root@192.168.1.1

这里最容易出现的坑是主机同时连着Wi-Fi，默认路由走了Wi-Fi出去，而有线网卡的静态IP配置有时不生效或者被NetworkManager干扰。可以检查一下有线网卡的连接状态：

bash复制nmcli device status

如果看到有线网卡的state是unmanaged，说明它没被NetworkManager管理，看之前提到的renderer配置哪里出了问题。反之如果state是connected，那IP应该已经生效。

开发板通过NFS或者sshfs挂载到Ubuntu主机的目录时，也需要先把IP连通。挂载NFS前记得检查两台机器的防火墙，Ubuntu侧的ufw如果开着，要放行NFS相关端口（2049），否则 mount -t nfs 会一直卡在超时。开发板挂载主机目录我常用的是：

bash复制sudo mount -t nfs 192.168.1.100:/home/user/shared /mnt/shared

挂载不上的时候，先在主机侧 exportfs -v 确认导出的路径和权限没错，再在开发板侧 Ping 通主机IP，网络不通的话后面全是白搭。

7. 排错宝典：网络出问题时的完整排查链路

7.1 SSH突然连不上：先别慌，按顺序查

Ubuntu 20.04的SSH连接突然失败，通常不是配置被改了什么，而是IP变了、服务停了、或者防火墙拦了。按这个顺序查，基本能定位问题：

bash复制arp -a                                    # 看看局域网里是否还有这台机器的记录
sudo nmap -sn 192.168.1.0/24              # 扫一下整个网段，找到这台机器的当前IP
ip addr show                              # 如果人在机器前面，直接看当前IP
systemctl status ssh                      # 20.04的SSH服务名是ssh，没有用sshd这个名字
sudo ufw status                           # 看防火墙是否放行22端口

远程运维时SSH断开的最常见原因是：你改了静态IP或者路由，机器重启后IP变了，SSH自然连不上旧地址。这种情况只能物理访问机器或者靠带外管理。另外很隐蔽的一个坑是网卡的省电模式，笔记本在合盖休眠后网卡进入省电状态，SSH会表现为“能Ping通但连不上”，用 ethtool 检查：

bash复制ethtool enp3s0 | grep Wake-on

如果结果是 Wake-on: g，有时也需要用 ethtool -s enp3s0 wol g 开启网络唤醒，不过这是硬件层面的事，具体成效依网卡而定。普通台式机和服务器不用太纠结这个。

SSH连不上时还要区分“连接被拒绝”和“连接超时”。前者说明端口没监听，多半是ssh服务没起或者防火墙DROP了；后者说明数据包根本没到目标机器或者被防火墙静默丢弃，优先检查网络层。在局域网里可以用 nc -zv 目标IP 22 快速测试端口是否开放，比直接肉眼瞪眼靠谱。

7.2 apt update报404或连接失败：源的问题占八成

热搜词里那个“ubuntu更新源404问题处理”特别典型。20.04的代号是focal，你用的软件源如果写的不是focal，比如混入了18.04的bionic或者22.04的jammy，apt update就会报404。查看当前源：

bash复制cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

404还有一种常见情况：你添加的PPA仓库已经不再支持focal了。比如用 add-apt-repository 装某个第三方软件，PPA地址里的版本代号还是之前系统的，等系统升级到20.04后，PPA的仓库focal路径下没有对应包，就会报404。处理办法：注释掉或者删除 /etc/apt/sources.list.d/ 下对应的.list文件，再 sudo apt update 就不会看到那一堆报错了。PPA本身如果确实没用了，直接 add-apt-repository --remove ppa:xxx/yyy 干净移除。

连接失败则是另一类问题。apt update报“Could not resolve archive.ubuntu.com”时，说明DNS解析失败，回到上面DNS排查那套流程。如果报“Failed to connect”但浏览器能打开网页，检查代理配置：

bash复制env | grep -i proxy
cat /etc/apt/apt.conf.d/ | grep -i proxy

有些国内网络环境需要配置APT代理，有些则是系统设置了代理但没给apt单独配，结果apt走不了代理导致连接超时。在国内服务器上最常见的一个实用做法是换成国内镜像源，复制之前先确认系统代号：

bash复制lsb_release -a
# 或
cat /etc/os-release

然后用sed批量替换源里的archive.ubuntu.com为镜像站地址，比如mirrors.aliyun.com或者mirrors.tuna.tsinghua.edu.cn。替换时务必保证整个源文件里所有条目都是同一个系统代号，不要出现focal和jammy混着写的情况，否则apt会一直报错。

7.3 配置应用后网络彻底断开：紧急自救三步

不管是因为网关配错、DNS写错还是网卡名对不上，只要网络断在自己眼前，都别慌。绝大多数情况是能够恢复到可用状态的。紧急处理三步走：

第一步，用命令行临时配置替代文件配置。比如网卡叫enp3s0，网关是192.168.1.1：

bash复制sudo ip addr add 192.168.1.100/24 dev enp3s0
sudo ip route add default via 192.168.1.1

这两条命令直接把IP和默认路由加到内核网络栈里，不需要改任何文件。执行后立刻能通，但这只是临时的，重启后失效。第二步，如果不想手填路由，直接用DHCP把网卡救回来：

bash复制sudo dhclient enp3s0

第三步，网络恢复后马上检查你的netplan配置文件哪里写错了，改回正确值后 sudo netplan apply。如果机器是远程的，重新连上SSH之后再重复这个流程。这套自救方法在现场运维时价值极高，它不依赖任何文件系统状态，直接操作内核网络参数，无论配置文件烂成什么样都能先把链路救通。

7.4 从物理层到应用层的完整排查链路

网络排查最忌讳东一榔头西一棒子。我的习惯是从底层往上层一层层过，每层确认无误再往上查。整理成了一张常用命令表格，按顺序执行即可：

还有一个万能的抓包工具tcpdump，定位到具体设备问题时特别有效。比如怀疑DNS有问题，在网卡上抓53端口流量：

bash复制sudo tcpdump -i enp3s0 udp port 53

看到有请求包发出但没响应包回来，那问题基本在DNS服务器那边，机器本身配置没问题；如果请求包都没发出去，可能是本地解析器状态不对，重启一下 systemd-resolved：

bash复制sudo systemctl restart systemd-resolved

这套方法论同样适用于Wi-Fi问题、虚拟机问题、开发板互联问题。先确定是OSI哪一层的故障，再针对性处理，能节省大量无效操作。

最后说一点我在Ubuntu 20.04配置网络这件事上的个人体会。网络配置这类基础操作，最怕的就是“照着教程抄但不知道每条配置在干嘛”。Netplan把配置集中到了一处，语法也比古老的interfaces文件友好得多，只要你理解了渲染器、YAML字段和apply/try的区别，后面极少会踩坑。如果你经常在多套网络环境之间切换，建议把 /etc/netplan/ 下的配置文件纳入git管理，每次改动留痕，出了问题可以秒回滚到上一个可用版本。远程操作任何生产机器之前，先跑 netplan try 而不是直接 netplan apply，这个习惯能帮你避免至少一次跑机房的命运。