虚拟机装完系统，打开终端敲了条 ping，屏幕上清一色的请求超时，浏览器转圈转到怀疑人生——这个场景我在不同机器上见过太多次。VMware Workstation 虚拟机连不上网这件事，绝大多数时候不是软件坏了，而是三种网络模式（桥接、NAT、仅主机）的边界没搞清楚，排查方向一开始就跑偏了。有人一看不通就直接重装虚拟机，有人到处改 DNS，还有人把宿主机的防火墙关了个遍，最后发现问题出在虚拟网络编辑器里桥接目标选错了一块网卡。

这篇内容就是把这类问题按“先判断、再定位、最后动手”的顺序捋一遍。适合刚接触虚拟机的新手，也适合用了几年的老手做一份排错清单——毕竟虚拟网络这东西，配置一次能用很久，等真出问题时细节早就忘干净了。下面这些步骤都是我在实际环境里反复验证过的，涉及命令的地方都给了可直接复制的写法。

1. 先分清三种网络模式的连通边界，再谈修

虚拟网络排查最容易犯的错，是拿着 NAT 模式的思路去修桥接模式的问题。三种模式在底层走的路径完全不同，连“虚拟机该不该有独立 IP”这个最基本的问题，答案都不一样。所以动手之前，先花两分钟确认当前虚拟机用的是哪种模式，这一步能省掉后面一大半的无效操作。查看方式很简单：虚拟机设置 → 网络适配器，右侧就能看到“桥接”“NAT”“仅主机”三个单选项，以及“自定义”指向的具体 VMnet。

1.1 桥接：虚拟机被当成局域网里的一台真机

桥接模式的本质，是把虚拟机的虚拟网卡“搭”在宿主机的一块物理网卡上，让虚拟机以一个独立设备的身份出现在宿主机所在的局域网里。它需要向上一级的路由器或交换机申请地址，拿到的是和宿主机同网段的 IP，比如宿主机是 192.168.1.20，虚拟机可能是 192.168.1.35。局域网里其他机器能直接 ping 通这台虚拟机，虚拟机也能被当成本地设备访问。

这个特性决定了桥接模式的两个硬性前提：第一，上游网络必须还有空闲地址可以分配；第二，上游网络必须允许一台“新设备”接入。前者靠 DHCP 解决，后者在很多受限网络里是过不去的坎。我遇到过不少情况是虚拟机 DHCP 一直转圈拿不到地址，但宿主机上网完全正常，原因就是上游做了接入限制。桥接模式还有个隐性依赖——宿主机的物理网卡驱动要能支持这种“多设备共享”的工作方式，部分无线网卡驱动在这块表现不稳定，表现为能连上但丢包严重或者干脆握手失败。

1.2 NAT：宿主机当前台，虚拟机在后台

NAT 模式走的是另一条路。Workstation 会创建一块名为 VMnet8 的虚拟网卡，虚拟机接入这个虚拟交换机，由一个内置的虚拟 DHCP 服务分配地址，默认网段通常是 192.168.x.0/24。虚拟机所有出网的流量都交给宿主机，由宿主机做地址转换后从物理网卡发出去，回来的数据再转回给虚拟机。

这套机制带来的好处很直接：虚拟机不需要上游网络给地址，宿主机的网络环境怎么变都不影响虚拟机内部配置，换个 Wi-Fi、插上网线，虚拟机照样能上网。代价是反向不通——局域网里的其他设备看不到这台虚拟机，想让外部访问虚拟机上的服务，得在虚拟网络编辑器里做端口映射。很多人抱怨“NAT 模式下虚拟机连不上网”，其实问题往往出在宿主机的转发链路上，而不是虚拟机内部。

1.3 仅主机：一条只连宿主机的网线

仅主机模式对应 VMnet1，它创建的是一条只在宿主机和虚拟机之间存在的封闭链路。虚拟机能和宿主机互相通信，能访问宿主机上跑的服务，但出不了宿主机这一层，外网完全是断的。这个模式的设计目的就是隔离，用来做安全测试、搭建不联网的实验环境、验证内网服务之间的调用关系。

