虚拟机开机，网卡图标是亮的，ping网关超时，浏览器一直转圈，宿主机这边网页刷得飞起。这个场景我每年至少撞上十几次，有时候是自己手贱改了虚拟网络编辑器的配置，有时候是笔记本换了无线网、有时候干脆是系统更新之后虚拟网卡被悄悄禁用了。VMware Workstation 虚拟机连不上网，听着像个小毛病，真排查起来能把人耗掉一下午，因为它的故障点横跨宿主机物理网卡、VMware 虚拟网络层、客户机操作系统三层，任何一层掉链子，表现都是同一个“上不了网”。

这篇东西不讲概念科普，讲的是我这些年实际排障时用的那套顺序和方法：先把三种网络模式（桥接、NAT、仅主机）的本质区别掰开，再按“宿主机 → 虚拟网络 → 客户机”的顺序一层层往下压，最后给一张症状对照表，让你在五分钟内锁定大概位置。刚装完虚拟机的新手能照着走完整个流程，跑了好几台虚拟机、开始折腾双网卡和内网环境的老手，也能在中间几节里找到几个容易忽略的点。全程实操，命令可以直接抄。

1. 三种网络模式的本质区别与选型逻辑

1.1 桥接、NAT、仅主机到底差在哪

很多人排查半天没结果，根子在于没搞清楚自己用的是哪种模式，以及这种模式在网络拓扑里到底站在什么位置。这三种模式的差别，用一句话概括：虚拟机在网络上“像谁”。

桥接模式下，虚拟机在网络里被当成一台独立的物理机。它有自己的 MAC 地址，直接向你所连的那个路由器要 IP，拿到的地址段和宿主机完全一样，同一局域网里的其他设备能直接访问它，它也能被路由器看见。优点是“真”，做局域网联调、跑服务给别人访问，非它不可；缺点是依赖物理网络环境，公司网络如果做了端口安全或者只允许特定 MAC 上网，虚拟机就会被拦在门外。

NAT 模式下，VMware 在宿主机内部搭了一个小型路由器，虚拟机连的是这个虚拟路由器，宿主机相当于这个虚拟网络对外的唯一出口。虚拟机拿到的是私有网段地址（默认常见 192.168.x.0/24），所有出网流量由 VMware 的 NAT 服务做地址转换后，借用宿主机的网络发出去。好处是虚拟机完全不依赖物理网络环境，换个 Wi-Fi、换个网线，虚拟机照常上网；坏处是外部设备主动连不进来，除非你手动做端口映射。

仅主机模式顾名思义，虚拟机只能和宿主机通信，压根没有出网的口子。它的用途是做隔离环境，比如测试一套内网服务、跑一些不想让它碰外网的东西。很多人选了仅主机模式然后抱怨上不了网，这属于配置意图和实际需求没对齐，不是故障。

我自己的习惯是：日常开发用 NAT，需要给别人演示或者模拟多机集群时切桥接，做纯内网实验才用仅主机。这个默认选择能避开八成的麻烦。

1.2 为什么出厂默认配置经常连不上

刚装好的虚拟机默认就是 NAT，按理说开箱即用。但实际环境里翻车的概率不低，原因通常不在 VMware 本身，而在宿主机那边有几个“隐形开关”。

第一个是虚拟网卡被禁用。Windows 上安装 VMware 时会生成两块虚拟网卡：VMware Network Adapter VMnet1 和 VMnet8。NAT 模式能不能通，很大程度取决于 VMnet8 这块网卡的状态。系统优化工具、某些安全软件、甚至手动整理网络适配器时，它很容易被顺手禁用，而它的图标藏在“网络连接”面板里，平时根本看不见。

第二个是后台服务没起来。VMware 装了两个关键服务：VMware DHCP Service 和 VMware NAT Service。前者负责给虚拟机发地址，后者负责做地址转换。这两个服务默认是自动启动，但电脑非正常关机、系统更新、或者某些清理工具“优化开机项”之后，它们可能变成手动甚至被停掉。服务没跑，虚拟机自然拿不到 IP，表现就是一直卡在获取地址。

