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服务的启动顺序出了问题导致开机时没拉起来。解决办法也简单右键点击服务选择“重新启动”。如果服务被禁用了双击打开属性把启动类型改成“自动”先点击“启动”把服务拉起来再点击“确定”保存。经验之谈笔记本用户如果经常休眠、合盖、切换WiFiVMware 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阿里DNS119.29.29.29腾讯DNS8.8.8.8 和 8.8.4.4谷歌DNSNetworkManager方式下可以编辑连接设置在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 修复安装VMwareWindows的“设置”里找到“应用”在已安装的应用列表里找到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的WiFiVMnet8就别再用192.168.50.0改成192.168.237.0这样不冲突的网段。第三物理网络环境变化休眠、切WiFi、换网线之后虚拟机网络异常先重启VMware服务。第四Ubuntu系统内的DNS配置直接写成公共DNS地址不要依赖宿主机转发。第五不要同时修改多个变量。想排查问题就一次只改一个配置项改完立即测试确认通了再改下一个。最怕的就是VMware服务、VMnet8网段、Ubuntu静态IP、DNS四样一起改结果出了问题根本不知道是哪一步弄坏的。按照这套思路走下来VMware NAT模式下Ubuntu 25.10无法上网的问题绝大多数情况下都能被迅速定位并解决。希望这份经验总结能帮你少走弯路。 
长河君 · 2026/10/16 3:39:39 · 阅读 1.2k VMware NAT模式下Ubuntu虚拟机无法上网的排查指南
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服务的启动顺序出了问题导致开机时没拉起来。解决办法也简单右键点击服务选择“重新启动”。如果服务被禁用了双击打开属性把启动类型改成“自动”先点击“启动”把服务拉起来再点击“确定”保存。经验之谈笔记本用户如果经常休眠、合盖、切换WiFiVMware 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阿里DNS119.29.29.29腾讯DNS8.8.8.8 和 8.8.4.4谷歌DNSNetworkManager方式下可以编辑连接设置在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 修复安装VMwareWindows的“设置”里找到“应用”在已安装的应用列表里找到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的WiFiVMnet8就别再用192.168.50.0改成192.168.237.0这样不冲突的网段。第三物理网络环境变化休眠、切WiFi、换网线之后虚拟机网络异常先重启VMware服务。第四Ubuntu系统内的DNS配置直接写成公共DNS地址不要依赖宿主机转发。第五不要同时修改多个变量。想排查问题就一次只改一个配置项改完立即测试确认通了再改下一个。最怕的就是VMware服务、VMnet8网段、Ubuntu静态IP、DNS四样一起改结果出了问题根本不知道是哪一步弄坏的。按照这套思路走下来VMware NAT模式下Ubuntu 25.10无法上网的问题绝大多数情况下都能被迅速定位并解决。希望这份经验总结能帮你少走弯路。