所以我见过最常见的“误判故障”，就是有人用仅主机模式装完系统，发现上不了网，然后开始一通排查。这不是故障，这是这个模式的正常表现。判断方法很简单：如果虚拟机设置里选的是“仅主机”，那它本来就该连不上外网，需要联网就换成 NAT 或者加第二块网卡。把这一点先记住，能避免后面走弯路。

1.4 三模式对照表与选型建议

把三种模式的差异整理成一张表，排查时可以对着看，比在脑子里反复推演快得多。

选型上我的建议是：日常学习、装各种系统练手，一律用 NAT，省心且不受网络环境限制；需要让同事或手机访问虚拟机上跑的服务，用桥接；做隔离验证或者模拟纯内网架构，用仅主机，必要时给虚拟机加第二块网卡，一块仅主机一块 NAT，两边都不耽误。

2. 从虚拟机内部开始逐层验证，别一上来就重装

确认了模式之后，下一步是从虚拟机内部往外查，而不是先动宿主机的配置。原因很实际：虚拟机内部的状态是最容易获取、也最容易证伪的。网卡有没有被识别、有没有拿到地址、网关通不通、域名能不能解析，这四步走完，问题范围基本就缩小到一两个点了。反过来，如果先动宿主机的虚拟网络编辑器，一旦改错，反而会引入新的变量，让原本清晰的问题变复杂。

2.1 网卡是否被系统认到，这一步定了后面一半的排查方向

虚拟机装完系统后网卡不认，是排错链条上最靠前的一环。Linux 下执行ip link或者ip addr，看有没有除 lo 之外的网络接口；如果只有 lo，说明系统压根没识别到虚拟网卡。这时候可以看内核日志：

dmesg | grep -i -E "eth|ens|eno|vmxnet|e1000"

如果日志里有网卡探测记录但接口没起来，多半是驱动加载或者配置文件的问题；如果连探测记录都没有，那问题在虚拟机层面的硬件配置，需要回头看虚拟机的网络适配器是不是被勾掉了“启动时连接”。Windows 虚拟机则打开设备管理器，看“网络适配器”下面有没有带黄色感叹号的设备，有的话就是驱动没装上，装一下 VMware Tools 基本能解决。

这一步之所以关键，是因为它把问题分成了两类：网卡都没认到，后面查 IP、查 DNS 全是白费功夫；网卡认到了但没地址，那才轮到下一层。我见过太多人跳过这步直接去改 DNS，结果折腾半天发现是网卡没启用。

2.2 地址、掩码、网关三件套怎么核对

网卡认到了，接下来确认地址配置是否合理。Linux 用ip addr看地址和掩码，ip route看默认路由；Windows 用ipconfig /all看完整信息。这里有几个容易忽略的细节。

第一，看地址是不是 169.254 开头的。这个网段是系统在拿不到 DHCP 响应时自动分配的链路本地地址，出现它基本等于“DHCP 没通”，问题在上游，不在虚拟机内部。第二，看默认网关在不在。NAT 模式下网关通常是虚拟网段的第二个地址（比如 192.168.x.2），如果ip route里压根没有 default 那条，那外网肯定不通，先补网关。第三，看掩码是否和网关匹配，手动配静态地址时掩码写成 255.255.255.0 但网关配成另一个网段的地址，这种低级错误实际出现频率不低。

在 NAT 模式下还有一个常被忽略的点：虚拟机的地址必须落在 VMnet8 对应的网段里。如果之前手动配过静态地址，后来虚拟网络被还原成默认设置，网段变了，虚拟机还拿着旧地址，表现就是网关 ping 不通。这种情况直接改成 DHCP 重新获取一次最快。

2.3 能 ping 通 IP 却打不开网页：DNS 的位置

这是最典型的一类“假断网”。ping 一个公网 IP是通的，但浏览器打开域名就失败。这说明链路层和网络层都没问题，问题出在域名解析上。验证方法很直接：

nslookup www.example.com

