VMware虚拟机Ubuntu断网排查：从NAT服务到DNS的全流程指南-代码聚汇网

VMware虚拟机Ubuntu断网排查：从NAT服务到DNS的全流程指南

李一雷·2026-09-09·阅读 39 GEO检测（免费）

虚拟机网络VMwareUbuntu

|难度：普通|阅读约 29 分钟

说个真实经历。前阵子在一台新装的VMware Workstation 17里部署Ubuntu 22.04，系统装完一切正常，我习惯性地执行 apt update，结果直接给我报“Temporary failure resolving 'archive.ubuntu.com'”。浏览器也打不开任何网页，右上角网络图标带个问号。当时第一反应是先ping一遍：ping 127.0.0.1 通了，ping 宿主机VMnet8的IP也通了，但 ping 网关直接超时。查了一堆资料，最后发现是Windows服务管理器里VMware NAT Service没启动，点一下启动，网络马上就回来了，前前后后折腾了半小时，真正出问题的地方却只有一秒钟。这篇文章就是想把这类“虚拟机Ubuntu断网”的问题做一次完整的梳理：从原理到排查，从VMware侧到Ubuntu内部，把常见原因和对应的解决方案都列出来。你可以按顺序排查，也可以直接跳到自己怀疑的那一节。适合刚接触VMware和Ubuntu的新手，也适合那些“明明之前好好的、今天突然断网”的老手。

1. 虚拟机上网的底层逻辑：NAT、桥接和仅主机到底差在哪

1.1 VMware的三种网络模式怎么选，直接影响你会不会断网

VMware Workstation安装完成后，会在宿主机上创建两个虚拟网卡：VMware Network Adapter VMnet1和VMware Network Adapter VMnet8，分别对应“仅主机模式”和“NAT模式”。外加一个逻辑上的VMnet0，对应“桥接模式”。

NAT模式（VMnet8）：虚拟机访问外网时，数据包交给宿主机，由宿主机做NAT转发出去。对外表现为宿主机的一个普通进程，不占用物理网络IP。默认网段是192.168.x.0/24，宿主机VMnet8网卡IP是192.168.x.1，虚拟机自动从DHCP拿IP。
桥接模式（VMnet0）：虚拟机直接连接到宿主机的物理网络，和宿主机在同一网段，有自己的独立IP，像一台真实的物理设备。这个模式下如果宿主机物理网络本身不稳，虚拟机也会跟着断。
仅主机模式（VMnet1）：虚拟机只能跟宿主机通信，不能访问外网，除非在宿主机上做额外的代理或NAT转发。

最后从实际使用角度说一句：日常开发测试一律用NAT，任何涉及局域网通信的场景才切桥接。这三种模式的差异，用一张表看得更清楚。

网络模式	对应VMnet	虚拟机IP来源	适用场景	断网常见原因
NAT模式	VMnet8	默认DHCP分配，网段192.168.x.0/24	大部分开发、测试、学习场景	NAT服务未启动、VMnet8配置损坏、防火墙拦截
桥接模式	VMnet0	与宿主机同网段，由路由器DHCP分配	需要局域网内设备直接访问虚拟机	IP冲突、物理网络隔离、路由器限制
仅主机模式	VMnet1	与宿主机VMnet1同网段	纯本地测试、实验环境	无NAT、无外部网络、宿主机防火墙

1.2 断网排查之前，先按这个顺序定位

排查时不要一上来就改Ubuntu配置。我习惯按从底层到上层的顺序来：

在虚拟机里ping自己的IP。不通：网卡没起来或驱动问题。
在虚拟机里ping宿主机VMnet8的IP（比如192.168.x.1）。不通：虚拟网络链路断了。
在虚拟机里ping默认网关。不通：NAT服务或路由问题。
在虚拟机里ping 223.5.5.5。通：公网链路OK，问题多半在DNS。
在宿主机上ping虚拟机的IP。不通：VMnet8或防火墙问题。

这个顺序基本能覆盖90%的断网场景。每一步“不通”，对应的排障方向都不一样。后面章节就按这个思路展开。

1.3 一个反直觉的事实：宿主机网络正常，不代表虚拟机网络正常

很多人觉得宿主机能上网，虚拟机就一定没问题。其实虚拟机的网络链路里多了好几层代理组件：虚拟网卡驱动、VMware的NAT/DHCP服务、Windows防火墙对VMware进程的放行、虚拟网络编辑器的网段配置，以及Ubuntu内的netplan配置。任何一个环节出问题都会导致断网。所以排查思路必须是“逐层验证”，而不是“看宿主机”。