第三个是虚拟网络编辑器的配置被改乱。这块最容易出在“还原默认设置”被误点，或者曾经手动改过网段、子网掩码，导致虚拟 DHCP 的地址池和虚拟网卡不在一个网段。

还有一个容易被忽略的是宿主机装了别的虚拟化软件。比如 Windows 自带的虚拟化平台组件开启之后，会接管一部分网络栈，可能让 VMware 的桥接模式失效，或者让虚拟网卡出现异常。

1.3 我习惯的排查顺序：从物理层往应用层推

排障最忌讳的是东一榔头西一棒子。我固定用这套自上而下的顺序：

第一步，确认宿主机自己能上网。这听着像废话，但真有宿主机本身就在断网、或者连的是需要认证的访客 Wi-Fi 的情况，你在虚拟机里折腾一小时都是白费。

第二步，确认虚拟机的网络适配器是否“已连接”。虚拟机设置里那个“已连接”和“启动时连接”两个勾，缺一个都不行。这个勾被某次误操作取消之后，虚拟机内部的网卡就是“未插入网线”的状态，你怎么配 IP 都没用。

第三步，确认虚拟网络层的参数。也就是虚拟网络编辑器里的网段、DHCP 范围、NAT 网关地址，以及宿主机那两块虚拟网卡是否启用。

第四步，才进客户机内部查。看 IP 有没有拿到、网关对不对、DNS 配没配、路由表正不正常。

这个顺序的道理很简单：网络是分层的，下层不通的时候，上层怎么改都是无效操作。我见过太多人在客户机里反复执行ipconfig /release，而他宿主机上的 VMnet8 压根就是禁用状态。

2. 动手之前：宿主机侧的五个必查点

2.1 虚拟网卡有没有被禁用或带感叹号

Windows 上按Win + R输入ncpa.cpl，直接打开“网络连接”面板。这里应该能看到至少两块 VMware 开头的虚拟网卡。要看的就三件事：图标是彩色还是灰色、名字下面有没有“已禁用”字样、有没有黄色感叹号。

灰色带“已禁用”的，右键启用就行。有黄色感叹号的，说明驱动层面出了问题，通常是 VMware 安装损坏或者和系统更新冲突。这种情况我的处理方式是先右键“禁用”再“启用”试一次，不行就去设备管理器里卸载这块虚拟网卡，然后在虚拟网络编辑器里点一次“还原默认设置”，让 VMware 重新生成。注意，还原默认设置会把你自定义的所有虚拟网络一并重置，如果之前配过特殊网段，得提前记下来。

还有一个细节：VMnet1 和 VMnet8 的 IP 是 VMware 自动分配的，正常情况下 VMnet8 会是一个固定网段的地址，比如 192.168.x.1，这个地址其实就是虚拟 NAT 网络的网关在宿主机这一侧的映射。如果你发现 VMnet8 拿到了一个 169.254 开头的地址，那是自动私有地址，说明它没能和虚拟 DHCP 通信，基本可以判定 DHCP 服务有问题。

2.2 那两个后台服务是不是在跑

按Win + R输入services.msc，在列表里找 VMware 开头的服务，重点看两个：

• VMware DHCP Service：负责给虚拟网络里的机器分配 IP。
• VMware NAT Service：负责 NAT 模式下的地址转换。

启动类型应该是“自动”，状态应该是“正在运行”。如果状态是空的，右键启动；如果启动类型是“手动”或者“已禁用”，改成自动再启动。有些优化工具会把它们改成手动，结果就是每次重启电脑之后虚拟机都上不了网，得手动去开一次，这个坑我踩过不止一次。

顺便说一句，这两个服务启动失败的时候，事件查看器里通常会有记录。如果反复启动失败，大概率是 VMware 安装文件损坏，重装一遍客户端比继续折腾省时间。

2.3 虚拟网络编辑器里的关键参数怎么看

在 VMware Workstation 菜单里打开“编辑 → 虚拟网络编辑器”，注意这一步需要点“更改设置”按钮提权，否则看到的是只读状态，很多人卡在这儿以为按钮坏了。

打开之后看三个地方：

第一，看 VMnet0、VMnet1、VMnet8 分别对应哪种模式。列表里每一行都标了“桥接”“NAT”“仅主机”，如果发现 VMnet8 被改成了仅主机，那 NAT 模式当然上不了网，改回来就行。

