VM虚拟机Ubuntu断网排查：网络模式、netplan与DNS配置

VM 虚拟机里的 Ubuntu 连不上网，这件事我前后处理过几十次，从刚入门时对着一堆配置文件发懵，到现在基本三五分钟就能定位问题。这套组合本身不难，难的是故障点分散在宿主机、虚拟化软件、Ubuntu 系统三层里，任何一层掉链子，表现都是"没网"。更麻烦的是症状高度相似：图标显示已连接但打不开网页、ping提示 Network is unreachable、能 ping 通 IP 却解析不了域名，这几种情况指向的原因完全不同。这篇内容就是把这套排查流程完整拆开，从网络模式选型讲到虚拟网络编辑器参数、netplan 配置写法、DNS 覆盖问题，以及克隆虚拟机后网卡改名这个经典坑。适合刚在虚拟化平台上装完 Ubuntu 的新手，也适合已经能跑起来但偶尔被网络问题卡住的中级使用者。所有步骤都在实际环境里验证过，配置可以直接抄。

1. 故障先分层：别一上来就改配置文件

1.1 三种断网症状，指向三个不同的故障层级

很多人一发现 Ubuntu 没网，第一反应是打开 netplan 配置文件开始改 IP，改完netplan apply一执行，问题还在，然后继续瞎改。这种做法最大的问题是没搞清楚断在哪一层。虚拟机上网这条链路至少有四个节点：宿主机的物理网卡、虚拟化软件虚拟出来的交换机、Ubuntu 里的虚拟网卡、以及 Ubuntu 里的路由和 DNS 配置。四个节点任意一个出问题，最终表现都是"上不了网"，但处理方式天差地别。

我习惯先按症状分类。第一种，ip a看网卡状态是state DOWN，或者压根没有inet那行地址，说明二层没通，问题大概率在虚拟化软件的网卡设置或者虚拟机内的网卡被禁用。第二种，ip a有地址，ip route也能看到默认网关，但ping 网关IP不通，说明三层路由有问题，多半是网络模式选错、虚拟网络编辑器里的子网和宿主机对不上。第三种，网关能 ping 通，IP 地址也能 ping 通，比如ping 8.8.8.8有回应，但ping www.baidu.com报Temporary failure in name resolution，这就是纯粹的 DNS 问题，改配置文件纯属浪费时间，直接看/etc/resolv.conf和systemd-resolved的状态就行。

这三种症状的区分成本极低，三条命令就能跑完，但它能把排查范围从"整个网络栈"缩小到"某一个具体环节"。我见过太多人卡在 DNS 问题上，却去重装虚拟机、重装系统，白白浪费一整天。

注意：先跑ip a、ip route、ping 8.8.8.8这三条命令，把结论记下来再动手改配置。改之前先知道原来是什么样，改坏了还能退回去。

1.2 我常用的三分钟定位流程

具体流程是这样的：第一步，在 Ubuntu 里执行ip a，找到名字形如ens33、ens160、eth0的那个网卡，看它有没有inet 192.168.x.x这样的地址。没有地址，往下看第 2 节；有地址，进第二步。

第二步，ip route看有没有default via 192.168.x.2 dev ens33这一行。没有默认路由，即使有 IP 也出不去，这时候要么是 DHCP 没下发网关，要么是手动配静态 IP 时漏了gateway4（新版 netplan 是routes下的to: default）。有默认路由，进第三步。

第三步，ping -c 3 192.168.x.2（把地址换成你ip route里看到的网关地址）。不通，说明虚拟网络这一层有问题，回到虚拟化软件的设置里查；通了，进第四步。

第四步，ping -c 3 8.8.8.8。不通但网关通，通常是 NAT 转发或者宿主机自身的网络有问题，检查宿主机的网络连接、虚拟化软件的相关后台服务是否在跑。通了，进第五步。

第五步，ping -c 3 www.baidu.com。不通，就是 DNS。cat /etc/resolv.conf看有没有nameserver行，再看resolvectl status的输出，基本就能定位。