如果返回解析失败或者超时，那就是 DNS 服务器地址不对或者不可达。Linux 下看/etc/resolv.conf，注意这个文件在很多发行版上会被网络管理服务覆盖，改完重启就没了，正确做法是在网络配置里写 DNS，而不是直接改这个文件。用 Netplan 的发行版在 YAML 里写nameservers: addresses:，用 NetworkManager 的用nmcli设置。Windows 则在网卡属性里改 IPv4 的 DNS 服务器地址。

NAT 模式下还有一个特殊情况：虚拟网络编辑器里有一个“使用本地 DHCP 服务将 IP 地址分配给虚拟机”的选项，某些版本里 NAT 设置中还能配置是否传递 DNS。如果宿主机本身的 DNS 就不稳定，虚拟机也会跟着出问题。判断方法是拿宿主机做对照，宿主机能正常解析而虚拟机不能，那问题在虚拟网络的 DNS 传递链路上。

2.4 用 tracert/traceroute 把断点定位到具体一跳

链路到底断在哪一段，靠猜效率太低，直接用路由追踪看。Windows 下tracert 目标域名，Linux 下traceroute 目标域名或tracepath。正常情况第一跳就是网关，也就是 VMnet8 对应的宿主机虚拟网卡地址；NAT 模式下后续几跳是宿主机的出口路径。

如果第一跳就超时，说明虚拟机和宿主机之间的虚拟链路就不通，问题在 VMnet8 或者虚拟机的地址配置上。如果第一跳通、后面全超时，说明虚拟机到宿主机没问题，是宿主机往外转发这一环断了，重点查宿主机的网络和 NAT 服务。如果追踪能一路走通但最后几跳超时，那可能只是目标网络对 ICMP 有限制，实际网页是能打开的，别被误导。

我习惯把 ping 网关、ping 公网 IP、tracert 三步连起来做，三分钟就能把问题锁在“虚拟机内部”“虚拟网络”“宿主机出口”三个区间里的一个，比漫无目的地试配置高效得多。

3. 宿主机的虚拟网络编辑器，才是大多数故障的案发现场

虚拟机内部查不出问题，就该把视角切到宿主机了。Workstation 的虚拟网络全部由“虚拟网络编辑器”管理，入口在菜单栏的“编辑”里，打开需要管理员权限。这个界面里藏着几个关键开关，配置一旦出错，虚拟机内部怎么改都没用。有意思的是，很多人的问题并不是自己改坏的，而是软件升级、系统更新、装了个新网卡之后，这些配置被自动重置或者自动选择到了错误的目标上。

3.1 VMnet0/VMnet1/VMnet8 到底各管什么

虚拟网络编辑器里的列表通常能看到 VMnet0、VMnet1、VMnet8 三个条目（有时候还有额外的 VMnet2、VMnet3 等自定义网络）。VMnet0 是桥接用的，类型显示为“桥接”；VMnet1 是仅主机；VMnet8 是 NAT。这三块虚拟网卡在宿主机的“网络连接”面板里也能看到，名字就叫“VMware Network Adapter VMnet1”之类。

排查时先确认这几点：VMnet8 是否处于“已连接”状态、类型是不是 NAT、有没有勾选“将主机虚拟适配器连接到此网络”。最后这个选项一旦取消，宿主机和虚拟机之间就少了一条通路，表现是虚拟机能拿到地址但网关不通。VMnet1 同理，如果没勾选连接，仅主机模式下宿主机和虚拟机也通不了。这几项看起来琐碎，但真出问题时往往就是某个勾被取消了。

3.2 桥接目标网卡自动选择，是坑中之坑

桥接模式有个“桥接到”的下拉框，默认是“自动”。自动选择的逻辑是让软件自己挑一块物理网卡，问题是它挑的未必是当前正在用的那块。宿主机上有线网卡、无线网卡、蓝牙虚拟网卡、各种虚拟网卡同时存在时，自动选择很容易挑到一块没连网的设备上，表现出来就是虚拟机 DHCP 一直转圈或者拿了地址也出不去。