第二，看 VMnet8 的“NAT 设置”。里面有个网关 IP，默认是网段里的.2地址。这个地址必须和虚拟 DHCP 分配的地址池在同一网段，否则虚拟机拿到 IP 也找不到网关。

第三，看“DHCP 设置”。里面能看到起始 IP、结束 IP 和租约时间。有次我遇到的问题是地址池只剩几个可用地址，而机器上开了七八台虚拟机，后开的几台就一直拿不到地址。把池子范围改大一点，比如从 x.100 到 x.254，问题立刻消失。

3. NAT 模式断网的完整实操排查

3.1 从宿主机到虚拟机的连通性分层验证

NAT 模式的排查，我固定按“四跳”来 ping，每一跳对应一个层次，跳不过去就说明问题卡在这一层。

第一跳：宿主机 ping 虚拟机的 IP。先在客户机里执行ipconfig（Windows）或ip addr（Linux）拿到地址，比如 192.168.152.128，然后在宿主机上ping 192.168.152.128。通不了，说明虚拟网卡 VMnet8 和虚拟机之间的链路有问题，回去查 2.1 和 2.2 那两节。

第二跳：虚拟机 ping 自己的网关。网关地址在虚拟网络编辑器的 NAT 设置里能看到，默认通常是192.168.152.2。这一跳不通，说明虚拟机的 IP 配置和虚拟网络不在一个网段，或者虚拟机内部防火墙把 ICMP 拦了。

第三跳：虚拟机 ping 一个公网 IP。比如ping 114.114.114.114。能通说明地址转换链路正常，问题出在域名解析上；不通说明 NAT 服务或者宿主机的出网链路有问题。

第四跳：虚拟机 ping 一个域名。比如ping www.example.com。前三跳都通，这一跳不通，那就是 DNS 的锅，去查 3.3 那一节。

# Linux 客户机上的四跳验证 ip addr show # 看拿到的 IP 和网段 ip route show # 看默认网关是否正确 ping -c 4 192.168.152.2 # 跳 2：网关 ping -c 4 114.114.114.114 # 跳 3：公网 IP ping -c 4 www.example.com # 跳 4：域名解析

这套四跳法最大的价值是快速排除无效路径。很多人一上来就在虚拟机里改 DNS，改了半天发现连网关都不通，白忙活。

3.2 DHCP 拿不到地址时的两种修法

DHCP 拿不到地址的典型表现是：客户机显示“未识别的网络”，ipconfig出来一个 169.254 开头的地址，或者 Linux 上ip addr显示NO-CARRIER或者干脆没有 IPv4 地址。

第一种修法是刷新租约。Windows 上依次执行：

ipconfig /release ipconfig /renew ipconfig /flushdns

Linux 上用nmcli或者重启 NetworkManager：

sudo nmcli networking off && sudo nmcli networking on # 或者 sudo systemctl restart NetworkManager

第二种修法是手动指定静态地址。当虚拟 DHCP 服务怎么都起不来，又急着用的时候，直接绕过它。参数参考这张表：

注意，静态 IP 一定要避开 DHCP 的地址池范围，否则可能出现“两台机器抢一个地址”的诡异现象，表现为时通时不通，非常难查。

3.3 DNS 配错导致的“能ping通但打不开网页”

这是最经典的一种“假断网”。前三跳全通，浏览器就是打不开页面，报“找不到服务器”或者“DNS 解析失败”。

Linux 上先看三处：

cat /etc/resolv.conf # 最直接，看 nameserver systemd-resolve --status # 用 systemd 的系统看实际生效的 DNS nmcli dev show | grep DNS # 看 NetworkManager 下发的 DNS

/etc/resolv.conf有一个坑：在某些发行版上它是个软链接，由 NetworkManager 或者 systemd-resolved 动态生成，你手改完重启网络就被覆盖了。正规做法是改网卡配置或者用nmcli设置，而不是直接编辑这个文件。我在用的一些新版发行版上，/etc/resolv.conf甚至指向127.0.0.53，这是本地解析服务，真正的上游 DNS 得用resolvectl查。

