重启VM虚拟机后连不上网，绝大多数是VMware桥接服务没启动或虚拟网卡IP冲突，优先检查Windows服务里的VMware DHCP/NAT服务，再重置虚拟网络编辑器。本文把排查思路按出现频率排序,一步步带你找回网络。
先分清是宿主机断网还是虚拟机单方面断网
不要把时间浪费在虚拟机里配IP，先看一眼物理机自己能不能上网页。宿主机断网，源头在路由器、宽带或物理网卡，跟VMware没半毛钱关系。宿主机正常，只有虚拟机掉线,才进入下面流程。
打开虚拟机终端,先看网卡有没有拿到地址：
- Windows虚拟机，在CMD里输入
ipconfig /all，重点看IPv4地址是不是169.254开头的自动私有地址 - Ubuntu/CentOS虚拟机，在终端里输入
ip a，观察网卡状态是UP还是DOWN，有没有显示inet地址段
254.x.x 说明DHCP压根没分配IP，属于虚拟机网络服务层面的故障。网卡DOWN说明系统层面把网卡禁用了，属于驱动或配置的故障，两者排查方向完全不同,别混着修。
vmware虚拟机连不上网络怎么办：按权重拆解五大原因
结合日常运维场景，把“vmware虚拟机连不上网络怎么办”这个高频搜索词对应的根因，按出现概率排个序，你从第一个开始对号入座,多数人卡在第二和第三个。
Windows宿主机：VMware相关服务处于停止状态
VMware桥接和NAT模式依赖Windows后台服务，服务没起来，虚拟机就像拔了网线的电脑，界面里怎么点都没用。重启虚拟机后尤其容易触发服务假死，因为VMware进程异常退出后没来得及回收虚拟网卡,服务和网卡状态就错乱了。
按下 Win+R，输入 services.msc,在服务列表里找下面三项：
VMware DHCP Service（VMeDCHCP）负责给NAT模式虚拟机分配IPVMware NAT Service（VMware NAT Service）负责NAT模式转发流量VMware Authorization Service（VMware Authorization Service）负责虚拟机访问权限控制
每项都右键点击启动，如果已经是“已启动”状态，右键选择重新启动，行业共识认为，重启这三个服务后，超过一半的虚拟机上不了网问题能直接解决，操作完不急着开虚拟机，先把宿主机物理网卡禁用再启用一次,让虚拟网卡重新绑定物理网络通道。
如果你的VMware安装在中文路径或者被安全软件拦过启动项，服务可能设置成“手动”但没触发器，顺手把启动类型改成自动,防止下次重启又断网。
虚拟网络编辑器里的子网网段和物理网卡冲突
这是Windows上第二大坑，VMware默认NAT模式使用168.x.x网段，如果你的家庭路由器或公司内网正好也是168.x.x开头，两边的DHCP就打架了，IP分配互相踩踏，虚拟机能拿地址但上不了外网,甚至和宿主机都ping不通。
打开VMware菜单栏的 编辑 → 虚拟网络编辑器，点右下角更改设置获取管理员权限，选中VMnet8（NAT模式）,把子网IP改成一个冷门私有网段，
-
16.88.0子网掩码255.255.0 10.55.0子网掩码255.255.0
顺手把DHCP设置里的地址池起始和结束范围改成新网段内的数值，例如起始16.88.128、结束16.88.200，避免租约冲突，改完点应用，NAT模式下虚拟机通常无需手动改IP,重启虚拟机即自动获取新网段地址。
网卡被系统休眠或电源管理策略断开
笔记本用户很容易踩这个雷，虚拟机系统里，虚拟网卡被Windows的电源管理当成了可休眠设备，宿主机睡眠唤醒后，网卡没跟着唤醒，虚拟机里看起来一切正常,但数据包已经卡死在网卡驱动层。
解决方案：进入宿主机的 设备管理器 → 网络适配器，找到所有带“VMware”前缀的虚拟网卡，右键属性，切换到电源管理选项卡，取消勾选“允许计算机关闭此设备以节约电源”，注意，这台宿主机上的所有VMware虚拟网卡都要改,漏一个就白改。
DHCP租约过期或虚拟交换机端口老化
虚拟机长时间挂起（挂起状态下宿主机也关机了），再恢复运行时，DHCP租约早过期了，虚拟交换机端口保留了旧的MAC绑定关系,新租约分配不过来。
重拳做法：把虚拟机的网络适配器先改为“仅主机模式”，应用后再改回“NAT模式”，强制网卡重新初始化，操作路径是 虚拟机 → 设置 → 网络适配器，改完开机，观察网卡是否重新发起DHCP广播，如果还不行，直接用root身份进入虚拟机系统,清理ARP和DHCP缓存：
- Ubuntu/Debian：
sudo dhclient -rsudo dhclient - CentOS/RHEL：
sudo dhclient -r eth0再sudo dhclient eth0
宿主机防火墙或第三方杀毒拦截虚拟网卡流量
这个属于小众因素，Windows自带的防火墙如果开了“阻止所有传入连接”，VMware NAT服务的数据流转会被卡住，杀毒软件的“网络防护”模块也经常扫描虚拟网卡。
先做排除法：临时关闭Windows防火墙，看虚拟机能否上网，能上，就给VMware相关进程加防火墙放行规则，千万别靠全关防火墙当长期方案，第三方杀毒软件里，把vmware-vmx.exe、vmware-netcfg.exe加入信任区，再把“网络防护”的监控对象里排除虚拟网卡。
vm虚拟机重启后网络不可用：恢复实操四步走
“vm虚拟机重启后网络不可用”是个很典型的场景词，描述的是重启前一切正常、重启后立刻失联，这类故障大多不是配置错误，而是环境残留，按顺序做,一步到位。
第一步：Ping宿主机网关来定位故障层
先别急着改配置，用命令定位是网络不通还是路由不通,在虚拟机终端里依次执行：
ping 宿主机IP通说明二层链路OK，虚拟网卡驱动正常ping 网关IP通说明NAT服务在干活，问题出在路由表ping 8.8.8.8通说明外网通路OK，问题只剩下DNS解析ping baidu.com通说明万事大吉
不同层级的反馈指向完全不同的修复方案，ping得通网关但ping不通8.8.8.8，优先看NAT服务的路由转发，和虚拟机系统里的默认路由表，如果全部超时,回到上文第二个H2的服务检查和网段看一遍。
第二步：重启虚拟网络适配器
Windows虚拟机为例，管理员身份打开CMD,执行：
netsh interface set interface "以太网" disabled
netsh interface set interface "以太网" enabled网卡名不确定就先跑 netsh interface show interface 看清楚，Linux虚拟机则用 nmcli networking off 再 nmcli networking on 重播网卡状态,这一步主要解决驱动和虚拟交换机端口之间的僵死会话。
第三步：重建VMware NAT和DHCP进程
VMware在Windows下提供了命令行重置手段，管理员身份打开CMD，进入VMware安装目录（默认路径 C:Program Files (x86)VMwareVMware Workstation）,依次执行：
vmnetcli.exe --stop
vmnetcli.exe --start这个命令会完整停掉虚拟网络栈并重新拉起所有VMware后台网络进程，比起在服务管理器里手工点击，它能顺便回收虚拟网卡句柄，vSphere或ESXi环境则登录Web管理端,重启对应虚拟交换机和端口组。
第四步：写死静态IP，跳过DHCP依赖
如果你频繁遭遇重启后IP丢失问题，直接给虚拟机的NAT网卡配置固定IP，不再依赖DHCP，把虚拟网络编辑器里的网段固定在某个值，比如168.88.0/24，然后在虚拟机系统里把IP设为168.88.10，网关指向168.88.2（VMware NAT网关默认是x.x.x.2），DNS填168.88.2或114.114.114,就再也不用管DHCP状态了。
Windows虚拟机的配置路径是 控制面板 → 网络和共享中心 → 更改适配器设置 → IPv4属性，Ubuntu桌面版则进 设置 → 网络 → IPv4 → 手动，这种方式对无GUI的Server版尤其好用，直接用 nmtui 或编辑 /etc/network/interfaces 写入静态配置。
Ubuntu和CentOS虚拟机重启断网的单独注意事项
Linux发行版对网卡命名和管理方式和Windows差异较大，Ethernet接口名在Ubuntu 18.04+后已改称ens33或ens160，CentOS新版本则带UUID绑定规则，重启后网络失效，相当一部分原因在Netplan服务没正确加载或NetworkManager与systemd-networkd打架。
- Ubuntu 18.04及以上用Netplan，配置文件在
/etc/netplan/.yaml，改完必须跑sudo netplan apply - CentOS 8及以上默认用NetworkManager，使用
nmcli管理连接，别直接手改ifcfg-ens33文件再重启，要用nmcli connection reload重新加载
在Ubuntu里重装open-vm-tools能解决一部分内核与虚拟网卡驱动的兼容性问题：
sudo apt remove --purge open-vm-tools
sudo apt install open-vm-tools重装完成后reboot一次，驱动模块vmxnet3会重新编译加载，虚拟机最小化安装缺了open-vm-tools的话，网络是不可能的,装上再谈。
宿主机是Mac或Linux时的虚拟网络特殊处理
Vware Fusion和Linux版VMware Workstation的网络栈工作机制和Windows版有出入，Fusion里NAT网关通常用vmnet8界面管理，如果笔记本切换过Wi-Fi或有线网段,虚拟机的NAT网关不会自动跟着宿主机网段变迁。
Mac宿主机上，把虚拟机的网络模式切到“与Mac共享”，让Fusion代理转发网络流量，再去 系统偏好设置 → 网络 确定当前活跃网卡是哪个，Linux宿主机上，敲systemctl status vmware看服务状态，必要时systemctl restart vmware重启整个VMware守护进程，部分Arch系宿主机还有个坑vmware-networks-configurator服务未启用,会导致每次开机VMware网络功能不完整。
低成本替代方案：VMware网络搞不定时换VirtualBox应急
如果你急需联网，别在VMware网络配置上耗一下午，把虚拟机导出成OVF格式（文件 → 导出 → 导出为OVF），然后用Oracle VirtualBox导入，关掉VMware，VirtualBox的默认NAT模式开箱即用，不需要任何服务或虚拟网络编辑器配置，这个挪窝方案对临时救急特别香，仅限非生产环境，生产环境还是踏实排查问题,别轻易换平台。
顺带回答一个关联疑问：vmware pro收费吗VMware Workstation Pro针对个人用户已提供免费许可，商用场景才涉及授权费用，网上流传的“VMware全面收费”说法不准确，个人学习使用可以直接从官网下免费版，和本文故障排查操作完全一致,不影响后续使用成本。
关于VM虚拟机重启后连不上网的三个高频追问
虚拟机里看不到以太网适配器，怎么办？
网卡在设备管理器里直接消失，多半是VMware Tools未正确安装或版本不匹配，Windows虚拟机里重新运行VMware Tools安装包（虚拟机 → 安装VMware Tools），选择修复模式，完成后重启，Linux虚拟机则检查内核模块：lsmod | grep vmnet，无输出就执行 vmware-modconfig --console --install-all 重新编译内核模块。
DHCP获取的IP和宿主机同一网段但上不了外网？
这个现象基本指向NAT模式误配成了桥接模式，桥接模式下虚拟机直接融入物理局域网，路由器没给虚拟机MAC放行，外网自然不通，把虚拟机网络模式改回NAT（VMnet8），让虚拟机走虚拟网关转发流量，外网即恢复，桥接模式适合需要局域网互访的场景，NAT模式下如果还需要对外提供服务，就用虚拟网络编辑器加一条端口转发规则,把宿主机的某个端口映射到虚拟机的22或80端口。
VMware虚拟机重启后桥接模式可以ping通网关，但ping不通局域网其他电脑？
桥接模式和物理网卡绑定错位了，打开 虚拟网络编辑器 → 桥接模式 → 桥接到，确认下拉菜单里选择的物理网卡和当前正在上网的网卡一致，笔记本电脑同时插着网线和Wi-Fi时，选了Wi-Fi网卡但实际走的是有线网络，就会出现这个半通不通的现象，该下拉框改成“自动”让VMware自行判断，或者直接指定当前活跃网卡,问题立即消失。
虚拟化网络的稳定核心就是服务、网段、网卡绑定三个层面的协调一致，重启后掉线不是什么复杂玄学，把Windows服务列表拉出来看一遍，再检查网段是否冲突，九成场景能完成修复，最后留一句大实话：任何时候先确认宿主机本身联网正常，再去折腾虚拟网络配置，能省下至少一半排查时间。