解决方式很直接：把“自动”改成手动指定，明确选中当前实际联网的那块物理网卡。这一步在笔记本上尤其重要，因为笔记本经常在无线和有线之间切换，自动选择的判断会跟着变。另外，如果你用的是无线网卡做桥接，某些驱动下桥接会不稳定，优先考虑改用 NAT，或者插网线。改完记得点“应用”，只在界面上改了不应用是不生效的。

还有一个隐蔽情况：宿主机的物理网卡名称里带中文或者特殊字符时，桥接配置偶尔会出问题，把网卡重命名成纯英文再试一次，能排掉一批莫名其妙的现象。

3.3 两个后台服务没起来，NAT 和 DHCP 就都是摆设

NAT 和 DHCP 在 Workstation 里是由两个系统服务提供的。打开services.msc，找“VMware DHCP Service”和“VMware NAT Service”，这两个服务的状态必须是“正在运行”，启动类型建议设为“自动”。如果被停掉了，现象非常典型：NAT 模式下虚拟机拿不到地址，或者拿到地址但完全出不了网。我遇到过系统优化工具把它们当成无用服务禁掉的情况，排查半天才想起来查服务列表。

用命令行也能快速确认和拉起（需要管理员权限的命令行）：

sc query "VMware NAT Service" sc start "VMware NAT Service" sc query "VMware DHCP Service" sc start "VMware DHCP Service"

服务起不来还有一层原因：宿主机上装了其他虚拟化软件或者网络工具，端口或者驱动层冲突，导致服务启动失败。这时候看 Windows 事件查看器里的应用日志，会有明确报错。

另外提一个容易撞车的点：Windows 自带的“Internet 连接共享”如果被启用，会占用 NAT 相关的组件，两者搅在一起容易互相干扰。排查时确认一下宿主机的网络连接属性里共享那一栏是不是勾着的。

3.4 防火墙与安全软件拦截的判断方法

宿主机的防火墙对虚拟网络的拦截，表现通常是“虚拟机能 ping 通网关但出不去”，或者“宿主机能访问虚拟机、虚拟机访问不了宿主机上的服务”。判断方法：临时关闭宿主机防火墙做一次对照测试，通了就说明是规则问题，测完立刻恢复，然后针对 VMware 的虚拟网卡添加放行规则，而不是长期关着。

这里要注意方向：虚拟机通过 NAT 出网时，流量在宿主机看来是从 VMnet8 发出的，防火墙如果把 VMnet8 这块虚拟网卡识别为“公用网络”并按公用网络的严格策略处理，就会拦掉一部分流量。把 VMnet1、VMnet8 的网络位置类型改成“专用”，能解决相当一部分玄学问题。第三方安全软件同理，有些会拦截虚拟网卡的流量，加白名单即可。做完这类改动后建议重启一次虚拟机的网络服务，避免缓存状态影响判断。

4. 三种模式各自的翻车场景与针对性修法

前面几章讲的是通用排查路径，这一章按模式拆开讲，因为三种模式的高频故障点差别很大。对号入座比从头查一遍快得多，尤其是你已经明确知道当前用的是哪种模式的时候。下面每一种都给出典型现象和对应处理方式，照着做基本能覆盖八成的场景。

4.1 桥接模式在受限网络里的失败：不是配错了，是没权限

桥接模式最常见的失败不是在虚拟机里，而是在上游网络。校园网、企业办公网这类环境经常做 MAC 地址绑定、端口隔离、DHCP 地址数量限制，虚拟机作为一个“新设备”接入时直接被挡在门外。现象是虚拟机反复发 DHCP 请求但拿不到地址，或者拿到地址后网关不通、只有本机可通。

这类情况下继续在虚拟机里折腾是没有意义的，因为权限不在你手里。可行的做法有三条：一是改用 NAT 模式，让宿主机做转发，绕过接入限制；二是在允许的范围内手动配置一个同网段的空闲静态 IP，前提是你确认这个地址没被占用且有权限使用；三是换一个不受限的网络环境测试，用来验证是不是网络侧的问题。我个人的经验是，在别人的网络环境里优先用 NAT，别去硬碰接入策略，省时间。