sudo resolvectl dns # 查看各网卡的上游 DNS sudo resolvectl dns eth0 114.114.114.114 # 临时指定

Windows 上排查更简单，nslookup一试就知道：

nslookup www.example.com nslookup www.example.com 114.114.114.114

第一次失败第二次成功，那就是 DNS 配置的问题，去网卡属性里把 DNS 手动指定成公共地址即可。

另外一个隐蔽的情况是虚拟机里改了 hosts 文件。之前调试时加过一条域名映射，忘了删，结果那个域名永远解析到一台已经不存在的机器上。排查时顺手cat /etc/hosts看一眼，省事。

3.4 一键重建 NAT 网络的正确姿势

如果上面几招都无效，或者你确实把配置改得面目全非，那就重建。操作路径是：虚拟网络编辑器 → 更改设置 → 选中 VMnet8 → 点“还原默认设置”。

这个操作的实质是卸载并重装所有 VMware 虚拟网卡，然后恢复默认网络配置。执行完之后有三件事要注意：

第一，重启宿主机或者至少禁用再启用一次虚拟网卡，让系统重新识别。

第二，所有虚拟机的网络配置会回到 NAT 默认状态，之前设了静态 IP 的机器需要重新配。

第三，自定义的端口映射会丢失，如果有做外部访问的转发规则，得重新加。

我通常把这个操作放在最后，因为成本比较高。先按前几节走完，绝大多数问题能提前解决。

4. 桥接模式断网：九成问题出在网卡选择上

4.1 自动桥接为什么不可靠

桥接模式的故障率明显高于 NAT，原因只有一个：它要挑物理网卡。

虚拟机设置里桥接模式默认是“自动”，含义是让 VMware 自己判断该桥接到哪块物理网卡上。这台机器上有线网卡、无线网卡、甚至还有一堆虚拟网卡的时候，它的判断经常出错，可能桥接到一块根本没连网的网卡上。

处理方法很直接：在虚拟机的“设置 → 网络适配器”里，把模式选成“桥接”，然后勾选“复制物理网络连接状态”，再到虚拟网络编辑器里把 VMnet0 的桥接目标手动指定为你当前正在用的那块物理网卡。有线就选有线，无线就选无线，名字通常一眼能认出来。

这一步做完，桥接失败的问题能解决大半。

4.2 无线网卡桥接的特殊处理

无线网卡做桥接比有线麻烦。部分无线网卡驱动不支持混杂模式，虚拟机发出的帧带着自己的 MAC 地址，而无线接入点只认已经完成认证的那个 MAC，于是这些帧就被丢了，表现是虚拟机拿不到 IP，或者能拿到 IP 但网关不通。

几种处理思路：

• 换成有线连接做桥接，这是最省事的办法，如果条件允许直接用。
• 改用 NAT 模式，如果只是要上网，桥接本身没有必要性。
• 在虚拟网络编辑器里切换桥接的物理网卡，有时候换个无线网卡（比如笔记本自带的那个和 USB 的）表现完全不同。
• 检查无线网络是否开启了客户端隔离，公共网络里面很常见，即使桥接成功，虚拟机也访问不到局域网里的其他设备。

4.3 桥接后的IP规划与冲突排查

桥接模式下虚拟机用的是物理局域网的地址段，这就带来一个新问题：地址冲突。如果虚拟机里设了静态 IP，而这个 IP 恰好和局域网里某台设备撞了，表现就是两台机器轮流掉线，非常折磨人。

排查方法是：先让虚拟机用 DHCP 自动获取，确认能正常上网之后，再把拿到的地址固定下来。固定前在宿主机上执行一次arp -a看一下局域网里已经有哪些地址在用，避开它们。

现代路由器一般都有 DHCP 租约列表，登录路由器管理界面能直接看到哪些地址被分配出去了，比盲猜靠谱。没有管理权限的话，就选一个地址池末端不太可能被用到的地址，比如网段里的.200以上，冲突概率很低。

5. 仅主机模式与特殊场景的取舍

5.1 只想宿主机和虚拟机互通的正确配置