这套流程走完不超过三分钟，但能避免 90% 的无效操作。我把它写在一张便签上贴在显示器边上，新人来了直接照着跑，比讲半小时原理管用。

1.3 一个容易被忽略的前提：宿主机自己得是通的

这个听起来很废话，但真的遇到过。有人抱着笔记本到会议室，宿主机没连上无线，然后在虚拟机里折腾了一小时。虚拟机的网络本质上是借用宿主机的出口，宿主机断了，虚拟机必然断，而且症状和配置错误一模一样。

所以排查的第一步其实应该放在宿主机上：浏览器能不能打开网页，ping一下公共 DNS 有没有回应，虚拟化软件相关的后台服务在系统服务列表里是不是"正在运行"。这三个确认完再进虚拟机，能省掉大量无用功。

2. 网络模式怎么选：NAT、桥接、仅主机的取舍

2.1 三种模式的底层差异，用一句话说清

VM 类虚拟化软件一般提供三种网络模式。NAT 模式是把虚拟机藏在一个虚拟子网后面，由虚拟化软件做地址转换，虚拟机访问外网时源地址被换成宿主机的地址，外网看不到虚拟机，虚拟机也默认不能被外网主动访问。桥接模式是把虚拟机的网卡直接"搭"在宿主机的物理网卡上，虚拟机会像一台独立设备一样出现在宿主机所在的局域网里，从路由器那里单独拿一个 IP，局域网内其他机器能直接访问它。仅主机模式只连接虚拟机和宿主机，不连接外部网络，适合做隔离测试。

三者的差别在地址分配和可见性上。NAT 模式下虚拟机拿到的是虚拟子网里的私有地址，默认是192.168.x.128到192.168.x.254这一段，网关固定是192.168.x.2；桥接模式下虚拟机拿到的地址和宿主机同一个网段，网关就是路由器的地址；仅主机模式下网关是虚拟网络里那个虚拟网卡的地址，出不了外网。

理解这一点非常关键，因为后面所有的 IP、网关、DNS 配置都要和所选模式对应。我曾经见过有人选了 NAT 模式，却手动配了一个和宿主机同网段的静态 IP，结果怎么都不通，因为那个地址在虚拟子网里根本不存在，网关自然也就找不到。

2.2 什么场景选哪种模式

日常开发调试，我基本都用NAT 模式。理由是它对宿主机所在网络环境完全不敏感：换个办公室、换个酒店、连手机热点，虚拟机照样能上网，IP 段还是在那个虚拟子网里，配置文件一个字都不用改。这种稳定性对经常带着笔记本到处跑的人太重要了。缺点是从外部访问虚拟机需要做端口转发，配置起来稍微麻烦一点。

需要让局域网内其他设备访问虚拟机时，比如搭建一个测试服务给同事联调，或者需要虚拟机暴露在局域网里跑某些监听，那就得用桥接模式。桥接模式的关键是"桥接到哪块物理网卡"这个选项，选错了就完全没网。笔记本同时有有线和无线两块网卡时，这个坑特别容易出现。

仅主机模式我主要用在安全测试和隔离实验上，比如跑一些不知道行为的样本，或者搭建纯内网的集群环境。日常上网用这个模式，那是自找麻烦。

2.3 选型阶段最容易踩的三个坑

第一个坑是无线网卡桥接。不少无线网卡的驱动对桥接支持不完整，桥接上去之后虚拟机能拿到 IP，但数据发不出去，表现就是有地址、有网关、ping 不通。遇到这种情况，我的建议是直接换回 NAT，别在驱动层面纠结，性价比太低。真要用桥接，插网线走有线。

第二个坑是桥接时选了"自动"。虚拟化软件里桥接模式有个"自动"选项，它会自己挑一块物理网卡。宿主机上有虚拟网卡、有蓝牙网络适配器、有各种虚拟设备的时候，"自动"经常挑错。手动指定成当前正在用的那块物理网卡，问题基本就没了。