打个不太恰当的比方：宿主机上网正常，相当于你小区大门是开的；但虚拟机想出去，还得看你单元楼的门禁、你家的门锁、以及楼道里的路通不通。VMware NAT Service就是那个单元楼门禁，虚拟网络编辑器就是楼道布局，Ubuntu里的配置就是你家的门锁。谁卡住了，你都出不去。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. VMware侧重点排查：服务、虚拟网络编辑器和连接报错

2.1 两个Windows服务：VMware NAT Service和VMware DHCP Service

在Windows上按Win+R输入 services.msc 打开服务管理器，找到 VMware NAT Service 和 VMware DHCP Service。前者负责把虚拟机发出的数据包做NAT转发，后者负责给虚拟机分配IP。

这两个服务是NAT模式下虚拟机上网的核心。它们一旦没启动，表现五花八门：虚拟机开机后网络图标带问号、分配不到IP、或者IP是169.254.x.x——这个网段是Windows和Linux在DHCP失败时自动分配的链路本地地址，看到它基本可以断定DHCP环节出了问题。如果是“能拿到IP但出不去”，多半是NAT Service没启动，或者Windows防火墙拦了vmnat.exe。

具体的操作步骤很简单：

打开 services.msc
找到VMware NAT Service，确认状态为“正在运行”，启动类型为“自动”
找到VMware DHCP Service，同样确认
如果服务被禁用，右键把启动类型改为“自动”并启动
退出VMware Workstation（包括系统托盘图标），重新打开

有一个容易被忽略的坑：某些系统优化软件或安全管家会把这两个服务设置为“手动”或直接禁止开机启动，导致每次开机虚拟机网络都不可用。遇到这种问题，改回自动之后，建议把这两个服务加入优化软件的白名单。这个细节我在实际工作中遇到过好几次，每次都是“莫名其妙断网”的结果。

2.2 虚拟网络编辑器：还原默认设置的正确姿势

如果服务没问题，下一步就是打开VMware Workstation的“编辑”菜单，进入“虚拟网络编辑器”。先检查VMnet8是否被配置为NAT模式，DHCP是否启用。正常状态下，VMnet8这一行会显示“NAT模式”，下方有子网IP和子网掩码。

如果配置看起来正常但还是不通，可以在所有虚拟机都关闭的状态下点击“还原默认设置”，然后重新配置：

VMnet8设置为NAT模式，勾选“使用本地DHCP服务将IP地址分配给虚拟机”
如果你希望虚拟机IP固定，可以保留DHCP并配置地址保留，或者手动设置静态IP（第5章会讲具体做法）

还原默认设置会清空你之前的全部自定义网络配置，包括端口转发、自定义网段等。建议操作前先截图存档。还原后默认网段通常是192.168.xx.0，IP变了的话，虚拟机里的静态IP配置也要跟着改。我见过有人还原之后没注意网段变化，虚拟机里的静态IP还是旧网段，折腾半天才发现是网段对不上。

2.3 “vmware workstation 无法连接到虚拟机”报错的排查链路

这个报错虽然不直接等于断网，但它出现在打开虚拟机时，导致虚拟机根本起不来。常见原因和解决方向：

VMware Authorization Service未启动。在服务管理器中找到VMware Authorization Service，设为自动并启动。
安装目录或临时目录权限异常。检查C:\ProgramData\VMware\和安装目录，确保当前用户有读写权限。有时候杀毒软件会锁定这些目录，临时关掉杀毒软件再试。
以管理员身份运行VMware Workstation。右键图标 →“以管理员身份运行”。
如果是VMware Tools导致的异常，进入安全模式重装或卸载VMware Tools。

按这个顺序排查，十次有八次是第一项解决。另外提醒一句：如果你的Windows同时还开着WSL2或Hyper-V，虚拟化平台和VMware共存时也可能出现各种奇怪问题，包括网络异常。需要的话可以在“启用或关闭Windows功能”里临时关闭Hyper-V来验证。这不是标准答案，但值得试一下排除干扰项。

3. Ubuntu内部的排障顺序：网卡、Netplan与DNS解析

3.1 网卡状态检查：先确认网卡驱动和链路是否正常

进入Ubuntu终端后，先看网卡状态：

bash复制ip addr
ip link

确认你的网卡（VMware下默认是ens33）状态是UP，并且有IPv4地址。如果状态是DOWN，运行：

bash复制sudo ip link set ens33 up

如果这里报错或者网卡干脆不存在，问题可能在VMware的虚拟网卡类型不匹配，或者是克隆虚拟机导致的MAC问题（后面专门讲）。

另一个常见现象是右上角网络图标带问号，点击后显示“未托管”。这跟NetworkManager没有接管网卡有关。Ubuntu 18.04之后网络管理变得比较分裂：底层用netplan管理配置，桌面版又依赖NetworkManager做图形化控制。如果/etc/netplan下的配置里写了NetworkManager渲染器，但服务没跑，就会出现“未托管”。解决办法：

