上周帮同事处理一台连不上网的虚拟机，他从上午折腾到下午，改了静态 IP、重置了网卡、重装了一遍系统，问题还在。我接手后先没碰虚拟机，而是在主机上敲了两条命令，八分钟后定位到原因——主机侧一个网络相关服务被安全软件顺手关掉了。这件事让我又一次确认：虚拟机连不上网，绝大多数时候不是虚拟机自己的问题，而是网络模式、主机服务、虚拟机内部配置这三层里某一层断了。盯着虚拟机内部反复改 IP，是最典型的白忙。
这篇内容就是把我这些年处理"虚拟机连不上网"的几种常见情形、对应的解决方法，以及排查顺序完整写出来。涉及 VMware Workstation、VirtualBox 这类主流虚拟化软件，也涉及 Linux 和 Windows 两类客户机的具体配置。不管你是刚装完虚拟机发现没网的新手，还是遇到过"昨天还好今天就不通"的老手，都能在里面找到能直接抄的步骤。我尽量把每一步的"为什么"讲清楚，因为只有知道原理，下次遇到变形的问题你才能自己判断，而不是挨个试。
1. 先把"虚拟机没网"拆成三层：模式、服务、系统内部
很多人处理这个问题的第一反应是打开虚拟机里的网络设置，看一眼 IP 是不是169.254.x.x，然后手动填一个静态地址。这个动作本身没错，但它跳过了前两层排查，成功率大概只有三成。我把整个链路分成三层来看，效率会高很多。
1.1 三层各自的职责边界
第一层是网络模式，也就是虚拟机网卡被接到了哪个虚拟交换机上。桥接、NAT、仅主机这三种模式决定了虚拟机的数据包往哪走，模式选错的话，虚拟机内部再怎么配都出不去。
第二层是主机侧的虚拟网络组件，包括虚拟网卡（VMnet1、VMnet8 这类）、DHCP 服务、NAT 服务、虚拟网络编辑器里的网段设置。这一层是 Windows 主机上出问题最多的地方，因为它牵扯到系统服务、驱动、防火墙、甚至其他虚拟化软件的抢占。
第三层才是客户机系统内部的配置，IP 地址、网关、DNS、网卡是否启用、网络管理服务是否在跑。
这三层是自上而下的依赖关系。上层不通，下层配置再完美也没用。我见过太多人在第三层反复折腾，其实问题在第一层——网卡模式被设成了"仅主机"，那当然上不了外网。
1.2 十分钟定位法：四条命令判断断点在哪
我一般用下面这个顺序快速定位，全程不需要改任何配置，只是"看"：
# 在虚拟机内执行，先看有没有拿到 IP ip addr # Linux ipconfig /all # Windows 客户机 # 看默认网关和路由 ip route # Linux route print # Windows 客户机 # 试探性连通性测试，分三跳 ping 223.5.5.5配合主机侧执行：
# 主机上看虚拟网卡状态 ipconfig /all判断逻辑很清晰：虚拟机里根本没有 IP 或者只有169.254.x.x，说明 DHCP 没拿到地址，问题大概率在主机侧的服务或模式设置；虚拟机有正常 IP、能 ping 通网关但出不去，说明模式没问题，卡在 NAT 或主机转发；能 ping 通 IP 但域名解析失败，那就是 DNS 的事，跟网络通不通是两码事。这三句话能砍掉八成的无效尝试。
注意：
ping通不通只能作为参考，有些网络环境会屏蔽 ICMP 回包，ping 不通不代表真的没网。最终判断还是要看能不能打开网页、能不能下载文件。
2. 桥接、NAT、仅主机：虚拟机到底被放在了网络的什么位置
要判断模式选得对不对，得先知道这三种模式到底干了什么。我习惯用一个小区宽带做类比：桥接相当于物业给你家单独拉了一根线，桥接模式下虚拟机会从你所在局域网的路由器直接要一个 IP，它和你的主机是"平起平坐"的两台设备。
2.1 桥接模式的适用条件与常见误用
桥接模式下，虚拟机会出现在和主机同一个网段里，同一局域网的其他设备能直接访问它，它也能访问别人。这种模式适合做需要被外部访问的实验，比如搭一个给同事测试的服务。
但它有几个硬性前提：你所在的局域网必须允许新设备接入。很多公司网络和校园网做了 MAC 地址绑定或接入认证，桥接出去的虚拟机会被直接拒之门外，表现就是"虚拟机拿不到 IP"或者"拿到 IP 但什么都访问不了"。这时候不管你重装几次系统都没用，要么找网络管理员登记，要么换成 NAT 模式。
另一个高频误用是主机同时插着有线和无线网卡。桥接模式默认的"自动桥接"会从所有物理网卡里挑一个，挑到无线网卡的时候，很多无线网卡驱动并不支持桥接所需的混杂模式，结果就是虚拟机完全没网。这个问题我在第四章会详细拆。
2.2 NAT模式为什么是日常首选
NAT 模式下，主机相当于一个路由器，虚拟机的所有对外流量都会经过主机做一次地址转换，以主机自己的身份发出去。对外界来说，只能看到你的主机，看不到虚拟机。
这个模式的好处很直接：只要主机能上网，虚拟机就一定能上网，不依赖局域网放行，也不受 MAC 绑定限制。日常学习、跑环境、装软件，我一律建议先用 NAT 把系统跑通，把网络无关的坑先排掉。
代价也有：外网设备无法直接访问虚拟机，需要额外做端口转发才能暴露服务。但对于绝大多数"我要装个 Linux 学命令"的场景，这不是问题。
2.3 仅主机模式和自定义VMnet的边界
仅主机模式顾名思义，虚拟机和主机之间能互相通信，但虚拟机没有通往外部的出口。这个模式适合做隔离实验，比如测试网络攻击行为、观察病毒样本行为，不希望它碰到外网。它的典型症状就是——主机能 ping 通虚拟机，虚拟机 ping 不通任何外部地址。如果你在排查网络问题时发现自己不小心把模式设成了仅主机，那"故障"的原因就找到了，改回 NAT 即可。
自定义 VMnet 则是把一个虚拟网段手动指派给虚拟机，通常配合多台虚拟机搭内网拓扑用。它容易出的问题是网段冲突：如果你把某个 VMnet 的子网设成了192.168.1.0/24，而你主机所在的真实局域网也是192.168.1.x，路由表就会出现歧义，表现是时通时断。改掉虚拟网段是唯一的解法。
3. NAT模式连不上外网：从VMnet8到主机服务逐项检查
选定 NAT 之后还是不通，问题基本落在主机侧。这个章节按从易到难的顺序给你一条排查链路。
3.1 先确认VMnet8虚拟网卡是否正常存在
在 Windows 主机的命令提示符里执行ipconfig /all，往下翻找名字带"VMware Network Adapter VMnet8"的适配器。正常状态下它应该有一个类似192.168.x.1的地址，并且这个网段要和虚拟网络编辑器里 NAT 模式的子网一致。
如果这条适配器完全不存在，说明虚拟网卡驱动没装好或在某次系统更新后被剥离了。最快的方式是重新运行虚拟化软件的安装包，选择"修复"或者"更改"，把虚拟网络驱动重新装一遍。装完之后最好重启一次主机，让驱动完整加载。
如果它存在但地址是169.254.x.x，说明它没能从自带的 DHCP 拿到地址——但注意，VMnet8 这个主机侧网卡通常是静态配置的，出现这种地址往往意味着服务没起来，接着往下看。
如果它带一个黄色感叹号，那就是驱动层面的问题了，见第六章。
3.2 主机服务被关掉：最隐蔽的一类故障
这是我最常遇到的坑，也是开头那位同事卡了一下午的原因。按Win + R输入services.msc，找到这两个服务：
| 服务名称 | 作用 | 缺失后的表现 |
|---|---|---|
| VMware DHCP Service | 给虚拟机的 NAT 网段分配 IP | 虚拟机拿不到地址，卡在169.254.x.x |
| VMware NAT Service | 做地址转换和转发 | 虚拟机有 IP、能 ping 通网关，但出不去外网 |
这两个服务的启动类型应该是"自动"。如果它们的状态是"已停止"，右键启动；如果启动后又自动停，去看事件查看器里的错误日志，通常是软件冲突或者安装不完整。
需要特别提醒的是：某些安全软件、系统优化工具在做"一键加速"或者"开机优化"时，会把这类看起来"不常用"的服务禁用掉。如果你装过这类工具，装完之后虚拟机突然没网，先来这里看一眼，比什么都快。
3.3 用虚拟网络编辑器恢复默认设置
如果上面两项都正常还是不通，打开虚拟网络编辑器（在软件的"编辑"菜单里，需要管理员权限）。先点"更改设置"拿到写权限，然后选中 NAT 模式那一行，点"还原默认设置"。
这个操作会把所有 VMnet 的网段、DHCP 范围、NAT 规则重置成出厂状态，能解决掉绝大多数"配置被改乱"的问题。代价是自己定义过的端口转发规则会丢，如果你之前配过，先截图记下来。
恢复完成后，主机侧会重新生成 VMnet1 和 VMnet8 网卡，虚拟机内重启一次网络服务或者干脆重启虚拟机，一般就通了。
提示：如果还原默认设置后 VMware 相关的服务没有自动重启，手动去服务列表里启动一次，别急着判定"还原没用"。
4. 桥接模式上不了网：网卡选错、无线限制与地址冲突
桥接模式的问题比 NAT 更"看环境"，因为它要跟你所在的真实网络打交道。下面三类是我遇到最多的。
4.1 自动桥接为什么会挑错网卡
现代主机的网络适配器数量远超想象：有线网卡、无线网卡、蓝牙网络适配器、各种虚拟网卡（包括其他虚拟化软件留下的）、某些外设自带的网络接口。桥接设置里的"自动"会把虚拟机桥接到"当前活动的物理网卡"上，但这个判断逻辑有时候会挑错。
结果是虚拟机看起来桥接出去了，但数据包走到了一个根本不通外网的接口上。解决办法很直接：在虚拟网络编辑器的"桥接到"选项里，把"自动"改成手动指定你那块真正在用的物理网卡。怎么确认是哪一块？在主机上执行ipconfig /all，看哪个适配器有正常的网关和能上网的 IP，那就是它。
同时建议把"自动"换成手动之后，顺手把那些用不到的适配器在桥接列表里排除掉，避免以后环境变化时又被挑错。
4.2 无线网卡桥接失败的原因和替代思路
无线网卡桥接是个老大难。桥接在技术上要求网卡能接收所有帧，而很多无线网卡的驱动和固件并不开放这个能力，尤其是消费级笔记本上的集成无线网卡。表现就是：桥接设置看起来正常，虚拟机却一张包都发不出去。
遇到这种情况，我给你三个可操作的替代方案：
- 改用 NAT。这是最省事的，只要主机能上网，虚拟机就能上网，完全绕开无线网卡的限制。
- 给主机插一根网线，用有线网卡做桥接。有线网卡基本都支持桥接所需的模式。
- 用主机做端口转发，在 NAT 模式下把虚拟机的服务端口映射出来，让局域网的其他设备能访问。虽然不如桥接直接，但功能上够用。
我自己的笔记本常年用方案一，需要给外部访问的时候就切到方案三，几年下来没出过问题。
4.3 局域网拒绝接入的几种表现
桥接之后虚拟机拿不到 IP，还有一类原因是所在网络做了限制。校园网和不少公司网络会做接入认证或者 MAC 白名单，虚拟机的虚拟 MAC 不在名单里，直接被交换机丢弃。还有一种情况是 DHCP 地址池已经满了，虚拟机的请求得不到响应。
这两种情况的区分方法是：把虚拟机的网卡模式改成 NAT，如果能上网，那基本可以确定是局域网侧的限制，而不是虚拟机自身的问题。确认之后，要么去申请登记这台设备的 MAC，要么就长期使用 NAT。
另外提醒一句：不要随便给桥接的虚拟机填一个静态 IP。如果你填的地址正好和局域网里某台设备重复，会引发 IP 冲突，轻则自己不通，重则影响别人的正常使用。需要静态地址的话，先在网关的 DHCP 分配记录里找一个不在池子里的地址。
5. 主机能上网、虚拟机IP也正常，却打不开网页
这一类故障特别有迷惑性：ping 223.5.5.5通，ping www.example.com不通，浏览器打不开任何页面。这不是网络不通，而是域名解析出了问题。
5.1 分清"网络不通"和"解析失败"
判断方法就一句话：直接用 IP 去连，能通就是 DNS 的问题。
ping 223.5.5.5 # 通，说明三层网络是好的 ping www.baidu.com # 不通，说明域名解析失败 cat /etc/resolv.conf # 看 DNS 配置是否为空或指向了不存在的地址DNS 配置为空或者指向一个已经失效的地址，是这个问题的绝对主因。常见于克隆出来的虚拟机、手动配过静态 IP 之后忘记填 DNS、以及 DHCP 下发的 DNS 信息不完整这几种情况。
5.2 Linux客户机里DNS的持久化写法
Linux 这边有个坑：直接编辑/etc/resolv.conf很多时候是没用的，因为 NetworkManager 或者 netplan 会在下次网络事件时把它覆盖回去。正确的做法是从上层的网络配置入手。
对于使用 netplan 的新版发行版，编辑对应的配置文件（通常在/etc/netplan/下）：
network: version: 2 ethernets: ens33: dhcp4: true dhcp4-overrides: use-dns: true nameservers: addresses: [223.5.5.5, 114.114.114.114]写完之后执行：
sudo netplan apply对于用 NetworkManager 管理的桌面版，可以用命令行改：
nmcli connection modify "有线连接 1" ipv4.dns "223.5.5.5 114.114.114.114" nmcli connection up "有线连接 1"对于传统的 CentOS 系，编辑/etc/sysconfig/network-scripts/ifcfg-ens33，加上DNS1=223.5.5.5，然后重启网络服务。
5.3 Windows客户机的网关和DNS检查
Windows 虚拟机里，在"网络和共享中心"打开适配器属性，确认 IPv4 设置为自动获取，或者至少要保证"默认网关"和"首选 DNS 服务器"两栏有正确的值。常见错误是手动配 IP 时只填了地址和掩码，网关和 DNS 空着——这个配置下虚拟机能和同网段通信，但出不了门，也解析不了域名。
如果确认配置没问题还是解析失败，试试清一下缓存：
ipconfig /flushdns ipconfig /release ipconfig /renew提示：如果
ipconfig /renew报错说无法联系 DHCP 服务器，那就回到第三章，检查主机侧的 DHCP 服务。
6. 网卡"消失"了：适配器缺失、VMnet感叹号与虚拟化功能抢占
有一类故障不是"连不上网"，而是"压根看不见网卡"。这种问题给人的心理冲击更大，因为它看起来像虚拟机坏了。
6.1 虚拟机里看不到网卡的三类情形
第一类是虚拟机配置里根本没加网络适配器。新建虚拟机时如果选了"不添加网络连接"，后面进系统当然看不到网卡。解决办法是在虚拟机关机状态下，打开虚拟机设置，添加一个网络适配器，选好模式再开机。
第二类是网卡在系统里被禁用了。Linux 下用ip link能看到设备但状态是 DOWN，用ip link set ens33 up打开；Windows 下在"网络连接"界面里看适配器是不是灰的，右键启用。
第三类是驱动没有识别。这种在 Linux 里比较少见，Windows 客户机上偶尔会遇到，尤其在换过虚拟硬件版本之后。在设备管理器里看"其他设备"下面有没有带问号的以太网控制器，有的话重新安装一下虚拟机工具即可。
6.2 主机侧VMnet带感叹号怎么处理
主机侧ipconfig /all里看到 VMnet1 或 VMnet8 带感叹号，或者干脆不出现在列表里，说明虚拟网卡驱动出了问题。我常用的处理顺序是：
- 在设备管理器里找到对应网卡，右键卸载设备，勾选"删除此设备的驱动程序软件"。
- 打开虚拟网络编辑器，点"还原默认设置"，让软件重新安装虚拟网卡。
- 如果还不行，用管理员权限运行虚拟化软件的安装包，选择修复安装。
- 重启主机。
这套流程走下来，九成以上的虚拟网卡异常都能解决。走不完的那一成，通常是杀毒软件的驱动拦截或者系统组件损坏，那就需要单独处理了。
6.3 其他虚拟化功能对网络的抢占
这个坑比较隐蔽，也很符合"刚装完某个东西虚拟机就没网了"的时间线。Windows 上启用 Hyper-V、Windows 沙盒、部分安卓模拟器所需的虚拟化平台之后，系统的网络栈会多出一层虚拟交换机。这层东西会和虚拟化软件自带的桥接机制打架，典型表现是NAT 还行，桥接彻底不通，或者虚拟网卡直接无法创建。
判断方法很直接：把 Hyper-V 关掉（在"启用或关闭 Windows 功能"里取消勾选，重启），如果虚拟机网络立刻恢复，那原因就确认了。如果确实需要同时使用，就长期用 NAT 模式，绕开桥接这条路径。
7. 克隆、快照与MAC地址：那些"昨天还好今天不通"的原因
有一类故障时间线特别诡异：昨天一切正常，今天开机就不通了，中间你什么都没改。这种情况我一般先怀疑下面三件事。
7.1 克隆之后MAC冲突与地址租约打架
虚拟机克隆时如果保留了原有的 MAC 地址，主机侧会出现两台设备用同一个 MAC 的情况。DHCP 服务会把同一个地址分给两台机器，结果两边都时通时断，或者干脆都拿不到地址。
解决办法是克隆完成后，在虚拟机设置的网络适配器里点一次"生成新的 MAC 地址"，然后在客户机里重新获取一次 IP。这一步我养成了习惯动作，克隆完先做，能省掉后面很多莫名其妙的排查。
7.2 快照回滚把网络配置一起带回去了
快照会保存虚拟机的完整磁盘状态，包括当时的网络配置。如果你打过快照之后改过模式或网段，回滚快照会把这些改动一起撤销，于是虚拟机又回到了那个"没网"的旧状态。
发现这种情况时，别急着重新配，先检查虚拟网络管理器里的网段和快照时间点是否对得上。对不上就切回正确的模式，问题自然消失。
7.3 Linux下onboot=no和网络服务未托管的经典坑
传统 CentOS 系发行版安装完之后默认网卡是不启用的，配置文件里ONBOOT=no，表现就是系统装好了却永远没网。
# 编辑 /etc/sysconfig/network-scripts/ifcfg-ens33 BOOTPROTO=dhcp ONBOOT=yes改完执行systemctl restart network（新版用nmcli）。
另一个坑是 NetworkManager 把某块网卡标记为"未托管"，这种情况在手动改过配置文件的机器上常见。执行nmcli device status，如果看到网卡状态是unmanaged，把对应配置文件里的NM_CONTROLLED=yes加上，再重启服务即可。
8. 一套可复用的排查顺序
前面分了八类情形讲，实际处理的时候我更希望有一套固定的动作顺序，这样不会遗漏。下面这套流程我用了很多年，从主机侧往虚拟机侧推进，一般十分钟内能锁定问题。
8.1 主机侧先看的六件事
- 主机本身能不能上网，先排除网络出口的问题。
ipconfig /all里 VMnet 网卡是否存在、地址是否合理、有没有感叹号。- 服务列表里 DHCP 和 NAT 两个服务是否在运行。
- 虚拟网络编辑器里的网段是否和主机真实网段冲突。
- 桥接模式下是否错误地桥接到了无线网卡或其他非活动接口。
- 最近是否启用了其他虚拟化功能，或安装过安全软件、优化工具。
8.2 虚拟机内再看的五件事
- 网卡是否存在且处于启用状态。
- 是否拿到了正常网段的 IP，还是
169.254.x.x。 - 默认网关是否正确。
- DNS 是否配置且可用。
ONBOOT之类的开机自启选项是否打开。
下面这张表是我总结的"现象到原因"快速映射，实际排查时可以照着对：
| 现象 | 最可能的原因 | 优先动作 |
|---|---|---|
无 IP，仅169.254.x.x | DHCP 服务未运行或模式错误 | 查主机服务、确认 NAT 模式 |
| 有 IP，ping 不通网关 | 网段冲突或桥接到了错误网卡 | 检查虚拟网段、改用手动桥接 |
| ping 通 IP，域名不通 | DNS 未配置或被覆盖 | 修改 netplan 或 NetworkManager 配置 |
| 网卡在系统里看不见 | 适配器未添加或被禁用 | 添加/启用网卡 |
| 克隆后不通 | MAC 冲突 | 重新生成 MAC 并重新获取 IP |
| 启用 Hyper-V 后桥接失效 | 虚拟化功能抢占 | 关闭冲突功能或改用 NAT |
9. 我踩过的几个坑和长期习惯
说几个实打实踩过的教训。有一次我为了图省事，给桥接的虚拟机直接填了静态 IP，正好撞上局域网里一台打印机，结果整层楼的人都打印不了，被同事念了半天。从那以后我给自己定了规矩：桥接模式下能自动获取就自动获取，非要静态也得先去路由器后台确认地址空闲。
还有一次是虚拟机网络时通时断，排查了两个小时，最后发现主机上装的一个网络加速类工具在接管流量，它会过滤掉虚拟网卡发出的包。卸载之后立刻恢复。这类工具装的时候都会说"优化网络体验"，但对虚拟机来说就是隐形的墙，如果你遇到主机能上网、虚拟机就是不行而且查不出原因，可以往这个方向想想。
长期习惯方面，我现在给每台虚拟机建好之后都会做三件事：一是固定用 NAT 模式跑通基础环境，网络相关的坑能绕掉一大半；二是把虚拟网络编辑器里的网段截图存下来，将来多了几台虚拟机也不会打架；三是克隆完第一件事就是重新生成 MAC，再重新获取 IP。
我还习惯在装完系统之后先跑一遍连通性三步验证——ping 网关、ping 一个外部 IP、ping 一个域名。三步都通，说明三层网络、NAT 转发、DNS 全都正常，后面装什么软件、改什么配置心里都有底。如果哪一步不通，也能立刻知道是哪个环节出了问题，而不是等到装完一堆东西才发现网络不对劲，那时候排查成本就高多了。
