1. 先把虚拟机的网络链路捋直，别急着瞎试
干这行十来年，虚拟机连不上网络这个问题，我在项目现场、技术群里被问过不下几百次。它折磨人的地方在于：现象永远只有一句"我上不了网"，但出问题的位置可能在虚拟机内部的网卡配置里，可能在宿主机的虚拟网卡上，也可能卡在 VMware 的虚拟交换机那层，甚至是宿主机上某个后台服务压根没启动。排查方向错了，你改半天/etc/resolv.conf也是白搭。
所以我从来不建议上来就翻教程抄命令，而是先在脑子里建一条链路模型：虚拟机网卡 → 虚拟交换机（VMnet）→ 宿主机虚拟网卡 / NAT 与 DHCP 服务 → 物理网卡 → 路由器 → 外网。这条链上任何一环断开，最终表现都是"连不上"。你要做的是判断断点在哪一环，而不是从第一环开始无脑试到最后。
这一节的目标很明确：把桥接、NAT、仅主机这三种模式的差别讲透，再教你怎么三秒钟确认自己的虚拟机挂在哪张虚拟网络上。这两件事搞明白了，后面所有排查都是顺藤摸瓜。适用范围也很广，VMware Workstation 17、老版本的 15/16，甚至 VirtualBox 的对应模式，逻辑都是通的。
1.1 桥接、NAT、仅主机，三种模式到底差在哪儿
先用生活化的说法打个底。桥接模式相当于给你的虚拟机发了一张独立的门禁卡，它跟宿主机是平级的邻居，各自去路由器那边领 IP，局域网里其他机器能直接看到它。NAT 模式相当于虚拟机住进了宿主机搭的一间"内屋"，出门必须经过宿主机这道门，外网只看到宿主机的地址，看不到虚拟机。仅主机模式则更彻底，房间连门都没有，只有宿主机能隔着窗户跟它说话。
把这三者放到一张表里对比，会清楚很多：
| 对比项 | 桥接模式（Bridged） | NAT 模式 | 仅主机模式（Host-Only） |
|---|---|---|---|
| 虚拟交换机 | VMnet0 | VMnet8 | VMnet1 |
| 谁分配 IP | 路由器 DHCP | VMware 的 DHCP 服务 | VMware 的 DHCP 服务 |
| 同网段设备 | 与宿主机同一网段 | 独立私有网段 | 独立私有网段 |
| 能否上外网 | 能 | 能（经地址转换） | 不能 |
| 局域网其他机器能否访问虚拟机 | 能 | 默认不能，需端口映射 | 不能 |
| 宿主机能否访问虚拟机 | 能 | 能 | 能 |
| 典型用途 | 模拟真实服务器、联调 | 日常开发、临时上网 | 隔离实验、内网集群演练 |
选哪种模式，取决于你要解决什么问题，而不是哪个"看起来更高级"。要装一台 Linux 服务器做 Web 联调，需要手机或同事的电脑访问，那桥接最省心；只是想在本地跑个 Ubuntu 24.04 学命令行、装点软件包，NAT 就够了，还不用担心 IP 被路由器抢走；要搭一套三节点的内网集群，又不想污染公司办公网，那就仅主机模式，干干净净。
注意：无线网卡上的桥接模式是翻车重灾区。很多无线网卡驱动不支持混杂模式，或者企业级路由器会限制单个物理口下挂的 MAC 数量，结果就是虚拟机能开机、网卡也认，但拿不到 IP。遇到这种情况别死磕，直接换 NAT。
1.2 三秒钟确认你的虚拟机挂在哪张网络上
很多人排查了半天，才发现自己压根没搞清楚虚拟机当前用的是哪种模式。确认方法很简单：在 VMware 里选中目标虚拟机，右键 → 设置 → 硬件列表里找到"网络适配器"，右侧就能看到当前选择。如果这里显示的"网络连接"是"自定义"，后面还会跟一个 VMnet 名字，那就说明你手动指定过某张虚拟交换机。
另外两个常见状态要留意。第一个是"已连接"和"启动时连接"这两个复选框，如果"已连接"是灰的或者没勾上，虚拟机里就是没有网卡的物理链路，怎么配 IP 都没用。第二个是"复制物理网络连接状态"，这个选项只在笔记本切换有线/无线时才有意义，勾了之后虚拟机会跟着宿主机一起切换网络，日常用建议勾上，能省不少事。
确认完模式之后，顺手在虚拟机内部也看一眼。Linux 下敲ip link show，正常应该能看到ens33、ens160、eth0之类的名字，前面带着UP字样。如果是 Windows 虚拟机，进"网络和共享中心"看适配器列表，有"以太网"并且没打红叉就说明链路是通的。这一步花不了十秒，但能帮你排除掉一大半"其实根本没连上"的乌龙。
2. 虚拟机内部的排查：从网卡到 DNS 的一条链
如果链路本身是通的，那问题大概率在虚拟机内部的配置上。这一节的思路是自下而上分层验证：先看网卡认没认出来、是不是被系统关掉了；再看有没有拿到 IP 和网关；最后再看 DNS 能不能解析、外网能不能通。每一层都验证过，你就能精准定位到是哪一层的锅，而不是一股脑把能改的都改了。
这一节我主要以 Linux 虚拟机为例展开，因为它出问题的概率最高、报错也最不友好。Windows 虚拟机的情况我在对应位置单独提。命令都是可以直接复制执行的，Ubuntu 24.04、CentOS 7/8、Debian 12 这些主流发行版基本通用。
2.1 网卡认没认出来，是不是被系统关掉了
第一件事是确认网卡存在。ip link show会列出所有网络接口，除了lo这个回环口，你还应该看到一个ens33或者eth0。如果只有lo，那说明虚拟硬件层面就没接到网卡，回到第 1.2 节检查虚拟机设置里的网络适配器是不是被移除了。这里顺带说一句，"虚拟机设置里根本没有网络适配器这一项"是个挺常见的情况，尤其是从别人那儿拷来的虚拟机或者精简过的模板，解决办法就是编辑虚拟机设置 → 添加 → 网络适配器，选好模式再开机。
如果网卡在列表里，但状态是DOWN，那就是没启用。临时启用用sudo ip link set ens33 up，但重启后会失效，得改配置文件。这里不得不提一个经典到烂大街的坑：CentOS 7 系列最小化安装后，网卡配置文件里默认ONBOOT=no，也就是开机不启用网卡。编辑/etc/sysconfig/network-scripts/ifcfg-ens33，把ONBOOT改成yes，同时确认BOOTPROTO是dhcp（要动态获取）或者static（要写死 IP），然后sudo systemctl restart network。这一条我见过太多人卡在里面，装完系统折腾一下午，就是因为这一行。
Ubuntu 这边情况不太一样，它用 netplan 管网络。配置文件通常在/etc/netplan/目录下，名字可能是50-cloud-init.yaml或者01-network-manager-all.yaml。重启网络用sudo netplan apply，如果报错可以加--debug看详细日志。改之前一定先用sudo cp 文件名 文件名.bak备一份，netplan 的 YAML 缩进对空格极其敏感，一个 Tab 就能让整台机器断网。
提示：改网络配置文件之前先拍个快照或者备份文件，这是铁律。我见过有人把唯一一份配置改崩，重启后宿主机 SSH 也进不去，最后只能挂载虚拟磁盘改文件。
2.2 IP、掩码、网关这三件套怎么验
网卡起来了，接下来看有没有拿到地址。ip addr show ens33会显示这块钱的完整信息。如果inet后面是空的，说明 DHCP 没拿到地址，手动触发一次：sudo dhclient -v ens33，-v参数会把交互过程打出来，能看到它发了几次请求、有没有收到回应。这一步能明确区分"网卡没起来"和"起了但拿不到地址"，是两个完全不同的问题。
拿到 IP 之后看网关，ip route show或老一点的route -n都行，正常应该有一行default via 192.168.x.1 dev ens33。NAT 模式下这个网关一般是192.168.x.2这种特殊地址，是 VMware 的虚拟路由器，看起来有点怪但完全正常，别以为错了。没有默认路由，就等于出门不知道往哪走，外面再好也到不了。
这里的参数不是随便填的。以 NAT 模式默认的网段为例，VMware 通常会给你一个类似192.168.70.0/24的网段，网关是.2，DHCP 池大概从.128到.254。如果你要配静态 IP，选个小一点的地址比如.10，别跟 DHCP 池冲突，子网掩码255.255.255.0，网关填.2，DNS 可以先填223.5.5.5和119.29.29.29这两个公共解析服务。这套参数满足"不冲突、能出网、解析稳"三个要求，日常开发够用了。
Windows 虚拟机的对应操作是ipconfig /all看详情，ipconfig /renew重新申请地址。如果显示169.254.x.x这种自动私有地址，说明 DHCP 请求失败了，问题多半在宿主机侧的服务上，跳到第 3 节看。
2.3 DNS 与连通性的分层测试
这一步是排查的精华所在，用四条命令把故障范围一刀切开。第一条ping -c 4 127.0.0.1，验证协议栈本身没问题，几乎总是通的。第二条ping -c 4 192.168.x.2，也就是网关，验证虚拟机能走到虚拟路由器。第三条ping -c 4 223.5.5.5，验证能不能出网。第四条nslookup www.baidu.com或者ping -c 4 www.baidu.com，验证域名解析。
这四步的组合能直接给出结论，我整理成表格看得更清楚：
| 127.0.0.1 | 网关 | 公网 IP | 域名 | 结论与方向 |
|---|---|---|---|---|
| 通 | 通 | 通 | 不通 | DNS 配置错误，检查/etc/resolv.conf |
| 通 | 通 | 不通 | 不通 | NAT 服务或宿主机转发有问题，转第 3 节 |
| 通 | 不通 | 不通 | 不通 | 网关地址写错、网段不匹配，或虚拟交换机配置异常 |
| 不通 | 不通 | 不通 | 不通 | 网卡本身没启用，回到 2.1 |
DNS 那块补一句，Ubuntu 从 18.04 起systemd-resolved接管了解析，/etc/resolv.conf经常是个指向127.0.0.53的软链接，直接改它重启就没了。正确的做法是在 netplan 配置里写nameservers: addresses: [223.5.5.5, 119.29.29.29]，然后netplan apply。如果急着排障想临时验证，可以sudo resolvectl dns ens33 223.5.5.5先顶上。
3. 宿主机这一侧：虚拟网络编辑器与虚拟网卡
虚拟机内部查完没问题，那锅大概率在宿主机上。这一块是很多人容易忽略的地带，因为它不在虚拟机窗口里，而是在 Windows 的"网络连接"面板和 VMware 的"虚拟网络编辑器"里。我见过最多的两种情况是：宿主机上的 VMware 虚拟网卡带了黄色感叹号，以及 VMware 的几个后台服务被安全软件默默关掉了。
这一节的排查顺序是：先看虚拟网络编辑器的网段规划是否正确；再看 Windows 侧的虚拟网卡状态；最后确认三个关键服务是否在跑。
3.1 虚拟网络编辑器里的网段规划
打开 VMware Workstation，菜单栏"编辑" → "虚拟网络编辑器"，如果按钮是灰的，点右下角的"更改设置"提权。这个界面里你会看到 VMnet0、VMnet1、VMnet8 这几张虚拟交换机，以及它们对应的类型、子网地址和 DHCP 设置。
第一个要检查的是网段是否跟物理网络冲突。假设你家路由器是192.168.1.0/24，而 VMnet8 也被配成了192.168.1.0/24，两边就撞车了，路由表会陷入混乱：访问192.168.1.50到底是宿主机网段的设备还是虚拟机，系统自己都说不清。解决办法很直接，把 VMnet8 的子网改成192.168.100.0/24这种平时用不到的网段，NAT 设置里的网关会自动跟着变。
第二个要检查的是 DHCP 是否启用，以及地址池范围。NAT 和仅主机模式都依赖 VMware 自带的 DHCP 服务分配地址，如果这里没勾"将 IP 地址分配给虚拟机"，虚拟机自然拿不到 IP。地址池别设得太窄，比如只有十几个地址，你开了几台虚拟机加上反复克隆，很容易耗尽。
第三个是 NAT 设置里的网关地址。点"更改设置"提权后，NAT 设置里能看到网关 IP，通常是网段的第二个地址。如果你的虚拟机配的是静态 IP，网关必须跟这里保持一致，差一位都出不去。
注意：改完虚拟网络编辑器里的任何设置，一定要点"应用"再点"确定"，只点确定有时候不生效。改完之后最好把虚拟机里的网络服务重启一次，或者直接重启虚拟机。
3.2 vmnet8 带感叹号、虚拟网卡异常怎么修
Windows 上打开"控制面板 → 网络和 Internet → 网络连接"，你会看到VMware Network Adapter VMnet1和VMware Network Adapter VMnet8两块虚拟网卡。它们正常的状态应该是"已启用"，且没有黄色感叹号。如果 VMnet1 或 VMnet8 上顶着感叹号，网络协议栈就没法在这块虚拟网卡上正常工作，NAT 和仅主机模式全废。
出现感叹号的原因通常有三个：网段跟物理网冲突（同 3.1 节）、虚拟网卡驱动状态异常、或者被安全软件限制了。修复思路是"先清后建"，具体操作是：在设备管理器里找到这两块虚拟网卡，右键卸载，弹出窗口里不要勾选"删除驱动程序软件"，卸载完回到虚拟网络编辑器点"还原默认设置"，VMware 会重新生成这两块网卡和对应的虚拟交换机。这一招比重启十次管用得多。
还有个小概率情况是虚拟网卡被系统识别成了"无法识别的网络"，这时候可以试着在虚拟网卡属性里手动指定地址，比如 VMnet8 那块填192.168.100.1、255.255.255.0，保证宿主机在这张虚拟交换机上有个明确的地址。正常情况 VMware 会自己配好，但如果之前被人手动改过，这一步能把状态拉回来。
Linux 当宿主机的话路径不一样，VMware Workstation 的 Pro 版本会创建vmnet1和vmnet8两个接口，用ip addr能看到。停止和启动虚拟网络用：
sudo vmware-networks --stop sudo vmware-networks --start这两个命令比重启整个 VMware 服务快，改完虚拟网络配置之后跑一遍很有效。
3.3 三个必查的后台服务与拦截问题
Windows 宿主机上，VMware 依赖几个后台服务干活，其中跟网络直接相关的是这三个：VMware DHCP Service、VMware NAT Service、VMware Authorization Service。前两个负责给虚拟机发地址和做地址转换，第三个负责虚拟机的授权。任何一个没启动，NAT 模式都会出问题。
检查方式是Win + R输入services.msc，在列表里挨个找这三个服务，看状态是不是"正在运行"。更稳妥的做法是双击进去把"启动类型"改成"自动"，省得下次开机又没起来。它们的服务名分别是VMnetDHCP、VMware NAT Service和VMAuthdService，用命令行批量操作也行：
net start VMnetDHCP net start "VMware NAT Service" net start VMAuthdService另一种高频情况是安全软件拦截。有些杀软或者企业管控软件会默认禁止 VMware 的虚拟网卡创建网络连接，表现就是虚拟机能上网一小会儿然后断掉，或者干脆一直不通。排查办法是暂时退出防护软件再试一次，如果立刻就好了，那就把 VMware 相关进程加入白名单。Windows 自带的防火墙一般不影响虚拟机出去，但会影响宿主机访问虚拟机里的服务，第 4.4 节细说。
VMware Workstation 17 里还有一点变化值得提一句：菜单结构做了调整，虚拟网络编辑器和部分设置入口需要提权才能打开，很多从 15 版本升上来的人会一时找不到"更改设置"按钮，以为功能被砍了。其实只是入口变了，点一下右下角那个带盾牌图标的按钮就行。
4. 分场景实战：几种最常见的"连不上"怎么破
前面三节讲的是通用链路和排查方法，这一节直接上场景。我把平时遇到频率最高的四种情况拆开讲，每种都给出完整的原因分析和操作步骤。你可以对照自己的现象直接跳到对应小节，不用从头看。
4.1 NAT 模式下能连宿主机，但上不了外网
这个现象很典型：ping网关通、ping宿主机上的192.168.100.1也通，甚至能访问宿主机上的服务，但一ping公网地址就没反应。这说明虚拟机和虚拟路由器之间的通信是好的，断点在"从虚拟机出宿主机的物理网卡"这一段。
第一步排查宿主机本身能不能上网。宿主机都上不了网，虚拟机自然跟着断，这是最基本但最容易被忽略的一点。第二步检查 VMware NAT Service 是否在运行，方法同 3.3 节。第三步看宿主机的物理网卡是不是被设成了某种特殊的网络配置，比如某些公司电脑装了流量管控客户端，会改变路由表，把非本机流量的转发给拦掉，这种在办公环境里会碰得比较频繁，处理方式一般需要找 IT 支持。
如果宿主机上网正常、服务也在跑，还有一招很管用：把虚拟机网卡先断开再重连。在 VMware 界面右下角的网络适配器图标上右键，选"断开连接"，等两秒再"连接"。这会强制重新走一遍 DHCP 和 NAT 建立流程，能解决一部分临时性的状态错乱。如果还不行，就在虚拟机里手动指定静态 IP，绕过 DHCP 环节，很多 DHCP 层的小毛病直接就绕过去了。
第四步检查 DNS。有一种情况是公网 IP 能ping通，但域名解析不了，浏览器打开网页一直转圈。这就是 DNS 的锅，按 2.3 节的方法在 netplan 或网卡配置里写死公共 DNS 地址即可。
4.2 桥接模式拿不到路由器分配的 IP
桥接模式的故障率明显高于 NAT，原因在于它把责任推给了物理网络环境，而物理网络环境是你控制不了的。典型的报错是虚拟机能开机、网卡也在，但ip addr里就是没有inet，或者出现169.254.x.x这种自动私有地址。
首先要确认桥接到哪块物理网卡了。虚拟网络编辑器里选中 VMnet0，下面的"桥接到"应该选"自动"，或者明确指定当前正在用的那块网卡。笔记本上经常出现的问题是：你插着网线但桥接到了无线网卡，或者反过来，那当然通不了。指定成当前实际在用的那块，问题就解决一半。
其次是无线网卡的限制。前面提过，不少无线网卡驱动对混杂模式支持不好，桥接后拿不到路由器分配的地址。判断方法很简单，换成有线网试试，如果立刻好了，那就是无线网卡的问题。这种情况下的正确做法不是折腾驱动，而是改用 NAT 模式，然后再做端口映射把需要的服务暴露出来（见 4.4 节）。
第三个可能是路由器的限制。有些路由器设置了"只允许已绑定 MAC 的设备接入"，或者限制了单台设备下挂的终端数量。虚拟机桥接后对路由器来说就是一台新设备，分不到地址很正常。进路由器管理页面看一眼 DHCP 客户端列表和接入限制，很多时候答案就在那儿。
还有一个容易忽略的点是宿主机的网络共享或流量控制软件。这些软件会接管物理网卡，导致桥接流量出不去。临时退出来验证一下就能确认。
4.3 克隆、复制、导入之后网络失灵
从别人那儿拷来的虚拟机、自己克隆出来做集群的虚拟机，开机后网络不通，这是另一个高频场景，根源基本都在"身份重复"上。具体分两种情况。
第一种是 MAC 地址冲突。虚拟机网卡的 MAC 在克隆时可能被原样复制，同一个局域网里出现两个相同 MAC，交换机会无所适从。VMware 在克隆时会弹出"我已复制该虚拟机"或"我已移动该虚拟机"的选项，选"我已复制"，它会帮你重新生成 MAC 和 UUID。如果你手滑选了"我已移动"，那就手动去虚拟机设置 → 网络适配器 → 高级里点一次"生成"重新造一个 MAC。
第二种是 Linux 系统内部记着旧网卡。老一些的发行版会把网卡和 MAC 的绑定关系写在/etc/udev/rules.d/70-persistent-net.rules这类文件里，换了 MAC 之后系统给新网卡分了个eth1的名字，而配置文件里还在配eth0，自然起不来。处理方式是删掉这个规则文件然后重启，系统会重新识别。Ubuntu 新版本用 netplan，问题变成配置文件里写死了旧的网卡名，把match段里的名字改成当前的即可，用ip link确认当前叫什么。
顺便说一个和克隆相关的经典提示：虚拟机开机报"此虚拟机可能已被移动或复制"或者"上次操作意外关机"。前者选"我已复制"就对了；后者是上次关机不干净留下的挂起状态文件，在虚拟机目录里能找到.vmss和.lck结尾的文件，关掉 VMware 后手动删掉再打开，一般就能正常启动。这种状态下网络不通也是正常的，因为整个虚拟机状态都是残的。
4.4 宿主机访问虚拟机里跑的网站
这个需求太常见了：在虚拟机里起了个 Web 服务，想用宿主机的浏览器打开看看。NAT 模式和仅主机模式下，宿主机和虚拟机在同一个虚拟网段里，直接用虚拟机的地址访问即可，比如虚拟机是192.168.100.128，服务监听 80 端口，浏览器输http://192.168.100.128就行。前提是服务本身监听在0.0.0.0而不是127.0.0.1，绑在回环地址上的服务外部访问不了，这个坑新手经常踩。
如果服务确实绑在127.0.0.1上又不想改配置，或者你需要在局域网另一台手机上访问 NAT 模式下的虚拟机，那就得做端口映射。打开虚拟网络编辑器 → 选中 VMnet8 → NAT 设置 → 添加映射，把宿主机的某个端口指向虚拟机的 IP 和端口，比如宿主机8080映射到192.168.100.128:80。填完之后，访问http://宿主机IP:8080就能到虚拟机里去。
还有一个经常挡路的是防火墙。Linux 虚拟机里如果开着 ufw，sudo ufw status看状态，需要开放端口用sudo ufw allow 80/tcp；CentOS 系列是 firewalld，sudo firewall-cmd --add-port=80/tcp --permanent然后sudo firewall-cmd --reload。Windows 虚拟机的 Defender 防火墙也要看一眼，默认会拦入站连接。我遇到过好几次都是服务没问题、网络也没问题，纯粹是防火墙把包丢了。
提示：排查"服务访问不了"时，先在虚拟机内部用
curl http://127.0.0.1自测，通了说明服务本身没问题，问题在监听地址或防火墙上，这个二分法能省大量时间。
5. 高频报错速查与几条踩坑经验
前面几节讲的是方法，这一节给你一张能直接查的表。我把这些年见过的高频现象、真实原因和处理方式整理成对照表，遇到问题时先扫一眼，能少走很多弯路。后面再补几条只有踩过才知道的经验。
5.1 常见现象与原因对照表
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| Linux 虚拟机能开机但无 IP | 网卡未启用，ONBOOT=no | 改配置文件为yes并重启网络服务 |
| VMnet1 或 VMnet8 带感叹号 | 网段冲突或虚拟网卡驱动异常 | 卸载网卡后执行"还原默认设置" |
| 能 ping 通 IP 但打不开网页 | DNS 配置错误 | 在 netplan 里指定公共 DNS |
| 桥接模式下无 IP | 桥接的物理网卡选错，或无线网卡不兼容 | 指定正确网卡，或改用 NAT |
| 克隆后无网络 | MAC 冲突或系统内残留旧网卡规则 | 重新生成 MAC，清理 udev 规则 |
| 只能宿主机访问虚拟机 | 用的是仅主机模式 | 换成 NAT 或桥接 |
| 局域网设备访问不到虚拟机服务 | NAT 模式未做端口映射 | 在 NAT 设置里添加端口转发 |
| 宿主机访问虚拟机服务超时 | 服务监听回环地址或防火墙拦截 | 改监听地址，开放对应端口 |
5.2 几条我踩过坑才记住的经验
第一条，排查顺序一定要自下而上，不要自下而上和自上而下同时乱试。先把虚拟机内部四层验证做完（网卡、IP、网关、DNS），确认哪一层断，再去查宿主机。我见过太多人两边同时改，最后环境改得面目全非，连原本正常的功能都坏了。
第二条，改配置前先备份、先快照。虚拟机最大的优势就是可以随时回滚，但很多人不拍快照就直接改网络配置，改崩了只能重装。尤其在改 netplan 的 YAML 文件时，缩进错一个空格就能让整机断网，物理机还能插个 U 盘救，虚拟机就只能挂盘了。
第三条，遇到玄学问题先断开重连网卡，再考虑重启虚拟机。VMware 的虚拟交换机和宿主机的虚拟网卡之间偶尔会状态漂移，断开重连相当于重新握手，比各种改配置都快。这一招我用了很多年，解决过不少"什么都没改但突然不通了"的怪问题。
第四条，别迷信静态 IP。很多人习惯给每台虚拟机配静态地址，觉得稳。实际上在 NAT 和仅主机模式下，DHCP 分配是最不容易出错的，因为地址池和网关都是 VMware 自己管的。真要固定，也在虚拟机设置里做静态绑定，而不是手工往配置文件里写，写错一位就白折腾。
第五条，保留一台"标准机"当模板。我本地长期留着一台配好网络、装好常用工具的 Ubuntu 24.04，需要新环境就整个文件夹复制一份，按 4.3 节的流程处理 MAC 和网卡名。这比每次从头装系统快得多，也避免了各种安装阶段的奇怪问题。
6. 安装阶段就埋下的雷：虚拟化开关与系统层冲突
有些问题看着像"网络故障"，实际上跟网络一点关系没有，根源在虚拟化层面。这类问题的特点是报错信息跟网络无关，但最终表现同样是虚拟机跑不起来或者网络功能异常，很容易误导排查方向。这一节专门讲这几种情况。
6.1 固件虚拟化没开，整个虚拟化层都是残的
最典型的是这句报错："此计算机上未启用虚拟化，请确保计算机固件设置中虚拟机平台已启用"。这段话虽然出现在启动侧的报错里，但它的影响范围远超启动本身，虚拟化扩展没开，虚拟机的性能会大幅下降，部分网络特性也可能表现异常。解决办法是重启进固件设置（开机时按 F2、Del 或 F10，视品牌而定），找到 Intel VT-x 或 AMD-V 相关选项，设为 Enabled，保存重启。
第二个相关的坑是 Windows 自带虚拟化组件与 VMware 的共存问题。Windows 11 上如果启用了 Hyper-V、虚拟机平台、Windows 虚拟机监控程序平台，或者开启了内核隔离里的"内存完整性"，VMware 会从底层切换运行模式，桥接模式可能不稳定甚至完全失效。判断方法是在虚拟机里看网卡状态，如果各项配置都对但就是不通，可以试着关掉这些组件验证一下。
关闭路径是控制面板 → 程序 → 启用或关闭 Windows 功能，把 Hyper-V、虚拟机平台、Windows 虚拟机监控程序平台这几项取消勾选，重启。内核隔离在"Windows 安全中心 → 设备安全性 → 内核隔离"里关闭。这里必须提醒一个取舍：关掉之后 WSL2 和部分容器工具就没法用了，因为它们依赖同一套虚拟化平台。如果你两样都要用，那就把虚拟机切到 NAT 模式，不要用桥接，通常能绕开这个冲突。
6.2 快照回滚与 MAC 变化的连带影响
快照是个好东西，但回滚的时候要注意一个细节：如果快照拍摄于网卡配置变更之前，回滚之后网卡配置会一起退回去，包括 IP、网关、DNS，甚至 MAC。表现就是"我明明刚配好的网络，恢复个快照又没了"，这不是故障，是预期行为。
还有一种情况是虚拟机的挂起状态。VMware 支持挂起虚拟机，下次直接恢复到内存状态。但如果挂起期间宿主机的网络环境变了（比如从家里换到公司、从有线换到无线），恢复后虚拟机里的网络状态还是旧的，就会不通。这时候正确做法是完全关机再开机，让虚拟机重新走一遍 DHCP。
顺带提一下虚拟硬件版本。从很老的 VMware 版本创建的虚拟机，硬件版本可能停留在 8 或 9，新的虚拟网卡类型（如 vmxnet3）支持不好，网络性能差甚至不通。可以在虚拟机设置里升级硬件版本，但要注意这是单向操作，升上去就降不回来了，升级前拍快照。
6.3 装 VMware Tools 到底有没有必要
这个问题问的人特别多，我的答案是：网络不稳定的时候，先装上再说。VMware Tools（Linux 上是open-vm-tools）带来的不只是拖拽文件和自适应分辨率，它还包括优化过的虚拟网卡驱动。用默认的e1000网卡和装了工具之后的vmxnet3相比，后者在吞吐和稳定性上明显更好。
Ubuntu 24.04、Debian 12 这些新发行版基本都预装了open-vm-tools，用dpkg -l | grep open-vm-tools查一下。没有的话一条命令搞定：
sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktopCentOS 系列用sudo yum install -y open-vm-tools。装完之后重启一次，网卡驱动会重新加载。我实测下来，同一台宿主机上，装了 tools 的虚拟机在网络抖动和长时间运行后的稳定性上确实更好，尤其在跑长时间任务的时候。
我个人在实际操作中的体会是，虚拟机网络问题九成以上能在十五分钟内定位，前提是你按"虚拟机内部四层验证 → 宿主机三项服务 → 虚拟网络编辑器配置"这个顺序走，而不是一上来就翻遍所有教程。真正难缠的往往不是技术本身，而是自己把环境改乱了之后失去了参照系。所以养成改前备份、留一台标准模板机的习惯，比背再多的命令都管用。另外提一句，如果你的虚拟机是用来做长期服务的，别嫌麻烦，把 IP 规划、网段划分、端口映射这些一次性理清楚，后续能省下大量重复排查的时间。