第三个坑是改了模式没重启网络。切换网络模式之后，虚拟机里的网卡还拿着旧模式的地址，这时候不重启网络服务，看到的现象是"设置改了但没生效"。切完模式记得在 Ubuntu 里执行一次sudo systemctl restart NetworkManager，或者干脆重启虚拟机，图个省心。

3. 虚拟机侧设置：虚拟网络编辑器和网卡状态

3.1 虚拟网络编辑器的几个关键参数

VM 类软件都带一个"虚拟网络编辑器"，这是整个虚拟网络的中枢。里面能看到几个虚拟网卡，比如 VMnet0 对应桥接、VMnet1 对应仅主机、VMnet8 对应 NAT。日常出问题最多的就是 VMnet8 这一项。

点进去要确认三件事。一是子网地址，默认一般是192.168.x.0，掩码255.255.255.0。这个网段不能和宿主机所在网段、也不能和公司内网网段冲突。我遇到过一次，公司内网正好用了192.168.8.0/24，而这个虚拟网络默认也是这个段，结果虚拟机里 ping 网关通、ping 外网不通，折腾很久才发现是网段撞了。改个子网地址，比如换成192.168.150.0，立刻就好。

二是NAT 设置里的网关地址，通常是子网的第二个地址，也就是192.168.x.2。这个值要和 Ubuntu 里ip route看到的默认网关一致。如果不一致，说明虚拟机里的配置是旧的，重启一下网络服务重新拿地址。

三是DHCP 设置里的地址范围，默认是x.x.x.128到x.x.x.254。如果你打算给虚拟机配静态 IP，就要避开这一段，选个x.x.x.10到x.x.x.100之间的地址，防止和 DHCP 分配出去的地址撞车。地址冲突的表现很诡异：一会儿通一会儿不通，特别难查。

提示：改动虚拟网络编辑器的设置需要管理员权限，改完之后建议点一次"还原默认设置"再重新配置，能避免很多历史遗留的脏配置。

3.2 网卡"已连接"勾选和后台服务状态

虚拟机设置里的"网络适配器"页面有两个复选框容易被忽略："已连接"和"启动时连接"。前者不勾，等于把网线拔了；后者不勾，每次开机都要手动连一次。我见过有人排查半天，最后发现就是"已连接"没勾上，ip a里那个网卡状态是DOWN，连地址都没有。

宿主机这一侧也要看。打开系统的网络连接列表，应该能看到VMnet1和VMnet8这两个虚拟网卡，状态是"已启用"。如果它们被禁用了（有时候装完某些安全软件会被自动禁用），虚拟机的 NAT 就彻底断了。启用之后建议重启一下虚拟化软件。

再往深一层是后台服务。Windows 平台上的服务列表里，和虚拟网络相关的通常有两个：一个负责 NAT 转发，一个负责 DHCP 分配。这两个服务没启动，虚拟机拿不到 IP 或者出不去外网。检查方式很简单，在服务管理器里搜一下关键词，看状态是不是"正在运行"，启动类型是不是"自动"。如果是手动启动，开机后忘了启动，就会出现"昨天还好好的今天突然没网"的情况。

我还遇到过一次更隐蔽的：这两个服务都在运行，但状态是"正在停止"卡住了。这种情况下重启服务没用，得先结束进程再启动。表现就是虚拟机一直拿不到 IP，ip a里那个网卡反复在UP和DOWN之间跳。

4. Ubuntu 内部配置：从 ip 命令到 netplan

4.1 用 ip 命令把问题钉死在哪一层

Ubuntu 从 18.04 开始默认用 netplan 管理网络，但底层的工具还是ip这一套。排查时我基本不用ifconfig，那个工具在新版里默认都没装，ip命令信息更全。

ip a的输出重点看三处：网卡名、state后面的状态、inet后面的地址。网卡名在新版 Ubuntu 里一般是ens33、ens160这种，不再是eth0。state UP表示链路是通的，state DOWN表示没连上。有inet 192.168.x.x/24说明拿到了地址。如果显示state UP但没有inet那行，说明链路通了但没拿到 IP，问题在 DHCP。