bash复制sudo systemctl enable --now NetworkManager
nmcli device set ens33 managed yes

设置完之后用 nmcli device status 确认网卡状态，一般就变成了“已连接”。

3.2 Netplan配置文件：Ubuntu 18.04之后的重灾区

Ubuntu 18.04+的网络配置由netplan管理。配置文件在/etc/netplan/目录，不同版本文件名可能不同，常见的有00-installer-config.yaml、01-network-manager-all.yaml、50-cloud-init.yaml。先看内容：

bash复制cat /etc/netplan/*.yaml

如果是桌面系统，通常会是这样：

yaml复制network:
  version: 2
  renderer: NetworkManager
  ethernets:
    ens33:
      dhcp4: true

如果配置看起来没问题，执行 sudo netplan apply 看看有没有报错。我遇到的常见报错：

“conflicting default route declarations for IPv4”：说明你配置了两次默认路由，通常是多个网卡都写入了默认网关。
“Cannot call openvswitch”：需要另外装openvswitch-switch包，但不常见。

克隆虚拟机导致的MAC地址问题也在这里：克隆后虚拟机的MAC变了，但如果netplan里的ethernets块还指定了旧MAC，网卡永远不会被启用。执行 ip addr 看到没有ens33但有一个奇怪名字的网卡，多半就是这个原因。解决办法：

bash复制sudo nano /etc/netplan/01-network-manager-all.yaml

把 match: 下的 macaddress: 那一行删掉，或者改成 match: {name: ens*}，然后 sudo netplan apply。这种“网卡名字对不上”的情况，在克隆场景里出现频率非常高。

3.3 DNS问题：能ping通IP但打不开网页

这类断网形态最迷惑人：apt update 报“Temporary failure resolving”，但 ping 223.5.5.5 是通的。这说明网络链路没问题，纯粹是DNS解析挂了。Ubuntu 18.04+默认启用systemd-resolved，/etc/resolv.conf是一个软链接，指向/run/systemd/resolve/stub-resolv.conf。如果systemd-resolved服务异常，或者DNS服务器配置被写坏，就会解析失败。

排查命令：

bash复制resolvectl status
cat /etc/resolv.conf

临时方案：手动切换DNS测试：

bash复制sudo systemd-resolve --flush-caches

永久方案：在netplan配置里加DNS：

yaml复制network:
  version: 2
  ethernets:
    ens33:
      dhcp4: true
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]

然后 sudo netplan apply。如果公司内网有独立DNS，在这里填内网DNS地址。这里补充一个细节：有些版本里systemd-resolve命令已经被resolvectl替代，如果你的系统提示找不到systemd-resolve，直接改用resolvectl flush-caches。

4. 那些“没道理”的断网：克隆、休眠唤醒、双网卡和代理残留

4.1 克隆虚拟机后没有IP：MAC地址错位

这是VMware场景里非常典型的问题。从模板机克隆出来的新虚拟机，会生成一张新的虚拟网卡（新的MAC地址），但Ubuntu内部还是用旧配置去匹配网卡。症状：IP是空白的，或者网卡叫ens38而不是ens33。排查方法：

bash复制ip link
cat /etc/netplan/*.yaml

对比一下，如果netplan里硬编码了macaddress，直接改成新MAC，或者把match条件改成按网卡名匹配。实际操作中，直接把macaddress行删掉最省事，让netplan按默认规则匹配网卡。改完执行 sudo netplan apply，不要重启系统，重启反而容易引入新的变量。

4.2 休眠唤醒后网络假死：宿主机网络环境变化导致

场景描述：笔记本盖子合上很久，唤醒后虚拟机里的网络不通。原因多半是宿主机从有线切到了Wi-Fi，或者重新获取了IP，导致VMnet8网卡自身所处的网络环境变化，虚拟机里缓存的网关信息失效。解决办法：

bash复制sudo ip link set ens33 down
sudo ip link set ens33 up
sudo dhclient ens33 -r
sudo dhclient ens33

如果频繁出现这个问题，建议把VMnet8在Windows里设为固定IP，同时把Ubuntu的网卡设为静态IP。笔记本用户经常切换网络环境，这个操作能省下大量重复排障时间。Wake-on-LAN相关的设置不建议动，默认情况下和这个问题关系不大。

4.3 双网卡配置导致的默认路由冲突

给虚拟机加了多个网卡（比如同时加了NAT和桥接），可能会看到网络时好时坏。原因：多张网卡各自拿到默认路由，系统选了错误的网关。检查：

bash复制ip route

如果有多条default路由，就需要删掉不该用的那条：

bash复制sudo ip route del default via <不该用的网关>

根治方法是在netplan里给次要网卡不配置默认网关，也就是次要网卡只写IP和DHCP，不写routes或gateway4字段。这个坑在虚拟机调试网络时非常容易踩，尤其是从网上拷贝别人的配置文件时，容易把两张网卡都写成带默认网关的。

4.4 代理残留：apt、pip、git在命令行下集体“断网”

这是很多人会忽略的坑。如果你之前设置过代理，后来取消了图形界面的代理，但环境变量里还留着，就会出现浏览器能打开网页、命令行却全都连不上的现象。检查：

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

把~/.bashrc、/etc/environment、/etc/profile里的http_proxy、https_proxy清理掉，并检查apt的配置文件/etc/apt/apt.conf.d/95proxies是否残留。这类问题在开发机里出现频率极高，尤其是一些教程教人配置代理拉取Docker镜像或GitHub代码，后来又没讲怎么清理。命令行下所有网络工具都会读环境变量，这个残留会同时影响apt、pip、git、curl等多个工具，表现就是“所有终端命令都断网，但浏览器正常”。

4.5 没装VMware Tools，网卡行为会变得很奇怪

VMware Tools会在虚拟机里安装虚拟网卡驱动（vmxnet3/vmxnet），优化网络性能。如果没有安装，网络也能用，但性能差、丢包多、休眠唤醒后更容易断。如果你在VMware里安装Ubuntu时“简易安装”没成功，VMware Tools可能没装上，建议：

bash复制sudo apt install open-vm-tools open-vm-tools-desktop

装完重启。这里说一句：Ubuntu 20.04之后，VMware官方也会建议直接用open-vm-tools替代传统的VMware Tools，包更小，维护更省心。装完之后确认一下 systemctl status open-vm-tools，服务在运行就说明驱动加载正常。

5. 断网解决之后的加固：固定IP、快照和保命习惯

5.1 手动指定静态IP，减少DHCP带来的不确定性

如果在NAT模式下希望虚拟机IP固定，建议在DHCP地址池之外手动指定。比如VMnet8网段是192.168.148.0/24，DHCP默认从128开始分配，那么给虚拟机分配192.168.148.50这种方式。在netplan里配置：

yaml复制network:
  version: 2
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.148.50/24
      routes:
        - to: default
          via: 192.168.148.2
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]

注意：NAT模式下，VMnet8网关通常是192.168.x.2，不是192.168.x.1（VMnet8虚拟网卡在Windows上是x.1）。我第一次配置静态IP时直接把网关填成了x.1，结果虚拟机死活上不了网，排查半天才发现网关写错了。这一点值得单独拿出来强调。

5.2 善用快照，改配置前先拍一张

网络配置出问题后，来回改很容易越改越乱。建议在任何涉及网络的操作前拍一张快照，改坏了直接恢复。VMware的“虚拟机”菜单 →“快照”→“拍摄快照”。快照不是万能钥匙，但至少能让你有后悔药吃。尤其是做实验、测试新配置的时候，快照比备份恢复快得多。我自己每次要改netplan或者虚拟网络编辑器之前，都会先拍一张，改完验证没问题再删除。

5.3 几个保命小技巧

每次宿主机Windows更新之后，检查VMware服务是否被重置为手动。Windows的大版本更新有时候会重置第三方服务的启动类型，这个真遇到过。
不要随意卸载open-vm-tools。
在Ubuntu里配置好网络后，apt update 能过，不代表所有软件都能联网。pip、npm、git等工具的代理/镜像配置都要单独检查。
宿主机如果是笔记本，经常更换Wi-Fi或热点，虚拟机网络更容易异常，尽量给VMnet8和虚拟机都设固定IP。
排查网络问题的时候，用 ping 和 ip route 两个命令足够定位80%的问题，不要急着装各种网络管理工具。

5.4 给VMware网络进程放行防火墙规则

Windows防火墙拦截VMware程序是NAT模式下断网的一个隐性原因。在“允许应用通过防火墙”里，找到VMware Workstation和VMware NAT Service相关项，确保“专用”和“公用”都勾选。如果你所在的网络环境是公用网络（比如公司网络），这一项更容易被拦截。这个检查放在最后是因为，防火墙导致的断网通常不是第一次就出现的，而是某次Windows更新或网络类型切换之后才发生。

我在虚拟机网络这块踩过的坑，比在真实服务器上多得多。现在我的习惯是：新装的Ubuntu第一件事就是配好静态IP和DNS，然后拍一张快照，再执行apt update。遇到网络问题，先在Windows服务管理器和虚拟网络编辑器里花两分钟确认VMware侧是正常的，再进Ubuntu看网卡和DNS。按这个思路走，绝大多数断网问题都能在十分钟内解决。最后留个建议：排查过程记得记录下来，尤其是那些“改了一条配置就好了”的瞬间，下次遇到同样问题能省不少时间。希望这篇文章能帮你少走些弯路。