还有一种桥接特有的现象：虚拟机能上网，但过一段时间就断，重连才好。这通常和无线网卡的省电策略有关，把无线网卡的电源管理里“允许计算机关闭此设备以节约电源”取消勾选，稳定性会明显改善。

4.2 NAT 模式的三个高频故障：网段撞车、地址池空了、映射没开

NAT 模式的故障率其实不高，但一旦出问题，基本集中在这三个点。

第一个是网段撞车。VMnet8 默认分配 192.168.x.0/24 这样的网段，如果宿主机所在的物理局域网恰好也是同一个网段，路由就会混乱，表现是虚拟机能上某些网站但上不了另一些，或者干脆全断。解决办法是在虚拟网络编辑器里把 VMnet8 的子网地址改成别的网段，比如 192.168.150.0，掩码 255.255.255.0，改完重启虚拟机的网络。

第二个是 DHCP 地址池耗尽或者配置异常。虚拟网络编辑器里 NAT 设置中可以看 DHCP 的地址范围，如果范围设得很小，同时开了多台虚拟机，就会分配不出地址。把范围调大一点，或者给虚拟机配静态地址绕开 DHCP。

第三个是端口映射没生效。想让局域网访问虚拟机上的服务，需要在 NAT 设置里添加端口转发规则，把宿主机的某个端口映射到虚拟机的 IP 和端口。规则加了不生效，通常是虚拟机 IP 变了导致映射失效，或者宿主机防火墙拦了对应端口。这两点都确认一遍。

4.3 仅主机模式连不上外网，本来就该这样

仅主机模式的“连不上外网”不是故障，但如果虚拟机连宿主机都通不了，那就是真问题了。检查方向有两个：一是虚拟网络编辑器里 VMnet1 是否勾选了“将主机虚拟适配器连接到此网络”，没勾选的话宿主机上那块 VMnet1 网卡就是断开状态；二是虚拟机自己的地址是否和 VMnet1 网卡在同一网段。

如果业务上确实需要“既能访问外网，又能和宿主机组成一个隔离内网”，正确做法是给虚拟机加第二块网卡：一块设为 NAT 负责出网，一块设为仅主机负责内网通信。Windows 下会有两个网络接口，注意调整接口跃点数，让默认路由走 NAT 那块，否则可能出现内网通了外网不通的怪现象。Linux 下用ip route确认默认路由指向的是 NAT 网卡对应的网关。

4.4 克隆、快照回滚后的地址冲突与MAC重复

从模板克隆出来的虚拟机，如果没做“重新生成 MAC 地址”，多台机器会带着同一个 MAC 出现在网络里。桥接模式下这个问题的后果很直接：上游交换机的端口安全策略会把这两台机器都判定为异常，表现是网络时断时续，或者两台机器互相抢占同一个 IP。

处理方式是打开虚拟机设置，在网络适配器的高级选项里点“生成”重新生成一个 MAC，或者手动改最后几位。Linux 虚拟机克隆后还要注意网卡配置文件里的 UUID 和 MAC 绑定，如果配置里写死了旧 MAC，新网卡不会被应用，表现是网卡存在但没有地址。快照回滚后也类似，回滚到的那个时间点如果网络配置和当前环境不匹配，就得重新配一次。我的习惯是克隆完成后的第一件事就是重新生成 MAC 并清空网络配置，让它重新走一次 DHCP，省得后面踩坑。

5. 我常备的一套修复动作清单

排查到最后如果还没定位到，我会按这套清单从轻到重依次执行。顺序是有讲究的——先做破坏性最小的，每做一步就测一次连通性，确认是不是这一步解决的，避免一次性改一堆东西导致问题复现不了。

5.1 还原默认虚拟网络：先备份再动手

虚拟网络编辑器的左下角有“还原默认设置”，它会删掉现有的虚拟网卡并重建一套。这一步能解决大量因为配置被改乱导致的疑难杂症，但代价是所有自定义的子网、DHCP 范围、端口映射都会丢失。所以动手前先把当前配置截图或者记下来，尤其是端口映射规则。