ip route看默认路由。正常的输出里应该有一行default via 192.168.x.2 dev ens33 proto dhcp metric 100。没有这一行，就算有 IP 也出不去。手动配静态 IP 时最容易漏的就是这一项，很多人只配了addresses，忘了配网关。

cat /etc/resolv.conf看 DNS。Ubuntu 桌面版里这个文件通常是个软链接，指向systemd-resolved的运行时文件，直接改它重启后就没了。正确做法是改 netplan 配置或者systemd-resolved的配置。

resolvectl status是查看 DNS 状态最直接的工具，它会列出每个网卡当前用的 DNS 服务器、DNS 搜索域、以及解析是否正常。这条命令的输出比resolv.conf靠谱得多，因为它反映的是实际生效的配置，而不是某个可能被覆盖的文件。

4.2 netplan 配置文件的正确写法

netplan 的配置文件放在/etc/netplan/目录下，文件名一般是00-installer-config.yaml或者01-network-manager-all.yaml。用ls看一眼，有哪个改哪个，别自己新建一个，多个配置文件会互相覆盖，行为难以预测。

先看文件里renderer这一项。桌面版 Ubuntu 一般写的是NetworkManager，服务器版一般是networkd。这个值决定了谁真正接管网络。如果写的是NetworkManager，但你用systemctl restart systemd-networkd去重启，那是白费劲。反过来也一样。我刚开始用的时候就在这上面栽过跟头，改了配置怎么都不生效，最后发现重启的服务根本不对。

DHCP 模式的配置最简单：

network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: true dhcp6: false

静态 IP 的配置要复杂一些，注意新版 netplan 里网关的写法已经变了，旧的gateway4被标记为废弃：

network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: - 192.168.150.50/24 routes: - to: default via: 192.168.150.2 nameservers: addresses: [8.8.8.8, 114.114.114.114]

这里几个细节必须注意。缩进只能用空格，绝对不能用 Tab，YAML 对缩进极其敏感，混用 Tab 和空格会报语法错误，而且报错信息往往指不到真正的位置。文件权限要收紧，执行sudo chmod 600 /etc/netplan/xxx.yaml，权限太宽 netplan 会警告并且可能拒绝应用。改完先sudo netplan try，这个命令会应用配置并等待 120 秒，期间按回车确认，不确认就自动回滚，比直接apply安全得多，尤其是在远程操作的时候。

sudo netplan apply执行完，用ip a和ip route复查一遍，确认地址和网关都变了。如果没变，多半是文件名排序问题或者 renderer 不匹配。

4.3 DNS 配置与 resolv.conf 被覆盖的问题

能 ping 通 IP 但解析不了域名，是最高频的"没网"症状。原因基本就那几种：netplan 里没写nameservers、写了但被别的服务覆盖、或者systemd-resolved服务没跑起来。

Ubuntu 桌面版里，/etc/resolv.conf通常是个指向/run/systemd/resolve/stub-resolv.conf的软链接，内容里只有一行nameserver 127.0.0.53。这个127.0.0.53是本地存根解析器，本身不是真正的 DNS 服务器，真正的上游 DNS 从别处读。所以看到这个地址不用慌，正常。

要确认上游 DNS 有没有配上，跑resolvectl status。输出里每个网卡下面会有一行DNS Servers:，后面跟着实际使用的地址。如果是空的，说明没配上。这时候有两个办法：一是在 netplan 配置里加nameservers然后 apply，二是临时改/etc/systemd/resolved.conf，把DNS=那一行的注释去掉填上地址，然后sudo systemctl restart systemd-resolved。

临时应急还有个野路子：直接sudo rm /etc/resolv.conf然后sudo sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'。这么做能立刻生效，但重启后会恢复，只适合应急排查。我一般用这个方法来快速验证"是不是 DNS 的问题"，确认之后再去做正规配置。

还有一种情况是 DNS 配了但不生效，resolvectl status里能看到地址，解析还是失败。这时候看systemctl status systemd-resolved有没有报错，以及/etc/nsswitch.conf里hosts:那一行是不是包含resolve。这个文件被别的软件改乱的情况虽然少见，但确实存在。