仅主机模式的配置极其简单：虚拟机网络适配器选“仅主机”，宿主机上对应的 VMnet1 网卡保持启用，两边配在同一网段即可。默认情况下 VMware 的虚拟 DHCP 会给虚拟机发地址，宿主机的 VMnet1 一般是网段里的.1。

验证方式就是宿主机 ping 虚拟机，虚拟机 ping 宿主机，能通就完事。这时候虚拟机访问外网是不通的，这是设计如此，不是故障。如果确实需要让虚拟机访问外网，那就不该用仅主机模式，直接换 NAT。

有个需求很常见：既想让虚拟机访问外网，又想让宿主机和虚拟机之间有一个固定不变的连接。做法是给虚拟机加第二块网卡，一块走 NAT 出网，一块走仅主机做宿主机互连。这样 IP 固定、断网也不影响本地调试。

5.2 双网卡组合：一个上网一个内网

多网卡配置的关键是默认路由只能有一条，否则会出现奇怪的断流。具体原则是：

• 出网的那块网卡（NAT 或桥接）配置默认网关。
• 内网的那块网卡（仅主机）只配 IP 和掩码，不配网关。

如果配了两条默认路由，系统会根据跃点值选一条，另一条流量就走不通，表现出来就是“有时候能上网有时候不行”。Windows 上用route print看，Linux 上用ip route show看，如果看到两条default记录，删掉内网的那条：

sudo ip route del default via 192.168.x.1 dev eth1

这个坑我在搭建本地测试集群的时候踩过，两台虚拟机互相能 ping 通，但都上不了网，最后发现是内网网卡抢了默认路由。

5.3 快照、克隆带来的MAC与网卡错乱

克隆虚拟机是另一个高频故障源。VMware 克隆时会问你是“创建完整克隆”还是“创建链接克隆”，不管哪种，MAC 地址必须重新生成。两台虚拟机 MAC 一样，接在同一个虚拟交换机上，交换机会直接懵掉，表现为两台机器都时通时不通。

虚拟机设置 → 网络适配器 → 高级 → 点“生成”按钮，重新生成一个 MAC。这一步花不了十秒钟，但能省掉几个小时的排查。

另外，从快照恢复之后也建议检查一下网卡状态。有些系统在快照恢复后会认为网卡是“新硬件”，重新枚举一遍，原来的网络配置就失效了，表现为网络图标带感叹号，重新配一次 IP 就好。

6. 客户机内部的分层排查手册

6.1 Windows客户机的四条命令

Windows 客户机排查，我固定跑这四条：

ipconfig /all # 看全部网络信息，包括 DHCP 服务器、DNS、MAC ipconfig /release # 释放当前租约 ipconfig /renew # 重新申请 nslookup www.example.com # 验证解析

ipconfig /all里重点看三项：有没有拿到 IPv4 地址、默认网关是不是虚拟网络的网关、DHCP 服务器地址是不是虚拟网络里的那个。如果 DHCP 服务器显示为空，说明请求压根没发出去或者没人应答，回到宿主机查服务。

网络栈被搞乱的情况下，用这两条命令重置：

netsh winsock reset netsh int ip reset

执行完必须重启才生效。这招对“本来好好的，装了个软件之后突然上不了网”这类问题特别管用，因为有些安全软件会往网络栈里插过滤驱动，卸载不干净就留下后遗症。

6.2 Linux客户机从网卡到DNS逐层确认

Linux 上我一般按这个顺序走：

ip link show # 网卡是不是 UP 状态 ip addr show # 有没有 IPv4 地址 ip route show # 默认路由在不在 cat /etc/resolv.conf # DNS 配置 ping -c 3 网关地址 ping -c 3 114.114.114.114 ping -c 3 www.example.com

ip link show如果显示state DOWN，先sudo ip link set eth0 up拉起来。如果显示NO-CARRIER，说明链路层没连上，问题在虚拟机的网络适配器设置，不是系统内部。

新版发行版大多用 NetworkManager 或 netplan 管理网络。用 netplan 的系统配置文件在/etc/netplan/下，改完要执行sudo netplan apply；用 NetworkManager 的直接nmcli就行：

nmcli connection show nmcli connection modify "有线连接 1" ipv4.method auto nmcli connection up "有线连接 1"

