李一雷说个真实经历。前阵子在一台新装的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配置。任何一个环