很多朋友装好VMware Workstation，虚拟机一开机就发现上不了网，或者能上网但宿主机怎么都访问不到虚拟机里的服务，来回改配置、重启网络，折腾半天也不明白问题出在哪。这篇文章就是把我这些年折腾 VMware 虚拟机网络配置的经验做一次完整梳理，从三种网络模式的原理区别、虚拟网络编辑器的关键参数，到虚拟机内部系统（Windows、Ubuntu、Rocky Linux）的具体配置方法，再到常见故障的排查套路，一次讲清楚。无论你是刚接触虚拟机的新手，还是要在虚拟机里搭开发环境的程序员，或者需要做网络实验的运维，这篇总结都能帮你少踩很多坑。
1. 三种网络模式选型：桥接、NAT、仅主机到底怎么选
打开VMware Workstation的任意一台虚拟机设置，网络适配器一栏会看到几个选项：桥接模式、NAT模式、仅主机模式，还有“自定义”。很多人直接默认NAT，结果发现宿主机访问不了虚拟机；有人选了桥接，结果虚拟机反而直接没网。其实这三种模式对应三种完全不同的虚拟网络拓扑，理解清楚之后选型就很简单。
1.1 桥接模式：让虚拟机变成局域网的“原生成员”
桥接模式说白了就是让虚拟机直接“插”在你家的路由器上，和宿主机平起平坐。VMware通过虚拟网卡VMnet0，把宿主机的物理网卡和虚拟机的虚拟网卡“桥”在一起。这个时候虚拟机的IP由外部路由器（或者你家宽带的DHCP服务器）分配，和宿主机处于同一个网段，互相访问非常方便，其他局域网设备也能直接访问虚拟机，就像局域网里多了一台独立的电脑。
这个模式最大的优势是网络环境干净、与物理网络完全一致，适合需要对外提供服务的场景，比如在虚拟机里开一个Web服务给局域网同事测试，或者做网络抓包实验。但代价是它强依赖物理网络环境：如果路由器绑定了MAC地址过滤，或者DHCP地址池满了，虚拟机就分不到IP；笔记本在Wi-Fi和有线之间来回切换时，桥接网卡也容易绑定错物理网卡，导致网络时断时续。我自己就遇到过好几次，插着网线一切正常，一拔网线切到Wi-Fi，虚拟机立刻掉线，就是因为VMnet0默认绑定了有线网卡。后面会讲到在虚拟网络编辑器里手动指定网卡。
1.2 NAT模式：宿主机当“隐形路由器”
NAT模式应该是大多数用户最常用的模式，也是VMware默认采用的模式。原理上，VMware在宿主机内部架设了一个虚拟路由器（VMnet8），虚拟机先把数据包交给这个虚拟路由器，再由宿主机物理网卡统一转发出去。对外部网络来说，所有虚拟机都“隐藏”在宿主机后面，从外面看只能看到宿主机的IP，访问不到虚拟机内部。
这个模式的优点很明显：只要宿主机能上网，虚拟机一般就能上网，不需要关心路由器怎么配，也不用管当前是Wi-Fi还是有线，天然具备隔离性。缺点是虚拟机对外不可见，局域网里的其他设备不能直接访问它。但注意，宿主机和虚拟机都在VMnet8这个虚拟网络里，所以宿主机是可以用虚拟机IP直接访问它的。适合的场景是：日常学习、装测试环境、虚拟机里编译代码、跑数据库这类不要求被外部设备直接访问的用途。
1.3 仅主机模式：与世隔绝的封闭实验室
仅主机模式对应VMnet1，VMware会创建一个虚拟交换机，但只允许宿主机和虚拟机之间通信，完全不出宿主机。它和NAT的区别在于没有NAT网关，所以在仅主机模式下，虚拟机默认上不了外网，除非你在宿主机上开启Internet连接共享（ICS），或者自己搭软路由。
仅主机模式适合做网络隔离实验、安全测试，以及不需要外网但需要和宿主机大量交换数据的场景。我一般用它来模拟一个“干净的隔离内网”，在里面搭建多台虚拟机组网测试，这样数据不经过物理网卡，速度和安全性都有保证。
1.4 选型建议：按场景快速匹配
我把选型逻辑整理成一张表，你可以直接对照：
| 使用场景 | 推荐模式 | 理由 |
|---|---|---|
| 跑Web服务给局域网同事访问 | 桥接 | 虚拟机直接获得局域网IP，别人能直接访问 |
| 日常上网、装软件、练Linux命令 | NAT | 宿主机能上网虚拟机就能上网，省事 |
| 和宿主机交换文件、跑数据库 | NAT | 宿主机可直连VMnet8网段里的虚拟机 |
| 搭建隔离实验网络、模拟内网环境 | 仅主机 | 物理网络完全隔离，可控性最强 |
| 多台虚拟机组成内部服务集群 | 仅主机或自定义VMnet | 统一网段，不受路由器影响 |
| 笔记本常切换Wi-Fi和有线 | NAT | 桥接容易绑错物理网卡，NAT没有这个烦恼 |
一句话总结：拿不准就用NAT，需要被外部直接访问就用桥接，要纯隔离就仅主机。这个准则我用了很多年，基本没翻过车。
2. 虚拟网络编辑器设置：改网段、开DHCP、做端口转发
2.1 先搞清楚VMnet0、VMnet1、VMnet8是什么
VMware Workstation安装完成后，会在宿主机里创建几个虚拟网络设备，对应关系是：VMnet0用于桥接模式，VMnet1用于仅主机模式，VMnet8用于NAT模式。在菜单“编辑 → 虚拟网络编辑器”里能看到它们的网段、DHCP开关、子网掩码等信息。
注意，这个界面里显示的是“虚拟网络”，不是物理网络。VMnet后面的编号只是个标签，VMnet0可以是桥接，VMnet1可以是仅主机，这些都可以在“VMnet信息”栏里动态调整。如果你需要额外的隔离网络，比如同时建三个互不干扰的虚拟内网，可以直接点击“添加网络”创建VMnet2、VMnet3，类型设为“仅主机模式”，之后在虚拟机设置里的网络适配器中选择“自定义”，再指定对应的VMnet编号即可。
2.2 修改NAT网段：把默认的192.168.x.0换成你习惯的网段
默认情况下，VMnet8的NAT网段是192.168.x.0/24，其中网关是192.168.x.2，宿主机在VMnet8上的地址是192.168.x.1，DHCP分配范围从192.168.x.128到192.168.x.254。如果你只是拿来练手，默认配置完全够用；但如果你有多套VMware环境，或者虚拟机要和宿主机上其他服务共用网段，最好换成一个不容易冲突的地址，比如192.168.88.0/24。
操作步骤我习惯这么走：
- 打开“编辑 → 虚拟网络编辑器”，选中VMnet8。
- 如果勾选了“使用本地DHCP服务”，先取消勾选，避免后续改网段时DHCP配置产生干扰。
- 在“子网IP”处填想要的网段，比如192.168.88.0，子网掩码保持255.255.255.0。
- 点击“NAT设置”，确认或修改网关地址，默认是192.168.88.2，一般不用动。
- 重新勾选“使用本地DHCP服务”，再点击“DHCP设置”，把地址池起始地址改成192.168.88.128，结束地址改成192.168.88.254，租用时间保持默认。
- 应用保存，VMware会提示网络服务重启，确认即可。
这里有一个常见坑：修改完NAT网段后，之前虚拟机里已经配置好的静态IP会全部失效。如果是用DHCP动态获取的，重启虚拟机网络一般会自动适配；但如果是手动写死的IP，不改虚拟机内部配置，虚拟机就永远停留在旧网段里，表现出来就是“上不了网”。
2.3 端口转发：让宿主机通过自己的IP访问虚拟机服务
NAT模式有个很方便的功能叫端口转发。比如虚拟机里跑了一个Web服务监听80端口，你想在宿主机上用 http://127.0.0.1:8080 直接访问这台虚拟机，就可以在虚拟网络编辑器里选中VMnet8，点击“NAT设置”，在“端口转发”处添加一条规则：主机端口填8080，虚拟机IP填192.168.88.128，虚拟机端口填80，协议选TCP。这样所有发往宿主机8080端口的请求，都会被VMware的NAT服务自动交给虚拟机里的Web服务。
端口转发的本质是NAT网关上的DNAT规则，和路由器上的端口映射是一回事。设置时注意三点：主机端口不要和宿主机自己监听的服务冲突；协议要分清TCP和UDP；如果虚拟机里有多个Web服务，每个服务都要单独加一条转发规则，比如8081对应一个站点、8082对应另一个站点。我实测过，这个功能在VMware Workstation Pro里表现很稳定，做本地开发联调非常顺手。
2.4 恢复默认设置：听起来省事，实际要慎用
虚拟网络编辑器右下角有个“恢复默认设置”按钮，会把所有VMnet网段、DHCP配置、NAT规则全部重置。很多人虚拟机网络一乱就点它，结果原有的端口转发规则、自定义网段全部消失，虚拟机内部配置也跟着乱套，反而更麻烦。
我的建议是：只有两种情况才点它。一是VMware自带网络服务出现异常且无法修复，二是你用的是全新环境，还来得及重新规划网络。平时只是想改某个网段，老老实实按2.2的步骤来。另外，改网络配置之前最好先给虚拟机打一个快照（虚拟机菜单 → 快照 → 拍摄快照），如果配置改坏了，马上就能回到之前的状态。这个习惯能帮你省下大量时间。
3. 虚拟机系统内网卡配置实操：Windows、Ubuntu、Rocky Linux一次配通
虚拟网络编辑器负责的是“虚拟交换机”那一侧，虚拟机内部的网络配置是另一半。两边的网段必须对得上，网络才能通。这一章把最常见的几个guest系统的配置方法讲清楚，顺便解释为什么要这么配。
3.1 Windows虚拟机：图形界面点几下就搞定
Windows虚拟机最简单。虚拟机设置里把网络适配器选成NAT模式，进入系统后，打开控制面板 → 网络和共享中心 → 更改适配器设置，找到对应的以太网适配器，右键属性，双击“Internet协议版本4（TCP/IPv4）”。
如果不想管IP怎么分配，就保持“自动获得IP地址”和“自动获得DNS服务器地址”不变；如果想让IP固定下来，就选择“使用下面的IP地址”，填一个和VMnet8同网段的地址，比如192.168.88.100，子网掩码255.255.255.0，默认网关填192.168.88.2，DNS可以填223.5.5.5或者你所在网络常用的DNS。
配完后点“确定”关掉窗口，按顺序做三步验证：先ping 192.168.88.2（NAT网关），再ping 192.168.88.1（宿主机在VMnet8上的地址），最后ping 223.5.5.5。三步都通，说明虚拟机到网关、到宿主机、再到外网全链路都是通的。
3.2 Ubuntu虚拟机：新版用netplan，别再去改/etc/network/interfaces了
Ubuntu 18.04之后的版本已经全面转向netplan，网络配置文件在/etc/netplan/目录下，通常是01-network-manager-all.yaml或00-installer-config.yaml。如果你照着网上的老教程去改/etc/network/interfaces，大概率没效果，原因就在这里。
以网卡名为ens33、虚拟机网段192.168.88.0/24为例，我一般这样配置静态IP：
network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.88.100/24 routes: - to: default via: 192.168.88.2 nameservers: addresses: - 223.5.5.5 - 119.29.29.29保存后执行 sudo netplan apply 让配置生效，再查看 ip addr 确认网卡拿到了IP。如果apply报错提示YAML格式有问题，九成是缩进不对。netplan对缩进极其敏感，建议统一用两个空格缩进，不要用Tab，也不要混用。
有一个容易忽略的细节：如果Ubuntu虚拟机使用NetworkManager管理网络，修改完netplan后最好同时执行 sudo systemctl restart NetworkManager，有时候只netplan apply会出现配置不生效或者连接状态不更新的情况。
3.3 Rocky Linux / RHEL系虚拟机：用nmcli命令行最顺手
Rocky Linux和RHEL 9系列默认使用NetworkManager，配置IP最推荐用nmcli命令，比编辑ifcfg文件直观，也不容易出错。网卡名通常是ens33或ens160，先用 nmcli device status 确认一下再操作。
配置静态IP的完整命令序列如下：
nmcli con mod ens33 ipv4.addresses 192.168.88.100/24 nmcli con mod ens33 ipv4.gateway 192.168.88.2 nmcli con mod ens33 ipv4.dns "223.5.5.5 119.29.29.29" nmcli con mod ens33 ipv4.method manual nmcli con up ens33动态获取则更简单：nmcli con mod ens33 ipv4.method auto && nmcli con up ens33 就能搞定。配完用 ip addr、ping网关、ping外网验证。如果你习惯编辑文件，路径是 /etc/NetworkManager/system-connections/ens33.nmconnection，改完要执行 nmcli con reload 再 nmcli con up ens33 重启连接。
3.4 多网卡场景：一张卡上网，一张卡和宿主机私有通信
有时候需要虚拟机既能上网，又要和宿主机走一条封闭的私密通道。比如我在家里测试一个多节点的分布式服务，既要虚拟机拉取外网依赖包，又希望节点间通信流量不占用物理Wi-Fi带宽。这时可以给虚拟机加第二块网卡：第一块网络适配器设为NAT（VMnet8）用于上网，第二块设为“仅主机模式”（VMnet1），两张网卡分别配不同网段的IP。
在虚拟机设置里点击“添加 → 网络适配器”就能加第二张卡，系统内部会出现ens33、ens34（Ubuntu）或者ens33、ens36（RHEL系）两个接口。两个接口各配各的IP，路由表默认只会有一条默认路由走NAT那张卡，仅主机那张卡因为网段不同会自动被设定为直连路由，不需要额外配置策略路由。
这里有个必须注意的坑：两张网卡如果都配置了网关，系统会生成两条默认路由，流量就可能走错出口，表现出来就是“时通时断”。解决方法是，仅主机网卡的配置里只写IP和掩码，不要写网关，让默认路由唯一落在NAT网卡上。
4. 网络故障排查：从网卡不识别到虚拟机服务连不上
虚拟机网络出问题，绝大多数不是玄学，而是配置错位。这一章把最常见的几类故障、排查思路和解决办法整理出来，很多是文档里查不到的实测经验。
4.1 桥接模式连不上网：先看绑定网卡，再看物理路由器
桥接模式最常见的病象是虚拟机内网卡显示“未识别的网络”或“无Internet访问”。第一步，打开虚拟网络编辑器，选中VMnet0，查看“桥接到”下拉框选的是哪个物理网卡。如果宿主机既有有线网卡又有Wi-Fi无线网卡，VMware可能默认是“自动”，自动模式偶尔会选错，就会出现网络时好时坏。手动改成当前正在上网的那块物理网卡再试。
如果绑定了正确的网卡还是不行，关掉虚拟机，在虚拟机设置里把网络适配器的“已连接”选项重新勾选，确保虚拟网卡确实连接到VMnet0。最后检查物理路由器：IP地址池是否已满、是否开启了MAC绑定。判断方法很简单，在虚拟机里查看IP，如果拿到的是169.254开头的地址，说明DHCP根本没通。
4.2 NAT模式下能ping通宿主机但上不了外网
这个故障特别典型：虚拟机的IP是192.168.88.x，能ping通192.168.88.1（宿主机VMnet8地址），但ping不通外网。原因是去往外部网络的流量需要经过VMware的NAT网关（192.168.88.2），而NAT服务本身可能没启动。
在Windows宿主机上按Win+R，输入services.msc回车，找到VMware NAT Service，确认状态是“正在运行”，启动类型为“自动”。如果服务是停止状态，右键启动；如果启动后隔几秒又停了，通常是和系统里其他网络组件冲突，这时可以在虚拟网络编辑器里点“恢复默认设置”重建VMnet8——这是少数我推荐用恢复默认的场景，但要注意端口转发规则会被一起清掉。
还有一类情况容易造成误判：ping 223.5.5.5通，但ping www.baidu.com不通。这说明网络本身是通的，只是DNS解析失败。检查虚拟机内部的DNS配置，改成223.5.5.5或114.114.114.114再试，问题通常就解决了。
4.3 虚拟机之间互ping不通：很可能没在同一个VMnet
一台宿主机上跑两台虚拟机，想在两个系统间传文件，结果互相ping不通。十有八九是两台虚拟机选了不同的虚拟网络。比如一个选了NAT（VMnet8），另一个选了仅主机（VMnet1），网段都不一样，当然不通。在虚拟机设置里把两台虚拟机的网络适配器改成同一个模式，再确认内部IP处于同一网段，问题就解决了。
还有一类坑是防火墙。Ubuntu默认启用了ufw，Rocky Linux默认开启firewalld，虚拟机之间ping不过去时先看防火墙：sudo systemctl stop firewalld 或 sudo ufw disable 临时关掉测试。如果是业务需要，别一直关防火墙，放行对应端口和ICMP规则就行。
4.4 克隆虚拟机后网卡不工作：UUID和MAC地址在打架
从模板克隆虚拟机，或者把一台虚拟机复制给同事用，很容易出现网卡启不来、NetworkManager报“设备不归NetworkManager管理”之类的错误。原因在于克隆时虚拟机的网卡MAC地址变了，但系统内部还保留着旧网卡的配置和连接记录，UUID对不上。
Ubuntu系统的处理办法：编辑/etc/netplan下的文件，确保匹配正确的网卡名，或者干脆删除旧的netplan配置重建；同时执行 sudo rm -f /etc/udev/rules.d/70-persistent-net.rules，重启后系统会用新MAC重新识别网卡。RHEL系（Rocky/AlmaLinux）则建议重建NetworkManager连接：先 nmcli con delete 旧连接，再重新创建，或者在ifcfg文件里把UUID那行注释掉，让系统重新生成。
如果你用DiskGenius之类的工具把物理机系统转成虚拟机镜像，或者反过来把虚拟机导出成物理机启动盘，同样会遇到网卡配置失效的问题——系统里记录的是旧硬件的PCI号和MAC地址，换成虚拟网卡后必然对不上。处理思路和克隆一样：清掉旧的网络连接记录，让系统重新识别网卡。
4.5 宿主机提示“无法连接到虚拟机”或VMware服务异常
启动虚拟机时偶尔会看到“无法连接到虚拟机。请确保您有权运行该程序、访问该程序使用的所有目录……”的提示。这不是网络配置本身的问题，而是VMware的服务或权限出了问题。处理顺序如下：
- 以管理员身份重新运行VMware Workstation，排除权限问题。
- 检查Windows服务里VMware Authorization Service、VMware DHCP Service、VMware NAT Service三个服务，都设为自动启动并运行正常。
- 如果服务重启无效，关闭VMware，在“程序和功能”里选择VMware Workstation的“修复”安装，绝大多数服务损坏都能这样恢复。
Win11用户如果遇到VMware明显卡顿，大概率是系统开启了内核隔离（基于虚拟化的安全），它和VMware在虚拟化指令上有争夺。在“设置 → 隐私和安全性 → Windows安全中心 → 设备安全性 → 内核隔离”里关掉内存完整性并重启，同时确认BIOS里VT-x处于开启状态，卡顿会有明显改善。新版VMware Workstation Pro（17.5及以后）对Win11兼容性更好，建议升级到最新版本。
4.6 常见问题速查表
| 症状 | 可能原因 | 快速处理 |
|---|---|---|
| 虚拟机完全没有IP | VMnet网卡未连接、网段冲突 | 检查虚拟网络编辑器，重选网络模式 |
| 桥接后能通内网但没外网 | VMnet0绑定错误、路由器限制 | 手动指定物理网卡，查看路由器DHCP |
| NAT下网关通但外网不通 | NAT服务未启动、DNS配置错误 | 启动VMware NAT Service，改DNS |
| 虚拟机之间ping不通 | 不同VMnet、防火墙拦截 | 统一虚拟网络模式，临时关防火墙测试 |
| 克隆后网卡不工作 | MAC、UUID冲突 | 删除旧网络配置，重建连接 |
| 宿主机访问不了虚拟机Web | 未做端口转发、防火墙拦80端口 | NAT设置添加转发规则，确认guest防火墙 |
| Win11里VMware明显卡顿 | 内核隔离占用虚拟化 | 关闭内存完整性，确认VT-x开启 |
| 启动虚拟机报权限错误 | VMware服务权限损坏 | 管理员运行，修复安装 |
5. 进阶实战：本地加虚拟机打造的多站点自定义域名开发环境
最后用一个我很常用的实战场景收尾：在宿主机上通过自定义域名访问虚拟机里跑在nginx上的多个站点。这个配置搭好之后，本地开发和测试非常舒服，和真实线上环境几乎一致。
5.1 网络拓扑规划
拓扑是：宿主机Windows或Mac加虚拟机Linux（Ubuntu或Rocky），虚拟机使用NAT模式，宿主机的8080端口通过NAT端口转发指向虚拟机80端口。为什么要这么做？因为不同站点直接监听不同端口虽然也能区分，但容易记混，而端口转发配合hosts文件可以实现完全模拟线上环境——访问app1.local和app2.local就像访问两个独立域名一样，后端不用关心具体的IP和端口。
具体网络规划：
- 虚拟机IP：192.168.88.128（静态配置，避免DHCP变化导致域名解析失效）
- 虚拟机nginx监听80端口
- 宿主机NAT端口转发：8080到192.168.88.128:80
- 宿主机hosts里把app1.local和app2.local都指向127.0.0.1
5.2 nginx多站点配置
在虚拟机里装好nginx后，在/etc/nginx/conf.d/下创建两个站点配置。第一个：
server { listen 80; server_name app1.local; root /var/www/app1; index index.html; location / { try_files $uri $uri/ =404; } }第二个：
server { listen 80; server_name app2.local; root /var/www/app2; index index.html; location / { try_files $uri $uri/ =404; } }两个配置唯一的区别就是server_name和root不同。nginx根据请求的Host头来区分访问哪个站点，这就是虚拟主机的核心原理。把两个静态页面分别放进/var/www/app1和/var/www/app2，然后执行 nginx -t 检查配置语法，再 systemctl reload nginx 重载。注意：如果虚拟机防火墙开着，要放行80端口，否则宿主机访问会被拦在门外。
5.3 配置宿主机hosts和端口转发
宿主机上打开hosts文件（Windows路径C:\Windows\System32\drivers\etc\hosts，macOS和Linux路径/etc/hosts），添加两行：
127.0.0.1 app1.local 127.0.0.1 app2.localWindows下编辑hosts需要管理员权限，macOS和Linux下记得用sudo。然后在VMware里配置端口转发：虚拟网络编辑器选中VMnet8，点击NAT设置，在端口转发处添加规则，主机端口填8080，虚拟机IP填192.168.88.128，虚拟机端口填80，协议TCP。保存后，在宿主机浏览器里访问 http://app1.local:8080 和 http://app2.local:8080，就能看到虚拟机里两个不同的站点。
浏览器访问时实际上发生了一连串事情：浏览器根据hosts文件把app1.local解析到127.0.0.1，请求发到宿主机的8080端口，VMware NAT服务把请求转发给虚拟机192.168.88.128的80端口，nginx根据Host头里的app1.local匹配到第一个server块，返回对应的静态页面。这个过程和线上的“域名解析到Web服务器”逻辑一模一样，非常适合用来模拟真实部署。
5.4 这套方案后续还能怎么扩展
这套自定义域名方案稍加改造就能覆盖更多场景：如果不想用域名，也可以把hosts里的域名换成虚拟机的IP，直接在浏览器里访问 http://192.168.88.128，只是没法体验多域名的乐趣了。如果想让多个虚拟机各自提供不同站点，就加多条端口转发规则，每台虚拟机对应一个宿主机端口。如果之后开始用Docker容器跑服务，同样能沿用这套规则，相当于宿主机为所有容器统一做了入口代理。
我在实际配置中还有一个心得：别把端口转发规则和虚拟机防火墙混为一谈。宿主机的8080转发到虚拟机80虽然已经配好，但如果虚拟机的firewalld或ufw把80端口挡了，访问依然会失败。所以每次配完端口转发，先在虚拟机内部执行 curl http://127.0.0.1 确认nginx和80端口本身正常，再回到宿主机浏览器测试，这样能快速定位问题出在哪一段。
其实整套VMware网络配置绕来绕去就是一句话：搞清楚“虚拟交换机”和“虚拟机内部网卡”两个层面，两边网段对齐，网络就通了一半，剩下的无非是服务、防火墙、DNS这些常见套路。我用这套方法帮同事排查过无数虚拟机网络问题，几乎百试百灵。如果看到这里你还在被虚拟机网络折磨，建议先给虚拟机打个快照，然后按文章顺序从虚拟网络编辑器开始重新走一遍，大概率能解决。希望这篇总结能帮你省下我当年反复折腾的时间。