有个细节值得提：VMware Tools 影响网卡驱动。安装了 Tools 之后，虚拟网卡可能从e1000换成vmxnet3，性能更好，但如果 Tools 安装不完整或者版本不匹配，网卡可能直接认不出来。遇到ip link里压根没有以太网设备的情况，先在虚拟机设置里把网卡类型改成e1000试试，能认出来就说明是驱动兼容问题。

6.3 防火墙与安全软件的拦截识别

防火墙导致的“上不了网”有个典型特征：能 ping 通 IP，但某些端口连不上。比如能 ping 通 114.114.114.114，但浏览器打不开任何网页，因为 80/443 被拦了。

Windows 上临时关掉防火墙验证一下：

netsh advfirewall set allprofiles state off

验证完记得开回来。Linux 上：

sudo systemctl stop firewalld # CentOS 系 sudo ufw disable # Ubuntu 系

如果关了就好了，那就是规则问题，去防火墙里放行对应端口，而不是长期关着防火墙。

还有一种情况是宿主机上的安全软件拦截了虚拟网卡的流量。这类软件有时会把 VMware 的虚拟网卡识别成可疑设备，直接切断它的通信。判断方法是看它的拦截日志，或者在它的网络防护设置里把 VMnet1、VMnet8 加入信任列表。

7. 典型故障速查表与踩坑实录

7.1 症状到原因速查表

7.2 几个反直觉的坑

坑一：宿主机连着需要认证的网络。有些公共网络要先在浏览器里点同意才能上网，这时候宿主机自己都还没通，虚拟机当然上不去。有次在会议室折腾了半小时，最后发现是宿主机没点那个登录按钮。

坑二：系统时间不同步导致的“打不开网页”。部分站点对时间偏差很敏感，虚拟机关机放几天再开，时间落后一大截，访问会直接被拒。表现和网络故障极像，但ping全通。装个时间同步服务就能避免。

坑三：MTU 不匹配。虚拟网络默认 MTU 是 1500，而某些拨号链路实际是 1492，大包发不出去，小包正常。表现是能打开简单页面，图片多的页面一直转圈。验证方法是用不分片的包试探：

ping -f -l 1472 114.114.114.114

不通就逐步减小包长，找到能通过的最大值，然后相应调小网卡的 MTU。

坑四：虚拟机设置里“已连接”没勾。这个坑我每年都要撞上一次。虚拟机的网络适配器设置里有两个复选框，一个是“已连接”，一个是“启动时连接”。后者没勾，虚拟机重启后就断网；前者没勾，当时就断网。两个都得勾上。

坑五：开了某些虚拟化相关组件之后桥接失效。宿主机如果启用了系统自带的虚拟化平台功能，可能和 VMware 的桥接驱动打架，表现就是桥接死活不通，NAT 正常。这种情况要么关掉那个功能重启，要么干脆用 NAT。

7.3 兜底手段与我的日常习惯

配置改乱了又懒得一步步查，我直接按这个顺序兜底：先在虚拟网络编辑器里还原默认设置，重启宿主机的 VMware 相关服务，再开虚拟机跑一次 DHCP。三步下来九成问题能自愈。

日常使用上，我养成几个习惯，能省不少事：

• 虚拟机一律先装 VMware Tools，网卡驱动、时间同步、剪贴板共享都靠它，装与不装差别很大。
• 克隆完立刻改 MAC，别等出问题再回头找。
• 给每台虚拟机记一笔网络用途，是 NAT 出网还是仅主机内网，写个备注在虚拟机名字后面，半年后回来看不至于懵。
• 重要环境拍快照之前先确认网络是通的，免得回滚到一个断网状态自己还不知道。
• 宿主机换了网络环境（换 Wi-Fi、插网线）之后，桥接模式要重新确认一次物理网卡，这是我遇到频率最高的一类“突然上不了网”。

虚拟机网络这块，说到底就那么几个变量：用哪种模式、桥到哪块网卡、虚拟网段配得对不对、客户机内部拿没拿到正确参数。把这四个问题按顺序问一遍，绝大多数断网都能在十分钟内定位。真正耗时间的从来不是技术难度，是排查顺序乱了、在错误的层面上反复尝试。