虚拟机装好之后,很多人第一件事就是打开浏览器试一下网络,结果页面转圈圈转到底也打不开。这个场景太常见了:宿主机明明刷视频刷得好好的,虚拟机里却像与世隔绝一样,ping 不通网关、打不开网页、连不上软件源,甚至连宿主机都访问不到虚拟机里跑的服务。虚拟机连不上网这个问题,排查起来其实有章可循——它从来不是单一原因造成的,而是虚拟机内部配置、虚拟网卡、虚拟化平台服务、宿主机物理网络这条链路上某一环断了。这篇内容就按这条链路,把每种断法的现象、判断依据和修复手段拆开讲清楚,不管你是用 VMware 还是 VirtualBox,装的是 Ubuntu、Kali 还是 Windows 10,都能对着找到自己那一步。1. 先把虚拟机联网的底层逻辑捋直,排查才有方向新手最容易犯的错,就是一遇到没网就重启虚拟机、重装系统,折腾半天问题还在。真正高效的做法是先搞清楚:虚拟机的流量到底是怎么走出去的。它并不是自己有网卡,而是虚拟化软件在宿主机上虚拟出若干块网卡和若干项后台服务,拼出一条虚拟链路,再借宿主机的物理网卡出门。链路里任何一环缺失,表现都是没网,但修复手法完全不同。所以排查的第一原则是分层,而不是乱试。我一般把它分成四层来看:虚拟机内部的网卡与 IP 状态、虚拟机软件生成的虚拟网卡与后台服务、宿主机的物理网络与 DNS、以及目标网络本身的策略限制。下面这个问题从上层往下逐层确认,基本上十分钟以内就能定位到病灶。1.1 三种网络模式分别解决了什么问题VMware Workstation 默认给你三种模式,理解它们的分工,后面所有排查都会变得顺理成章。桥接模式(Bridged)是最直观的一种。虚拟化软件把虚拟机的网卡桥到宿主机的物理网卡上,让虚拟机看起来像局域网里另一台独立的电脑。它会直接向路由器要 IP,拿到的地址和宿主机同一网段。这种模式的好处是双向透明:虚拟机可以被局域网其他设备访问,宿主机访问虚拟机里的网站也不用做任何额外配置,直接填虚拟机 IP 就行。代价是它依赖宿主机的物理网卡正常工作,而且当宿主机用的是无线网卡时,桥接有时候需要手动指定桥接到哪一块网卡,不指定就可能在多块网卡之间乱猜,拿不到 IP。NAT 模式是装机后默认选中的模式,也是最省心的一种。虚拟机连的是 VMware 虚拟出来的 VMnet8 这块网卡,由 VMware 的 NAT 服务帮它做地址转换,再把流量交给宿主机送出去。虚拟机拿到的通常是 192.168.x.0/24 这个私有网段里的地址,网关指向这块虚拟网卡的地址。它的优点是虚拟机不需要在局域网里有独立身份,换 Wi-Fi、换办公网络都不用改配置;缺点是外部设备主动访问虚拟机比较麻烦,必须做端口转发。仅主机模式(Host-Only)连的是 VMnet1,流量只在本机和虚拟机之间走,出不了宿主机。它的典型用途是搭隔离的测试环境,比如要跑一些有风险的服务、做网络安全实验,不希望它碰到外网。很多人抱怨虚拟机没网,最后发现就是模式选成了仅主机,这种属于自己给自己挖的坑。提示:如果你的诉求是宿主机能访问虚拟机里的网站,同时虚拟机也能上外网,桥接模式是最省事的解;如果宿主机经常切换网络环境,或者你所在的公司网络禁止陌生设备接入,NAT 加端口转发是更合适的选择。1.2 一张表看懂三种模式的连通性差异光看文字描述容易记混,我把常见问题做成了一张对照表,装机或者排障的时候可以直接对着看。对比项桥接模式NAT 模式仅主机模式使用的虚拟网卡桥接到物理网卡VMnet8VMnet1虚拟机 IP 来源局域网路由器 DHCPVMware DHCP 服务VMware DHCP 服务能否访问外网能能不能宿主机能否直接访问虚拟机能需端口转发能局域网其他设备能否访问虚拟机能不能不能换 Wi-Fi 后是否需要改配置通常需要重新获取 IP一般不用不用典型适用场景需要被访问的服务、模拟真实主机日常开发、上网查资料隔离实验、安全测试这张表里最值得记住的是最后两行。很多昨天还能上网今天就不行了的情况,本质是宿主机换了网络(比如从公司网换到家里的 Wi-Fi),桥接模式下的虚拟机拿不到原来网段的 IP,自然就断了。而 NAT 模式因为走的是内部虚拟网段,受到的影响要小得多,这也是我一般建议先调通 NAT、再去折腾桥接的原因。2. 分层排查:从最容易忽略的地方一层层往下走有了上面的模型,排查就不再是碰运气了。我通常固定按三层往下走,顺序是先看虚拟机内部,再看虚拟化平台,最后看宿主机。这个顺序不能反,因为如果你先去动宿主机的网络设置,很可能把本来正常的部分弄乱,最后连问题在哪都找不到。2.1 第一层:先确认虚拟机内部的网卡与 IP 状态进到虚拟机里,第一步是看网卡有没有被识别、有没有拿到 IP。Windows 虚拟机打开命令提示符跑ipconfig /all,Linux 虚拟机跑ip a和ip route。重点看三个信息:网卡是否处于 UP 状态、是否拿到了一个正常网段的 IPv4 地址、默认网关是否存在。有一种非常典型的情况是,地址显示为169.254.x.x开头。这个网段是系统在要不到 DHCP 地址时自己给自己分配的临时地址,只要看到它,基本可以断定 DHCP 环节出了问题——要么是虚拟化平台的 DHCP 服务没启动,要么是桥接模式桥错了网卡,要么是宿主机的网络本身就不通畅。这个判断非常省时间,不用再一点点试。# Linux 下快速确认网卡、IP 与网关 ip a ip route cat /etc/resolv.conf另外还有一种容易被忽略的情况:虚拟机不是没网,而是网卡被系统关掉了。Linux 下可能是NetworkManager里连接处于未激活状态,Windows 下可能是网络适配器被禁用,或者防火墙策略把网卡标成了公用网络。这两种都表现为看着一切正常但就是不通,值得先确认一遍。还有一个专门针对克隆虚拟机的坑。如果你是从一台已经配好的虚拟机克隆出来的,新机器的 MAC 地址变了,但系统里 udev 或 netplan 配置文件还记着旧网卡名字,就会导致网卡不被激活,ip a里只看到lo看不到业务网卡。这种情况要改/etc/netplan/下的配置文件,把网卡名对上实际的接口名,或者直接删掉机器的网络设备绑定记录让它重新识别。# Ubuntu 下查看并修正 netplan 配置 ls /etc/netplan/ sudo nano /etc/netplan/00-installer-config.yaml sudo netplan applynetplan 的配置文件内容长这样,网卡名一定要和ip a里显示的一致:network: version: 2 renderer: networkd ethernets: ens33: dhcp4: true nameservers: addresses: [192.168.1.1]2.2 第二层:检查虚拟网卡和 VMware 后台服务如果虚拟机内部一切正常,那就把注意力转回宿主机和虚拟化平台。Windows 上的操作路径是:先看网络连接里有没有VMware Network Adapter VMnet1和VMnet8这两块虚拟网卡,再看它们的状态。VMnet8上带感叹号,是一个非常高频的故障,表现得非常典型——NAT 模式下虚拟机完全没网,虚拟网卡旁边挂着黄色三角。造成它的原因通常是虚拟网卡驱动没装上或者装坏了,常见于系统大版本更新之后,或者装过其他虚拟化软件(比如 Hyper-V、WSL2、Docker Desktop)之后网络栈被抢占。处理思路分三步走。先试最轻的:右键禁用再启用这块网卡,再看状态。不行的话,在设备管理器里找到对应的虚拟网卡,卸载设备并勾选删除驱动,然后在 VMware 的虚拟网络编辑器里点还原默认设置,让它重新安装虚拟网卡,这一步能解决绝大多数感叹号问题。最后一步是重新运行 VMware 安装程序选择修复安装,把虚拟网络组件补齐。说到虚拟网络编辑器,这里有个常见疑惑:有些人装完 VMware 发现根本没有这个菜单项,或者点开提示需要管理员权限。前者的原因通常是安装时没勾选,或者被精简安装包砍掉了组件,解决办法是用官方完整安装包做一次修复安装;后者的处理很简单,用管理员身份运行 VMware Workstation 即可,因为修改虚拟网络配置本身就需要较高权限。宿主机上还有一组服务必须处于运行状态,少一个都不行:服务名称作用停掉的后果VMware DHCP Service给 VMnet 网段分配地址虚拟机拿不到 IP,出现 169.254 地址VMware NAT Service为 NAT 模式做地址转换NAT 模式完全断网,虚拟网卡可能带感叹号VMware Authorization Service权限校验无法启动虚拟机、无法修改网络配置VMware USB Arbitration ServiceUSB 设备转发与网络无关,但影响外设使用检查方法是在服务管理里把这几项找出来,确认启动类型是自动、状态是正在运行;如果是手动并且已经停止,启动它,再把启动类型改成自动,避免下次重启后又出问题。2.3 第三层:回到宿主机本身的网络前面两层都没问题,那就该怀疑虚拟化平台之外了。这里的关键认知是:虚拟机自己不会凭空变出网络,它所有流量最终都要过宿主机这一关,宿主机上不了网,虚拟机必然也上不了,顶多是与宿主机之间的内部通信正常。这一步要干的活其实很朴素:确认宿主机能不能正常打开网页、DNS 是否正常解析、有没有连上某个需要额外认证的网络。有些公司网络或者公共 Wi-Fi 需要先弹页面做认证,这种环境下虚拟机往往会被卡在门外。还有宿主机上装的某些安全软件、网络管理工具,会把虚拟网卡的流量一并纳入管控,导致虚拟机能通内网却通不了外网。遇到这种情况,把虚拟网卡加入信任列表或者临时停掉这类软件测试一下,问题往往就浮出水面了。另外要提一句,宿主机的防火墙也需要留意,因为它影响的是反向访问——虚拟机访问宿主机一般没问题,但宿主机要访问虚拟机里的 Web 服务、数据库端口时,可能被宿主机的防火墙规则挡住。这跟上面几种完全没网不是一回事,排查时要区分开。3. 四类高频故障的完整修复流程理论讲完了,接下来上实战。下面这四种故障基本覆盖了九成以上的虚拟机连不上网,我把现象、原因和具体操作都写清楚,你可以直接照着自己遇到的那一类操作。3.1 场景一:NAT 模式下完全没网,VMnet8 带感叹号现象描述:虚拟机里怎么都上不了网,ipconfig或者ip a显示拿到了 192.168.x.x 的地址甚至没有地址,回到宿主机一看,VMnet8 网卡挂着黄色感叹号,或者那几项 VMware 服务处于停止状态。这个场景的处理顺序是先修网卡,再看服务,最后重置网络配置。具体操作如下。先处理虚拟网卡驱动。打开设备管理器,展开网络适配器,找到名字里带 VMware 的两块虚拟网卡,右键卸载,勾选删除驱动程序软件。然后在开始菜单里找到虚拟网络编辑器(用管理员身份运行),点右下角的还原默认设置。程序会重新安装虚拟网卡并把 VMnet1、VMnet8 的配置恢复到初始状态,重启一下宿主机再看这两块网卡是否恢复正常。注意:还原默认设置会把之前手工配的端口转发、自定义网段一并清掉,如果你之前为 NAT 模式配过端口映射,记得先截图记下来,重置后再补回去。再看服务。确认 VMware DHCP Service 和 VMware NAT Service 处于正在运行、启动类型为自动。有些精简版系统或优化软件会把这两项设成禁用,需要手动改回来。改完之后,在虚拟机里执行一次地址续租,Linux 下可以用dhclient,Windows 下用ipconfig /release加ipconfig /renew。:: Windows 虚拟机内重新获取地址并刷新解析缓存 ipconfig /release ipconfig /renew ipconfig /flushdns如果以上都做完还是不通,可以在虚拟机里手工指定一套参数做验证:NAT 模式下常见网段是 192.168.x.0/24,网关一般是该网段的.2地址,把 IP 手工设成同网段的其他地址、DNS 设为公共 DNS,看能不能通。如果手工配置能通、自动获取不通,问题就锁定在 DHCP 服务这一侧,沿着这条线细查就行。3.2 场景二:桥接模式拿不到 IP,只剩 169.254 地址现象描述:模式是桥接,但虚拟机里地址是 169.254 开头,网关那一栏空的,ping 谁都不通。宿主机本身的网络是完全正常的。这类问题的根源几乎都在桥接到了哪块网卡上。当宿主机有多块网卡(有线加无线、虚拟网卡、蓝牙网络等)时,桥接如果没有明确指定目标,虚拟机可能桥到了某块根本没连接的网卡上,自然拿不到地址。第一步,打开虚拟网络编辑器的桥接设置,把自动改成手动指定,明确选中当前正在使用的物理网卡。如果你用的是笔记本无线网卡,特别注意要选对无线网卡而不是有线的,虽然无线网卡做桥接有时需要额外的驱动支持,但新版软件已经能处理得比较好。第二步,选择桥接的目标网卡后,重启虚拟机网络或在虚拟机内重新触发 DHCP。Linux 下可以先把网卡断开再启用:sudo nmcli networking off sudo nmcli networking on ip a第三步,确认局域网的路由器没有开启 MAC 地址白名单或者设备数量限制。有些公司网络对陌生设备比较敏感,桥接过去的虚拟机在路由器看来就是一台新设备,拿不到地址很正常,这种情况要么找网络管理员登记,要么直接改用 NAT 模式,先在本地把开发环境跑起来。这里插一句,主机上用无线网络时,如果桥接一直不稳定,不用强求,换成 NAT 模式再给需要的端口配一条转发规则,实际开发体验几乎没有差别。3.3 场景三:能 ping 通 IP 但打不开网页,典型的 DNS 问题现象描述:虚拟机里ping 8.8.8.8或者 ping 网关都有回应,说明链路是通的,但一 ping 域名比如ping baidu.com就报无法解析,浏览器打开任何网站都在那转圈。这类故障非常经典,原因只有一个——DNS 配置有问题。先看当前用的是什么 DNS:cat /etc/resolv.conf nslookup baidu.com如果resolv.conf里是空的、指向了 127.0.0.53 这样的本地转发地址但转发链断了,或者指向了一个根本不通的内网 DNS,那问题就找到了。Ubuntu 桌面版由 NetworkManager 接管解析,服务器版走 systemd-resolved 或 netplan,直接改resolv.conf大概率会被覆盖,属于治标不治本。正确做法是在 netplan 或 NetworkManager 的连接配置里写死 DNS。netplan 的写法就是前面那段配置里的nameservers字段,配好之后执行sudo netplan apply。如果用 nmcli 管理连接,可以这样改:sudo nmcli connection modify 有线连接 1 ipv4.dns 114.114.114.114,223.5.5.5 sudo nmcli connection up 有线连接 1NAT 模式下还有一个特殊情况:VMware 的 NAT 服务会做 DNS 代理,如果你在虚拟网络编辑器里调整过 NAT 设置,把 DNS 相关的选项关掉了,也可能出现能通 IP 不能解析域名的情况。这时候要么把 DNS 手工指到公共 DNS,要么在 NAT 设置里恢复默认。Windows 虚拟机同样适用这个思路,只不过入口是网络适配器的 IPv4 属性,把 DNS 手工指定成公共 DNS 再执行一次ipconfig /flushdns就行。3.4 场景四:能上网但访问不了,内网服务和端口转发的问题现象描述:虚拟机上网没问题,但宿主机访问不了虚拟机里跑的服务,或者局域网同事访问不了你虚拟机上的项目页面。反过来,虚拟机也访问不到宿主机上跑的某些服务。这种单向不通和前面几种完全断网是两码事。先分清模式:NAT 模式下,宿主机和局域网设备默认不能主动访问虚拟机,这是设计如此,不是故障。要打通,必须在虚拟网络编辑器的 NAT 设置里做端口转发,把宿主机的某个端口映射到虚拟机的 IP 加端口上。配置时需要三个信息:宿主机监听端口、虚拟机 IP、虚拟机服务端口。填完之后,宿主机上访问127.0.0.1:监听端口就能连到虚拟机的服务。这里有个细节容易踩:虚拟机的 IP 如果是 DHCP 动态分配的,某次重启后地址变了,转发规则就会失效,所以做端口转发前最好把虚拟机地址固定下来,或者在 VMware 的 DHCP 设置里给它绑定 MAC 地址分配固定 IP。桥接模式下就简单多了,虚拟机有自己的局域网 IP,直接访问那个 IP 即可,不需要转发。但前提是宿主机的防火墙放行了对应端口,尤其是 Windows 上默认会把入站流量拦得比较严。测试时可以先临时关闭防火墙验证,确认是防火墙问题后再针对具体端口添加放行规则,而不是长期把防火墙关着。还有一个坑值得单独说:有些服务默认只监听127.0.0.1,这种情况下无论你怎么配网络,外部都连不上。比如某些开发服务器启动时如果不加--host 0.0.0.0参数,就只在本机回环上监听。排查时先在虚拟机里用curl 127.0.0.1:端口试试,能通再用虚拟机自己的对外 IP 试,两步都通之后才去怀疑网络配置。4. 常见问题速查与踩坑心得排查做多了会发现,真正难的不是修复操作,而是快速定位。下面这张速查表是我自己整理出来常用的,遇到问题先看现象,基本能直接跳到对应原因。4.1 故障现象与原因对照速查表现象最可能的原因优先动作地址为 169.254 开头DHCP 未生效、桥接选错网卡检查 DHCP 服务、桥接目标网卡VMnet8 带感叹号虚拟网卡驱动异常卸载重装、还原默认设置能 ping IP 不能解析域名DNS 配置错误改 netplan 或连接配置里的 DNS完全不通且服务列表里有停止项VMware 服务未启动启动 DHCP 与 NAT 服务并设为自动宿主机访问不了虚拟机服务NAT 模式未做端口转发配置 NAT 端口映射虚拟机访问不了宿主机服务宿主机防火墙拦截放行对应端口克隆后网卡不激活MAC 变化导致网卡名不匹配修正 netplan 里的网卡名换了 Wi-Fi 后桥接不通网段变了拿不到原地址重新获取 IP 或改用 NAT4.2 三个只有踩过才知道的细节第一个细节,虚拟网络编辑器的权限问题。修改虚拟网络配置需要管理员权限,如果当前账户不是管理员,菜单点开会提示无权操作,或者干脆看不到某些选项。这不是软件坏了,而是权限不够,用管理员身份重新启动一次就好。第二个细节,Hyper-V、WSL2、Docker 这类组件会和 VMware 抢网络栈。装了它们之后,VMware 的虚拟网卡偶尔会出现异常,表现为感叹号或者干脆消失。遇到这种情况,先确认是不是最近装过这类工具,然后按前面的方式重建虚拟网卡。这也是很多人反映系统更新后虚拟网卡莫名没了的真实原因之一。第三个细节,排查时一定要做对照实验。比如怀疑是 DNS 问题,就在同一台虚拟机里分别 ping 一个 IP 和一个域名,结果一对比,结论立刻清晰。如果只在浏览器里刷新页面,你永远只能看到打不开,看不到卡在哪一步。养成用ping、ip route、nslookup这几个命令分步验证的习惯,排查效率会高出一大截。提示:排查过程中每改一步就验证一次,不要一次性改五六项配置再测试。否则问题解决了你也不知道是哪一步起的作用,下次遇到还是不会。5. 让虚拟机网络少出问题的几个使用习惯修好只是第一步,让它以后少复发才是真本事。我自己用了这么多年,总结下来有三条习惯收益最大。第一条,把虚拟机的 IP 固定下来。NAT 模式下可以在虚拟网络编辑器的 DHCP 设置里,按 MAC 地址给虚拟机分配固定 IP;桥接模式下则在虚拟机内部设静态地址,或者让路由器做地址保留。固定 IP 的好处是,你写在代码里的服务地址、配好的端口转发规则、收藏夹里的访问链接都不会因为重启而失效,省掉大量昨天还好好的今天怎么就不通了的困惑。第二条,克隆虚拟机之前先做一次网络清理。把网卡配置里的静态 IP 去掉改回自动获取,清掉 SSH 的 host key 和机器标识,再做克隆。这样新克隆出来的机器不会带着旧机器的网络身份去抢同一套配置,第一开机就能正常获取地址。这一步花两分钟,能省掉后面一小时的排障。# Ubuntu 克隆前清理机器标识,让新机器重新生成 sudo truncate -s 0 /etc/machine-id sudo rm -f /etc/ssh/ssh_host_*第三条,给每个虚拟机留一份网络配置备忘。把它的模式、网段、IP、网关、DNS、配过的端口转发规则、需要用到的服务名记在一个文本文件里,放在虚拟机目录旁边。等到半年后重新打开这个环境,你会庆幸自己当初记了这几行。最后再说一个我个人很常用的技巧:如果准备做网络相关的实验或者要装一些不太确定影响范围的服务,先在虚拟网络编辑器里新建一个独立的 VMnet 网段,把虚拟机的网络模式改成自定义并指向这个新网段,让它和你的日常工作网段彻底隔开。这样即使实验把网络配置搞乱了,也只是这一个隔离网段的事,不会波及正在使用的环境。这个做法在需要反复重置网络的场景下非常省心,推荐你也试试。