4.4 克隆之后的网卡改名问题

这个坑我踩过不止一次。虚拟机克隆出来之后，新机器的网卡名从ens33变成了ens34，但 netplan 配置文件里写的还是ens33，于是配置完全不生效，ip a里能看到ens34拿不到地址，ens33这个配置项指向一个不存在的网卡。

原因是新版系统的网卡命名和 MAC 地址绑定，克隆出来的虚拟机 MAC 变了，网卡名就跟着变。解决办法有三个。最直接的是打开 netplan 配置文件，把里面所有的ens33改成ip a里实际看到的网卡名，然后 apply。省事的办法是删掉旧配置，sudo rm /etc/netplan/*.yaml，然后重新写一份对的。还有个一劳永逸的办法是改 udev 的命名规则，在/etc/udev/rules.d/下新建一个规则文件，把NAME写死，但这个方法在新版系统上不一定管用，因为命名逻辑已经换到 systemd 那边了。

更稳的做法是修改/etc/systemd/network/99-default.link，把MACAddressPolicy设成none，让网卡名不再跟 MAC 走。改完需要更新 initramfs 并重启，稍微重一点，但克隆多台机器的时候非常值得。

提示：克隆完虚拟机第一件事就是ip a看网卡名，别急着开服务。名字对不上，后面所有配置都是白搭。

5. 常见问题速查与实操心得

5.1 一张表把高频故障对上号

排查的时候最怕东一榔头西一棒子。我把这些年遇到的典型症状和对应原因整理成了一张表，遇到问题先对号入座，能少走很多弯路。

这个表不是穷举，但覆盖了日常 90% 的情况。遇到表里没有的，回到第 1 节的分层流程重新走一遍，别直接改配置。

5.2 几个反直觉的细节，写下来给后来人

第一个细节：ping通不代表网络好。ICMP 能过但 TCP 不通的情况是存在的，比如 MTU 不匹配、防火墙只放了 ICMP。测连通性我更倾向用curl -I或者telnet 目标IP 端口，这两个走的是 TCP，更接近真实使用场景。虚拟机里ping 8.8.8.8通但浏览器打不开，八成是 TCP 层面被拦了，或者代理设置有问题。

第二个细节：改完配置一定要重启服务，而且要是对的那个服务。桌面版是NetworkManager，服务器版是systemd-networkd，DNS 是systemd-resolved。三个服务名字长得像，功能完全不同。我见过有人systemctl restart networking，那是老版本 Debian 的写法，新版里这个服务根本不存在，命令执行完没报错但什么也没做。

第三个细节：虚拟机里装了某些网络管理工具之后，可能会和 NetworkManager 抢控制权，表现为配置改了被还原。判断方法很简单，nmcli device status看设备状态是managed还是unmanaged。如果是unmanaged，说明 NetworkManager 没接管，得看是谁在管。

第四个细节：时间不同步也会引发奇怪的问题。虚拟机挂起再恢复之后，系统时间可能倒退，导致 TLS 证书校验失败，浏览器报证书错误。看着像网络问题，其实是时间问题。timedatectl看一眼就清楚了，sudo timedatectl set-ntp true打开自动同步。

第五个细节，也是我最想强调的：备份配置文件。改 netplan 之前cp一份带日期的备份，出错了一分钟就能还原。我现在每个虚拟机装完系统第一件事就是备份 netplan 目录，这个习惯帮我省掉了好几次重装的麻烦。配置文件那么小，备份成本几乎为零，收益却是实打实的。

我个人在实际操作中的体会是，这类问题之所以让人觉得难，不是因为技术门槛高，而是因为排查顺序乱了。先把症状分层，再顺着链路一层层往下走，绝大多数情况两三分钟就能定位到具体环节，剩下的只是查文档改参数的事。真正需要经验的地方在于：知道哪些改动是安全的、哪些操作可能把系统搞挂、以及改完之后怎么确认真的生效了。这三点想明白了，虚拟机网络这块基本就不会再成为障碍。