操作时注意要先点“更改设置”获取管理员权限，否则按钮是灰的。还原过程中会短暂断开宿主机的虚拟网卡，如果宿主机上有依赖 VMnet 的软件在跑，先停掉。还原完成后宿主机会重新识别虚拟网卡，稍等一会儿再看“网络连接”面板里 VMnet1 和 VMnet8 是否都回来了，没回来的话在设备管理器里扫描一次硬件变更。这一步做完，绝大多数网络配置类的问题都能归零。

5.2 手动静态IP的正确写法与易错点

需要固定地址时，静态 IP 是最直接的办法。NAT 模式下要记住几个固定值：VMnet8 在宿主机上的地址通常是网段的第一个（比如 192.168.150.1），NAT 网关是第二个（192.168.150.2），DHCP 分配的地址一般从 128 之后开始。给虚拟机配静态地址，选 3 到 127 之间的数字比较安全，避开可能被 DHCP 分配的范围。

Linux 用 Netplan 的发行版，配置大致长这样：

network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.150.50/24 routes: - to: default via: 192.168.150.2 nameservers: addresses: [192.168.150.2]

易错点有三个：网卡名不要照抄，用ip link看实际的；缩进必须是空格不能是 Tab，YAML 对缩进极其敏感；改完执行sudo netplan apply，报错信息会直接告诉你哪一行有问题。传统 ifcfg 风格的发行版改/etc/sysconfig/network-scripts/ifcfg-xxx，把BOOTPROTO改成static，补上网关和 DNS，然后重启网络服务。

5.3 换虚拟网卡型号解决兼容性断网

有些系统装完之后网络时通时不通，或者流量一大就断，这种情况可以考虑换虚拟网卡型号。Workstation 支持 e1000e、vmxnet3 等几种虚拟网卡，默认通常选的是兼容性最好的那种，但某些新系统内核上默认型号的驱动反而不如 vmxnet3 稳定。

改法是关机后编辑虚拟机的.vmx配置文件，找到ethernet0.virtualDev这一行，把值改成"vmxnet3"，保存后开机。如果这行不存在就手动加上。改完进系统用ip link确认网卡被识别，必要时重新配一次地址。注意换型号后虚拟网卡的 MAC 可能会变，如果之前做过 MAC 绑定的配置要同步更新。

.vmx文件是纯文本，改之前复制一份备份，改错了直接覆盖回去。这个文件里还有ethernet0.connectionType记录着网络模式（nat/bridged/hostonly），排查时顺手看一眼，能确认虚拟机的配置和界面显示是否一致。

5.4 彻底清理重装：.vmx与驱动残留

前面几步都无效，才考虑卸载重装。卸载 Workstation 时要注意几处残留：宿主机的虚拟网卡、安装目录下的配置文件、以及系统里的驱动注册信息。直接覆盖安装有时候解决不了问题，需要先彻底卸载再装。

建议的清理顺序：先在虚拟网络编辑器里还原默认设置，再通过控制面板卸载程序，卸载过程中如果提示是否保留配置，选择不保留。卸载完成后检查“网络连接”面板里有没有残留的 VMnet 网卡，有的话在设备管理器里卸载设备并勾选删除驱动程序。重启之后重新安装，安装完成后第一时间打开虚拟网络编辑器还原一次默认设置，然后开机测试。

这套流程走下来，如果还是不通，那基本可以排除软件层面，问题在宿主机的系统网络栈或者上游网络策略上，需要换个思路查，比如换一台宿主机测试同样的虚拟机镜像，用对照法定位。

装虚拟机这些年，我现在形成一个固定习惯：新建虚拟机后先确认网络模式，NAT 作为默认选项；然后进系统第一件事是看ip addr和ip route，把地址、网关、DNS 三项记下来；最后 ping 网关、ping 公网、解析一个域名，三步全过才算配置完成。这套动作花不到三分钟，但能避免之后 90% 的“突然连不上网”。另外提醒一句，做任何修改前先给虚拟机打个快照，尤其是改.vmx文件和虚拟网络编辑器的时候，出问题一条命令就能退回去，比事后回忆改了什么靠谱得多。