1. 先把故障边界摸清楚：NAT模式下网络到底走的是哪条路
遇到VMware里Ubuntu 25.10虚拟机NAT模式无法上网，先别急着改配置文件，也先别把虚拟网络编辑器里的参数一顿乱调。我见过太多人一上来就把VMnet8的网段改了，结果越改越乱，最后整个虚拟网络环境全废掉，反而更难排查。动手之前，花两分钟把NAT模式的网络路径理清楚，后面所有的排查步骤就都有依据了。
VMware的NAT模式，本质上就是让虚拟机通过宿主机做一层地址转换上网。虚拟机自己拿到的是一段私有IP，比如192.168.100.128，这个网段就是虚拟网络编辑器里VMnet8对应的子网。虚拟机发出去的数据包，先到达虚拟网关（通常就是192.168.100.2），虚拟网关再把源地址替换成宿主机物理网卡的IP，由宿主机送出到真实网络。响应数据回来之后，同样经过NAT转换再送回虚拟机。
这里有一个很关键的点：真实网络里的设备根本不知道这台虚拟机的存在，它们看到的只是宿主机在跟它们通信。这相当于虚拟机住在一个小区里，宿主机是大门保安，虚拟机的所有网络请求都由保安代传，外面的快递员只知道保安，不知道小区具体哪个住户。
搞清楚这条链路，你就能明白为什么NAT模式“偶尔连不上”会比桥接模式更让人头疼。因为链路上任何一环出问题都可能导致断网：宿主机自身没网、VMware的网络服务没启动、VMnet8虚拟网卡配置被篡改、虚拟机内部DHCP没续租、DNS解析卡住、防火墙拦截转发……每一个都有可能是罪魁祸首。所以我的排查原则就一条：从宿主机的物理链路开始，一层一层往虚拟机内部查，而不是跳来跳去。
下面这套排查流程，适用于Ubuntu 25.10，也适用于其它版本的Ubuntu，因为底层网络机制大同小异。你手里的系统版本号跟我写的不一样，没关系，排查逻辑完全一致。
2. 动手前先做三件事：确认现象、收集信息、找回基线
2.1 先判断故障现象到底属于哪一类
“无法上网”这四个字其实很笼统，我在群里见过不少朋友说上不了网，结果细问之下情况完全不一样：
- 虚拟机完全拿不到IP地址，
ip addr里网卡没有IPv4地址； - IP地址能拿到，网关也通，但ping不通外网IP；
- 外网IP能通，但域名解析不了，浏览器一直转圈；
- 某些域名能打开，另外一些打不开；
- 系统刚开机时能上，过一会儿就断了。
这几种现象对应的故障点完全不同。拿不到IP，优先查DHCP服务；网关不通，优先查VMware NAT服务和虚拟网络编辑器；外网IP能通但域名不通，基本就是DNS的问题；用着用着断掉，大概率是服务状态异常或网卡电源管理导致。所以不管你是从网上搜到这个标题，还是自己踩坑踩到这一步，第一步一定是先问清楚，或者先自己观察清楚：到底卡在哪一层。
2.2 确认宿主机自己能不能正常上网
这一步听起来像废话，但真的很容易被忽略。尤其是笔记本电脑，有时候系统显示WiFi已连接，但实际没有外网访问能力，或者公司办公网络本身就需要额外登录认证。如果宿主机本身就不能上网，那虚拟机里的NAT模式必然上不了网，这时候排查VMware纯粹浪费时间。
验证方式很简单：在宿主机上打开浏览器随便访问一个网站，或者打开命令行ping一个公共DNS服务器的IP，比如ping 223.5.5.5。如果宿主机ping不通外网IP，先把宿主机的网络修好再说，不用碰虚拟机。
注意：如果是公司网络或者校园网，还可能出现宿主机能上内网、不能上外网的场景。在这种网络环境里，虚拟机NAT模式的上网能力完全取决于宿主机的外网权限，这不是VMware的问题，别折腾虚拟机。
2.3 记录虚拟机当前网络状态，别急着改配置
在动任何配置之前，先进入Ubuntu系统里把现场信息抓出来。这就像出事故要先拍照片保存证据，后面改坏了还能对照着恢复。
打开终端，依次执行这几条命令：
ip addr show ip route show cat /etc/resolv.conf ping -c 4 192.168.100.2第一行看网卡状态和IP地址，第二行看默认路由，第三行看DNS配置，第四行测到NAT网关的连通性。其中网关地址要看你的VMnet8子网配置，通常就是子网地址的第二个IP，比如子网是192.168.100.0，网关一般就是192.168.100.2。如果你不确定，可以在Windows宿主机上打开虚拟网络编辑器查看。
把这几条命令的输出截图或者抄下来，后面排查全靠这些信息做判断。很多时候，问题真相就是在这几条命令的输出里直接暴露的。
3. Windows宿主机侧的三大高频元凶：服务、虚拟网卡、防火墙
3.1 VMware的NAT Service和DHCP Service到底还活着没有
Windows宿主机的服务列表里，有两个服务直接决定NAT模式能不能工作：VMware NAT Service和VMware DHCP Service。从名字就能看出来，一个负责NAT地址转换，一个负责给虚拟机分配IP。任何一个没运行，网络就废了。
排查方法非常直接，在Windows上按Win + R输入：
services.msc回车打开服务管理器，找到这两个服务，看看状态是不是“正在运行”，启动类型是不是“自动”。我遇到的情形五花八门：有的服务被安全软件优化工具禁掉了，启动类型变成了“手动”甚至“禁用”；有的服务虽然显示正在运行，但实际已经停止响应，需要重启；还有的系统更新之后，VMware服务的启动顺序出了问题，导致开机时没拉起来。
解决办法也简单，右键点击服务，选择“重新启动”。如果服务被禁用了，双击打开属性，把启动类型改成“自动”，先点击“启动”把服务拉起来，再点击“确定”保存。
经验之谈：笔记本用户如果经常休眠、合盖、切换WiFi，VMware NAT Service很容易罢工。我现在的习惯是：系统一开虚拟机就卡，第一件事先重启这两个服务。十次里有六次能直接解决。
另外补充一点：宿主机上如果安装了第三方防火墙，比如某些安全软件自带的网络防护模块，也可能拦截VMware的虚拟网卡流量。排查时可以先临时关闭第三方防火墙的防护，确认是不是它导致的，如果是，再加入白名单放行VMware相关进程。Windows自带的防火墙一般不会拦VMware虚拟网卡，但别忘了检查。
3.2 虚拟网络编辑器里的配置是不是被动了手脚
在Windows宿主机上打开VMware主界面，菜单栏找到“编辑”下的“虚拟网络编辑器”，这里维护着VMnet8的全部网络参数。正常情况下，NAT模式使用VMnet8，子网IP段、子网掩码、DHCP分配范围和NAT网关IP都有默认值。
检查几个关键参数：
- VMnet8是否选择了“NAT模式”，而不是“仅主机模式”；
- 子网IP是否和你虚拟机里看到的IP在同一网段；
- 是否勾选了“使用本地DHCP服务将IP地址分配给虚拟机”；
- NAT设置里的网关IP是不是子网网段内的合法地址。
如果发现参数异常，可以考虑直接点“使用默认设置”恢复VMnet8的默认配置。但这里要提醒一句：恢复默认设置会把整个虚拟网络配置重置，如果你之前手动配置过端口转发或者自定义网段，重置后都会丢失。所以操作前先把原来的配置截图存档。
还有一种情况比较隐蔽：宿主机物理网络环境发生变化后，VMnet8的网段和宿主机实际所在局域网网段产生了冲突。比如宿主机的WiFi所在网段正好也是192.168.100.0，而VMnet8的子网恰好也是这个网段，那么数据路由就会出现混乱。解决方法是把VMnet8改成一个不那么容易冲突的私有网段，比如192.168.237.0，同时确保不跟物理局域网、其它虚拟网卡网段重复。
3.3 虚拟网卡VMnet8在Windows侧的状态
VMnet8在Windows里体现为一张虚拟网卡。在Windows命令行里输入：
ncpa.cpl打开网络连接面板，找到VMware Network Adapter VMnet8。检查它的状态是不是“已启用”，IP地址是不是和虚拟网络编辑器里的配置对应。正常情况下，VMnet8的IPv4地址应该和VMnet8子网在同一个网段，通常略高于网关地址，比如192.168.100.1。
如果这张虚拟网卡被禁用，或者IP地址变成了“自动获取”但没能拿到地址，NAT模式也会出问题。手动给VMnet8设置一个静态IP，子网掩码和VMnet8配置保持一致，不需要设置网关，就能解决这层问题。
还有一个Windows侧的小坑：Windows更新偶尔会重置网卡配置，导致VMnet8的IP丢失或者与虚拟网络编辑器配置不一致。遇到这种问题，重新设置VMnet8的静态IP即可。
4. 虚拟机设置层面的坑：网卡连接、设备类型与MAC地址
4.1 确认虚拟机网卡处于“已连接”状态
很多人忽略这个最简单的设置。VMware的虚拟机设置里，每个网卡都有一个“已连接”复选框，还有“启动时连接”选项。如果“已连接”没勾选，或者当前运行状态下网卡被手动断开，虚拟机系统里当然看不到网络。
在VMware主界面，右键虚拟机选择“设置”，找到“网络适配器”，确认三个事情：
- “已连接”复选框是否勾选；
- “启动时连接”是否勾选；
- 网络连接方式是否是“NAT模式”。
如果之前为了排查问题切换过网络模式，比如改成过仅主机模式或者桥接模式，确认现在确实切回了NAT模式。
4.2 网卡类型的选择也有讲究
VMware支持多种虚拟网卡类型，常见的有e1000、vmxnet3、e1000e等。默认情况下VMware会根据客户操作系统的类型自动选择合适的虚拟网卡，通常不需要手动改。但如果你是从其它平台迁移过来的虚拟机，或者手动调整过网卡类型，可能出现“系统里根本认不出网卡”或者“网卡能认出来但性能极差”的情况。
查看当前网卡类型，可以在虚拟机设置里点开“网络适配器”的高级选项，或者直接看.vmx配置文件里的ethernet0.virtualDev字段。
如果网卡类型不匹配，Ubuntu系统内可能连eth0或ens33这样的接口都看不到，只有回环接口lo。遇到这种情况，把虚拟网卡类型改成VMware默认推荐的类型，重启虚拟机再试。
4.3 MAC地址冲突导致DHCP分配失败
另一个容易踩坑的地方是MAC地址。虚拟机的网卡MAC地址如果和宿主机所在局域网内某台设备的MAC冲突，虽然这是虚拟网络环境，但也有可能导致DHCP无法正常分配IP或者网络访问异常。
在VMware虚拟机设置里，网络适配器的高级选项中有MAC地址设置，默认是“自动”生成。如果之前复制过虚拟机、恢复过快照，MAC地址可能会变化。不要手动随意填一个MAC地址，除非你清楚自己在做什么。
有些朋友为了让虚拟机IP固定，会手动设置静态IP地址，但静态IP的配置如果和DHCP分配范围冲突，也会带来各种怪异现象。我建议第一次排查网络问题时，先把虚拟机内部改成DHCP自动获取，等网络通了再考虑固定IP的事情。
5. Ubuntu 25.10内部的网络配置与排查
5.1 先搞清楚系统用的是NetworkManager还是netplan
进入Ubuntu系统之后，第一步要判断当前系统的网络管理方式。Ubuntu 25.10桌面版默认使用NetworkManager，服务器版通常使用netplan搭配systemd-networkd。这两种方式的管理命令完全不同，如果你用错工具去排查，很容易误判。
判断方法很简单，执行：
nmcli device status如果返回结果里有设备的连接状态信息，说明NetworkManager在运行。如果提示命令不存在，或者显示设备状态为“未托管”，说明网络可能由netplan管理。
桌面版的Ubuntu用户，我建议优先使用系统右上角的网络设置图形界面来查看连接状态。如果图形界面显示“已连接”，但实际ping不通，再用命令行深挖。
5.2 DHCP获取地址是否正常
虚拟机内的网卡如果通过DHCP获取地址，默认情况下应该能拿到192.168.100.x网段的IP。如果ip addr里网卡显示没有IPv4地址，或者地址是169.254.x.x这样的APIPA地址，说明DHCP过程失败。
104.254.x.x这个地址是个标志性信号，说明网卡尝试自动配置私有IP但没有找到DHCP服务器。出现这种情况，优先检查VMware的DHCP Service是否在运行。
如果网卡没有获取IP，可以先尝试让NetworkManager重新激活连接。用命令行操作：
nmcli connection show nmcli connection up ens33如果还是无法获取地址，可以强制走一次DHCP流程：
sudo dhclient -r ens33 sudo dhclient -v ens33看到DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK的完整流程，才说明DHCP链路是通的。如果卡在DHCPDISCOVER阶段没有任何回应，问题基本就在宿主机侧的DHCP服务上。
5.3 静态IP配置里的经典错误
有些朋友为了省事，直接在Ubuntu里配置静态IP，结果反而给自己挖了坑。常见的错误包括：
- 网关IP写错，写成了子网地址本身，或者写成了宿主机的IP；
- 子网掩码写错，导致路由判断异常；
- DNS没有配置，导致域名解析失败；
- 配置了静态IP，但没有设置默认路由。
修改Ubuntu的网络配置，不同管理方式操作位置不同。netplan方式的配置文件在/etc/netplan/目录下，通常是.yaml后缀。改完执行sudo netplan apply生效。NetworkManager方式可以编辑连接配置，或者用图形界面操作。
如果你不熟悉这些配置格式，我强烈建议先把网络方式改回DHCP自动获取，确认网络通了之后，再研究静态IP的写法。不要在一个有多个变量的环境里同时改好几个配置。
6. DNS解析异常：能上QQ不能开网页的真相
6.1 用IP和域名分别测试，快速锁定是不是DNS问题
判断是否为DNS问题，方法非常简单。在Ubuntu虚拟机内执行：
ping -c 4 223.5.5.5这是阿里云公共DNS的IP地址，ping通说明外网链路是通的，且NAT转换正常工作。然后再执行：
ping -c 4 www.baidu.com如果第一条命令能通，第二条命令提示ping: www.baidu.com: 临时解析失败或者超时，那么问题就锁定在DNS解析环节。
还有一种情况：IP能通，域名也能解析，但网页加载不出来。这可能涉及HTTP层面的问题，比如MTU设置、IPv6优先级、代理设置等。但这个概率相对较低，绝大多数情况下，还是DNS配置不对。
6.2 systemd-resolved和/etc/resolv.conf的关系
Ubuntu系统上，默认使用systemd-resolved处理DNS解析。打开/etc/resolv.conf文件看，内容通常会指向127.0.0.53，这是systemd-resolved的本地解析器，而不是直接的公共DNS地址。所以如果你编辑/etc/resolv.conf添加DNS服务器，可能会发现重启系统后又被覆盖，因为这是被systemd-resolved管理的。
查看当前系统实际生效的DNS配置，可以执行：
resolvectl status重点关注“当前DNS服务器”和“DNS域名”等字段。如果发现DNS配置为空或者指向了不可达的地址，就需要修改配置。
6.3 给虚拟机配置一个可靠的DNS
对于NAT模式的虚拟机，最简单的DNS配置是使用和宿主机相同的DNS服务器，或者直接使用公共DNS。2025年这个时间点，比较常用的是：
- 223.5.5.5 和 223.6.6.6（阿里DNS）
- 119.29.29.29（腾讯DNS）
- 8.8.8.8 和 8.8.4.4（谷歌DNS）
NetworkManager方式下，可以编辑连接设置，在IPv4设置里添加DNS服务器。netplan方式则直接在yaml配置文件的nameservers字段中加入DNS地址。
改完配置后，重启网络服务或者重启虚拟机，然后重新测试解析：
nslookup www.baidu.com能返回正常的IP地址，说明DNS配置生效。
还有一个小细节：如果你在宿主机上使用的是公司内部DNS，那么虚拟机里也填这个内部DNS可能无法解析外网域名，因为NAT模式下虚拟机的DNS请求会直接发往指定DNS服务器，而不是必然经过宿主机的DNS代理。所以虚拟机内直接填公共DNS通常是最省心的做法。
7. 我踩过的几个坑与对应的解决办法
7.1 坑一：笔记本合盖休眠后虚拟机突然断网
这个坑我踩了不止一次。笔记本电脑合盖再打开，或者系统从睡眠状态唤醒之后，虚拟机里的Ubuntu网络经常就断了。检查宿主机能正常上网，虚拟机里IP地址也显示正常，但就是ping不通网关。
这个问题的根源在于虚拟机恢复运行时，VMware的服务和虚拟网卡状态没有同步恢复。解决方案分两步：先重启VMware NAT Service和DHCP Service，再在虚拟机系统里执行一次网卡重启。
sudo ip link set ens33 down sudo ip link set ens33 up或者用NetworkManager方式：
nmcli connection reload nmcli connection up ens33如果不想每次手动处理，可以在虚拟机开机自启动脚本里加一条测试网络连通性的逻辑，不通就自动重置网卡。但最省心的方式还是习惯性重启两个Windows服务。
7.2 坑二：物理机切换WiFi导致虚拟机网络失效
办公环境里经常需要切换WiFi，比如从办公室网络切到手机热点，虚拟机网络有时候就会失效。原因是宿主机物理网卡的IP和路由发生了变化，但VMware的NAT服务没有及时更新外部网络接口的路由。
解决办法是在Windows宿主机上重启VMware NAT Service。如果重启之后虚拟机还是不通，尝试把虚拟网络编辑器里的VMnet8网段改换一下，再改回去，强制NAT服务刷新配置。
7.3 坑三：Ubuntu的systemd-resolved占用53端口
我之前在一台Ubuntu 25.10虚拟机里跑DNS相关的服务时，发现启动失败。最终查出来是systemd-resolved默认占用了127.0.0.53的53端口，导致自定义DNS服务端口冲突。
如果你的目标不是跑DNS服务，而是单纯解决上网问题，这个坑一般不会遇到。但如果你在排查过程中尝试在虚拟机里安装或启动DNS服务，要意识到这个端口占用问题。
7.4 坑四：克隆虚拟机后网卡名称变了
从模板克隆出来的虚拟机，Ubuntu里的网卡名称可能从原来的ens33变成了ens160，或者变成eth0。原因在于克隆操作改变了网卡的MAC地址和PCI槽位信息，系统生成了新的接口名称。
这个变化会导致原有的网络配置文件失效，甚至连NetworkManager的连接配置都对不上。解决办法是在系统里确认新的网卡名称，然后重新建立连接配置。执行ip addr看清楚当前网卡叫什么，然后：
nmcli connection delete "Wired connection 1" nmcli device connect ens160或者针对netplan的方式，修改yaml文件中的接口名称，重新netplan apply。
8. 如果上面全都没用，最后的干净三板斧
8.1 重置虚拟网络编辑器到默认状态
如果经过前面所有排查还是不通，可以尝试在虚拟网络编辑器里点击“更改设置”，然后找到“恢复默认设置”按钮。这个操作会把所有虚拟网络（VMnet0、VMnet1、VMnet8等）恢复到安装VMware时的初始状态。
恢复默认设置之后，重新打开虚拟机的网络适配器，确认还是NAT模式，然后启动虚拟机测试。
这一步能解决大部分因为配置错乱导致的奇怪网络问题。但也有代价：如果你之前配置过端口转发，这些规则都会丢失，需要重新配置。
8.2 修复安装VMware
Windows的“设置”里找到“应用”，在已安装的应用列表里找到VMware软件，选择“修改”或“修复”，重新运行安装程序进行修复安装。修复过程会重新注册Windows服务、重置虚拟网卡驱动、恢复默认配置文件。
修复安装不需要卸载虚拟机里的系统，已创建的虚拟机文件都还在，可以放心操作。
8.3 临时切换到桥接模式验证故障边界
最后还有一招，能帮你判断到底是NAT服务的问题，还是Ubuntu系统内部的问题：把虚拟机的网络适配器临时改成桥接模式。
如果桥接模式能够正常上网，说明Ubuntu系统内部网络配置没有问题，问题出在NAT服务或者VMnet8虚拟网络上。如果桥接模式也不通，那问题就出在Ubuntu系统内部网络配置，比如防火墙、网卡驱动、路由表等。
注意，桥接模式下虚拟机需要和宿主机在同一局域网才能上网，如果你的物理网络环境不允许（比如公司网络有MAC地址白名单），这个方法可能不适用。
9. 按经验排序的排查顺序与小技巧
说了这么多，最后给你一个我个人的经验总结，按优先级排序，照着做能节省大量时间。
第一，90%以上的NAT模式网络故障，出在Windows宿主机侧的VMware服务和虚拟网络编辑器上。所以优先检查VMware NAT Service和VMware DHCP Service。
第二，如果你动了虚拟网络编辑器，记住一个原则：VMnet8子网不应该与宿主机所在的物理局域网网段相同。比如宿主机连着192.168.50.0的WiFi，VMnet8就别再用192.168.50.0，改成192.168.237.0这样不冲突的网段。
第三，物理网络环境变化（休眠、切WiFi、换网线）之后，虚拟机网络异常，先重启VMware服务。
第四，Ubuntu系统内的DNS配置，直接写成公共DNS地址，不要依赖宿主机转发。
第五，不要同时修改多个变量。想排查问题，就一次只改一个配置项，改完立即测试，确认通了再改下一个。最怕的就是VMware服务、VMnet8网段、Ubuntu静态IP、DNS四样一起改，结果出了问题根本不知道是哪一步弄坏的。
按照这套思路走下来，VMware NAT模式下Ubuntu 25.10无法上网的问题，绝大多数情况下都能被迅速定位并解决。希望这份经验总结能帮你少走弯路。
