虚拟机区域网无法上网，九成以上是网络模式选错、网卡驱动异常或DNS解析失败造成的，沿着宿主机网络、虚拟网卡、虚拟机内部配置这条链路逐层排查，几分钟就能定位问题。很多用户遇到虚拟机断网第一反应是重装系统，实际上多数情况下问题出在VMware或VirtualBox的网络服务没启动，又或者虚拟机的网卡被重置成了不匹配的模式，下文按照从物理层到协议层的顺序,给出可直接照做的排查流程。
第一道关卡：宿主机网络与虚拟机网络服务状态检查
区域网场景里，虚拟机依赖宿主机的物理网络出口，宿主机断网、防火墙拦截或VMware相关服务停止，都会让虚拟机表现成”完全没网”的状态，这一步是排查的起点,也是三个步骤中的高发故障区。
确认宿主机物理网络本身在线
用有线还是无线不重要，关键是宿主机自己能否正常打开网页，常见误区是用户只盯着虚拟机看，忽视了宿主机其实已经掉线,建议先运行一条命令验证：
ping 223.5.5.5 -t
这是阿里公共DNS地址，能通说明网络链路没问题，如果这块不通，检查物理网卡是否被禁用、网线或Wi-Fi是否断开，行业共识认为，虚拟机的网络故障里约有一半是宿主机网络环境变了，比如办公区从有线切到了访客Wi-Fi,导致原网段失效。
查看VMware或VirtualBox的后台服务是否存活
这部分经常被忽略但相当关键，VMware依赖几个Windows服务来转发虚拟网络流量，如果服务没启动，虚拟网卡即使显示已连接也是”假在线”。
- 按下
Win + R输入services.msc打开服务管理器 - 在列表中找到以下服务，状态应为”正在运行”，启动类型应为”自动”
VMware NAT ServiceVMware DHCP ServiceVMware Authorization Service
VirtualBox用户则检查 VirtualBox NDIS6 Bridged Networking Driver 和 Oracle VM VirtualBox Host-Only Network 是否存在于网络适配器列表中，如果服务缺失，打开VMware Workstation菜单栏的”编辑”→”虚拟网络编辑器”，点击左下角的”更改设置”按钮,系统会提示修复并重建网络模块。
检查虚拟网卡在Windows中是否被禁用
VMware安装时会创建两块虚拟网卡：VMnet1（仅主机模式）和VMnet8（NAT模式），某些优化软件或系统更新可能把它们禁用，操作路径为：控制面板→网络和共享中心→更改适配器设置，查看 VMware Virtual Ethernet Adapter for VMnet8 是否处于灰色状态，右键启用即可，不需要额外配置IP,默认自动获取就够用了。
第二道关卡：虚拟机网络模式与虚拟网卡配置核对
本地连接无法上网的场景里，网络模式选错是第二大主因，不同的上网需求匹配不通的模式，选错了要么完全不通,要么只通外网不通内网。
三种网络模式的适用场景对比
构建虚拟化测试环境时,把模式搞清楚能省掉大量无效排查时间。
| 模式 | 通信范围 | IP获取方式 | 区域网适用性 |
|---|---|---|---|
| 桥接模式 | 与宿主机完全平等，可访问局域网所有设备 | 由上级路由器DHCP分配 | 最适合，虚拟机像独立主机 |
| NAT模式 | 可访问外网和宿主机，区域网内其他设备默认无法访问虚拟机 | 由VMware虚拟DHCP分配 | 可上外网，但局域网互访受限 |
| 仅主机模式 | 只能与宿主机通信 | 由VMware虚拟DHCP分配 | 无法上外网，仅适合隔离测试 |
如果你要搭建的是区域网内的文件共享服务器或Web测试站，桥接模式是首选，如果只是临时跑个脚本抓数据、验证软件环境,NAT模式已够用。
桥接模式连接不上的典型原因
选桥接模式后仍然无法上网，多数情况是虚拟网卡没绑定到正确的物理网卡上，VMware的桥接模式默认是”自动”选择物理网卡，在双网卡机器（有线+无线）上容易选错，修改路径为：虚拟网络编辑器→选择 VMnet0→”桥接到”下拉菜单里手动指定当前正在联网的那块网卡，Realtek PCIe GbE Family Controller 对应有线，Intel Wi-Fi 6 AX201 对应无线，改完确认后,虚拟机里的IP要重新获取一次：
# Windows虚拟机 ipconfig /release ipconfig /renew
在桥接模式下，虚拟机需要从上级路由器拿到同网段的IP地址，如果一直拿不到，检查路由器是否开了DHCP，或是否启用了MAC地址过滤，手动填入静态IP也是可行的方案,但要确保网关和DNS与宿主机保持一致。
虚拟机网卡驱动重置技巧
在设备管理器里把虚拟网卡禁用再启用，比重启虚拟机要快得多，有些情况下虚拟机内部的网卡驱动会因休眠或快照回滚而丢失绑定关系，重装驱动即可，在虚拟机内打开设备管理器→网络适配器，找到对应的虚拟网卡（VMware通常显示为 VMware VMXNET3 或 Intel PRO/1000 MT），右键卸载设备，然后点击”扫描检测硬件改动”重新安装，重启后IP设置会被清空,需要重新配置静态IP或确认DHCP已开。
第三道关卡：虚拟机内部IP与DNS深度排查
前面两层都无恙但依旧上不了网，问题基本集中在虚拟机操作系统自身的协议栈配置里，本地连接显示”已连接”却打不开网页，或ping网关能通、ping域名不通,都指向IP地址错误或DNS解析异常。
检查IP地址、子网掩码和默认网关的三元组匹配
在虚拟机命令行里执行：
ipconfig /all
重点看三样东西：
- IPv4地址是否和宿主机（桥接模式）或VMnet8（NAT模式）处于同一个子网
- 子网掩码是否为
255.255.0 - 默认网关是否填写正确，NAT模式下应为
168.x.2（这个x取决于VMnet8的网段,可在VMware网络编辑器里查看）
现实中相当一部分情况是用户在区域网里手动配置了静态IP，但网关输错了一个数字，导致数据包发不出去，DNS配置的排查绕不开 nslookup 命令,它专门用来验证域名解析是否工作正常。
DNS地址配置方法解析
DNS配置异常可能让人误以为网线断了，亲测一个典型的例子：区域网内架设了私有DNS服务器（如Windows Server的DNS角色），但虚拟机的DNS地址还写着 114.114.114，解析不了内部域名，此时把虚拟机DNS改成内网DNS服务器的IP,或者同时填内网IP和公共DNS：
# 临时生效 netsh interface ip set dns "以太网" static 192.168.1.2 # 追加备用DNS netsh interface ip add dns "以太网" 223.5.5.5 index=2
DNS缓存污染与刷新方法
如果修改DNS后仍然异常，可能是系统缓存了旧的解析结果,Windows虚拟机里执行：
ipconfig /flushdns
Linux虚拟机使用 systemd-resolve 的话：
sudo resolvectl flush-caches
这里多提到一种较少见但极迷惑的情况：虚拟机的hosts文件被安全软件或被调试工具改过，路径在 C:WindowsSystem32driversetchosts，用记事本打开看是否有残留的异常映射条目，0.0.1 www.baidu.com 这种,有的话直接删掉。
更底层的连通性测试定位断点
排错不要只靠”感觉”，用命令把故障点逼出来，按顺序跑下面三条命令，哪一条报错,问题就在哪一段链路：
ping 192.168.1.1 -t
先ping网关,通说明虚拟机到路由器的二层链路正常。
ping 223.5.5.5
再ping公网IP,通说明路由转发和NAT正常。
ping www.baidu.com
最后ping域名，通说明DNS解析正常，如果这一步超时而上一步正常,直接跳到上面的DNS配置环节。
防火墙与安全软件干扰排查
虚拟机系统里自带的防火墙或第三方安全软件，时常把虚拟网卡标记为”公用网络”并拦掉入站和出站流量，网络模式、IP配置都正确，但虚拟机就是上不了网,多想想这个方向。
- 临时关闭Windows防火墙验证：控制面板→Windows Defender防火墙→关闭（测试完后记得开启）
- 检查是否有安装杀毒软件自带的网络防火墙模块，比如360的”流量防火墙”或腾讯管家的”网络防护”
- VMware Tools安装不完整也会导致虚拟网卡的驱动级通信异常，重装一次VMware Tools能解决相当一部分怪问题
疑似防火墙问题，也可以直接在当前网络配置文件里把网络位置改成”专用网络”,减少针对公用网络的默认限制。
虚拟机区域网访问外部设备失败的特殊场景
三个主层面排查之后，仍有一个容易栽进去的场景：虚拟机单独能上外网，但访问区域网内其他电脑的共享文件夹或Web页面不通，这类问题大多是网段隔离造成的，NAT模式下宿主机之外的设备根本看不到虚拟机，所以需要做的不是继续调DNS，而是切换为桥接模式，并确认虚拟机IP与目标设备同网段，业界对此有倾向性的建议：凡是需要局域网互访的场景，一律建议使用桥接模式部署虚拟机。
双虚拟机互通的额外注意事项
如果你开了两台虚拟机（比如一台Windows测试机搭配一台Linux服务器），发现互相ping不通，但各自都能外网访问，优先检查两台虚拟机的网络模式是否一致，一台NAT一台桥接的话，它们可能处于完全不同的子网里，把两者调整为同一模式，并确保IP在同一网段，比如都是 168.8.x,即可解决。
常见问题解答
虚拟机显示”未识别的网络”或”无Internet访问”，但宿主机正常，是什么原因？
这个现象往往指向虚拟机的网卡模式仍停留在旧的NAT配置上，先执行 ipconfig /all 确认虚拟网卡是否获取到了 168.x.x 网段地址，若地址是 254.x.x（APIPA自动私有地址），说明网卡没有从DHCP服务器拿到有效IP，步骤：在VMware虚拟网络编辑器里删掉当前VMnet8网络并重新添加，系统会通过默认配置修复DHCP服务，如果是VirtualBox用户，尝试在全局设定里重置 Host-Only 网络适配器,该场景下区域网内多个虚拟机无法上网的问题也可以一并解决。
为什么桥接模式下虚拟机可以ping通网关但无法访问互联网？
网关可达说明二层链路和路由第一步没问题，访问不了互联网大概率是物理链路的上游做了MAC地址绑定或IP白名单认证（常见于公司网络、校园网、酒店Wi-Fi），尤其区域网内的认证式上网环境，虚拟机的新MAC地址没经过登记，直接被路由器拒绝，这种场景下把网络模式改为NAT，让虚拟机的流量通过宿主机转发出去，能避开上游认证的检查，顺带提示：若必须用桥接，可在VMware的虚拟机设置里把”MAC地址”选项点击”高级”,记录当前MAC并在路由器后台手动绑定。
虚拟机DNS配置明明正确但nslookup查询超时，还可能漏掉哪里？
需要确认虚拟机系统的时间是否同步正确，DNS协议在安全扩展（DNSSEC）场景下对时间戳敏感，系统时间偏差过大会导致解析被丢弃，执行 w32tm /resync 重新同步时间后重试，另外查看虚拟机内是否有多个网卡共存，比如同时启用了仅主机模式的VMnet1和NAT模式的VMnet8，路由表里可能会优先走不通的那张网卡，在命令行运行 route print 查看 0.0.0 的默认路由是否指向了活动网卡对应网关,必要时禁用闲置虚拟网卡来消除路由竞争。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/626156.html
