企业官网建设流程全解析

你是不是也经历过这种场景：VMware里装好了Ubuntu或者CentOS，终端打开，输入ping www.baidu.com，结果一行红色超时刷下来，连网关都ping不疼不痒的没反应。更气人的是，同一台机器上VirtualBox里的虚拟机却能正常上网，Windows宿主机也好好的。这种“看似小问题、折腾一晚上”的Linux虚拟机联网失败，几乎每一个搞过运维或者刚入门虚拟化的朋友都踩过。它之所以难搞，是因为“不能上网”这四个字背后，可能藏着网卡没有启动、DHCP没拿到地址、NAT服务没开、桥接网卡选错、DNS解析异常等完全不同的原因，而且网上搜出来的教程大多是Copy来Copy去，要么命令过期，要么版本对不上，照着点根本解决不了问题。

这篇内容我就用实际排障的视角，把Linux虚拟机无法联网这件事从头到尾拆开揉碎讲一遍。不管是VMware Workstation还是VirtualBox，不管你是CentOS 7、CentOS Stream还是Ubuntu 22.04，核心的排查思路和命令是通用的，照着做至少能解决九成以上的问题。适合刚装好虚拟机还没通网的初学者，也适合被公司分配了“把这台Linux虚拟机网络弄好”这种任务、手上却没什么参考资料的朋友。

1. 先把问题分类：Linux虚拟机不能联网到底分几种情况

1.1 三种常见的“不能上网”现象

我在实际处理过程中发现，很多人说“虚拟机连不上网”时，其实说的是完全不同的三件事，如果不提前区分，后面排查方向就容易跑偏。

第一种是宿主机本身就不通网。这个听起来很蠢，但真有人折腾了两三个小时虚拟机，最后发现是公司网络的认证页面弹出来没登录，或者物理网线松了。Windows下可以ping网关或者直接打开浏览器测试，先把宿主机网络确认好，再谈虚拟机。

第二种是虚拟机能够和宿主机互相访问，但访问不了外网。这种通常出现在“仅主机模式”（Host-Only）或者自定义网络配置的场景里。特点是你用ssh连虚拟机没问题，宿主机和虚拟机之间ping得通，但一访问公网地址就超时。

第三种是虚拟机完全不通，连网关和宿主机都ping不到。这种最极端，通常意味着网卡没起来、没拿到IP、虚拟网络服务出了问题，或者网络模式配置本身就不对。必须逐层往下查。

我习惯用寄快递来理解这个问题：你要把虚拟机里的一个包裹寄到互联网上，第一步这个包裹得先交到快递员手里，对应的是虚拟机内部网卡和IP要正常；第二步快递员要把包裹送到集散中心，对应的是网关要通；第三步集散中心要把包裹送上主干运输线，对应的是NAT或桥接线路要通；最后一步是目的地的地址能被解析出来，对应的是DNS要正常。哪一步断了，现象都是“包裹寄不出去”，但断的位置完全不同。

1.2 先记住排障的黄金顺序：由下往上、先内后外

踩了几次坑之后，我现在面对任何“网不通”的问题，都强制自己按固定的顺序排查，绝不跳步。这个顺序就是：网卡物理状态 -> IP地址是否就位 -> 网关是否可达 -> DNS是否正常 -> 防火墙和系统服务是否拦截。

由下往上的意思是，先确认底层的链路状态，再去看上层的应用问题。你如果发现DNS解析不了，但连IP地址都没配，那先去解决IP问题，而不是在DNS配置里折腾。先内后外的意思是，先保证虚拟机和宿主机、虚拟机和网关之间能通，再去判断外网的问题。把内网通了再测外部，问题边界会清晰很多。

1.3 准备一套不会过时的排查工具

虽然不同发行版命令有些差异，但下面这几个工具是Linux系统自带的，除非你把系统裁剪得很精简，否则一般都有：ip、ping、route或ip route、traceroute、nmcli、systemctl、cat。建议一开始就用ip addr而不是ifconfig，因为CentOS 8之后ifconfig不是默认安装了，ip命令才是长期稳定的写法。排查网络连通性的工具足够用了，不需要额外安装什么包，这点倒是挺省心。

另外，Windows宿主机上建议先打开服务管理器确认VMware相关的几个服务状态，这个后面单独讲，但它是在Windows里排查，不属于Linux命令范畴，提前做到心里有数。

2. 虚拟机网络模式：搞清楚NAT、桥接、仅主机的区别再动手

2.1 NAT模式：默认且最省心，但依赖宿主机的NAT服务

VMware和VirtualBox安装完Linux虚拟机之后，默认给你的网络模式基本都是NAT。NAT的中文叫网络地址转换，你可以把它理解成宿主机充当了一个“翻译官兼快递中转站”：虚拟机没有自己独立的公网IP，所有对外访问都借宿主机IP发出去，回来的时候再由宿主机把数据转交给对应的虚拟机。

这个模式最大的好处就是“省心”：只要宿主机能上网，虚拟机里正常开启DHCP，它基本就能自动上网，不需要额外的配置。但这里藏着一个关键依赖——宿主机的NAT服务进程。在VMware里是VMware NAT Service，在VirtualBox里是VirtualBox DHCP Server和VirtualBox NAT Network。如果你把这个服务停掉了或者安装的时候没装完整，那虚拟机里的网卡就算已经UP，也拿不到地址或出不了网，现象就是你Linux虚拟机里一直卡在“正在连接网络”或者完全没有IP。

所以，用NAT模式排障时，我会先确认宿主机上的VMware服务列表里，VMware NAT Service和VMware DHCP Service是不是“正在运行”。这一点很多人会漏掉，因为虚拟机安装时一切正常，过了几天突然断网，很可能是Windows优化软件或者系统更新把这个服务禁掉了。

2.2 桥接模式：虚拟机变成局域网里的“真实主机”

桥接模式下，虚拟机的网卡直接和宿主机的物理网卡“搭桥”，虚拟机和宿主机在局域网里像是两台独立的主机，都能从路由器获取IP。它的好处是虚拟机拥有自己在局域网内的独立身份，可以被局域网内其他设备直接访问，适合做服务器演示或者集群实验。

但这个模式也有坑：如果宿主机同时有多个网卡，比如有线网卡、无线网卡、虚拟网卡，而VMware桥接选择了错误的网卡，虚拟机就会一直拿不到IP或者虽然拿到IP却出不了外网。我遇到过好几次，笔记本用Wi-Fi上网，VMware默认桥接到了有线网卡上，而有线网卡根本没有插网线，结果虚拟机的网卡状态始终是“未连接”。

桥接模式还有一个容易被忽略的问题：宿主机换了网络环境，比如从公司网络切到家里路由器，网络段完全不同了，桥接网卡可能仍然绑定着旧网卡信息，导致虚拟机获取不了IP。一般重新启动虚拟网络编辑器里的桥接设置或重启VMware服务就能解决。

2.3 仅主机模式：它本来就是用来“断外网”的

仅主机模式的意思很简单，虚拟机只能和宿主机之间通信，不能访问外网，反之亦然。这个模式不是用来修“联网问题”的，它的用途恰恰是隔离环境，比如做渗透测试、搭建安全实验环境，或者模拟一个不能访问互联网的内部系统。

如果你发现自己的虚拟机网络模式是仅主机，还希望它能上外网，那就不要在这个模式上浪费时间了，直接切到NAT模式最省事。很多人搞混了这个概念，在仅主机模式下配了半天的网关和DNS，自然是徒劳无功。

2.4 改完网络模式后一定要重启网络，而不是傻等

从“虚拟网络编辑器”里切换了模式之后，虚拟机内部不会立刻刷新网络状态，你至少要做两件事中的一件：在虚拟机里重启网络服务，或者把网卡down掉再up。很多新手等了十分钟发现还是不通，就在网上继续搜教程，其实只需要一条命令就能让新配置生效。

CentOS系用systemctl restart network，Ubuntu 18.04以上用netplan apply或者重启Netplan服务，另外也可以直接执行nmcli connection reload后再nmcli connection up eth0。有些发行版的NetworkManager坑比较多，多试几个命令没关系，只要看到网卡状态的IP地址变成新网段的地址，就是生效了。

3. 一份可以直接照着操作的排障流程

3.1 第一关：确认虚拟机里的网卡到底“活着”没有

先在虚拟机终端里执行ip addr，看返回的网卡列表。一般VMware下会有一个ens33、ens160或者eth0的网卡，Ubuntu新版本可能是ens18这种名字。注意看两个关键信息：网卡状态是不是UP，广播地址下面有没有显示inet这个字段。

如果网卡状态是DOWN，执行ip link set ens33 up把它启动。如果提示权限不足，就前面加sudo。这里有个细节：有些最小化安装的CentOS，默认网卡就是DOWN的，因为ant安装时没有开启。手动启动只是临时生效，重启虚拟机之后可能又变回DOWN，所以后面还需要修改配置文件。

如果连网卡都看不到，那就要检查虚拟机设置是不是漏了网卡设备，或者VMware Tools没装好导致虚拟网卡驱动没加载。点开虚拟机的“设置 -> 网络适配器”，确认勾选了“已连接”和“启动时连接”，这一点看起来基础，但很多人真的忽略了。

3.2 第二关：网卡没拿到IP的时候怎么处理

如果ip addr输出里没有inet字段，说明网卡没拿到IP地址，你要么走DHCP自动获取，要么手动配置静态地址。绝大多数虚拟机场景，先用DHCP把网调通再说，静态IP可以后面再改。

CentOS/RHEL系的网卡配置文件在/etc/sysconfig/network-scripts/ifcfg-ens33，如果是旧版本可能是ifcfg-eth0。用vim或者nano打开，确认里面有三行关键配置：

• ONBOOT=yes，这决定了开机时是否会激活网卡
• BOOTPROTO=dhcp，这是用DHCP自动获取地址
• NM_CONTROLLED=yes，把控制权交给NetworkManager

改完执行systemctl restart network。如果不行，再执行dhclient -v手动触发一次DHCP请求，看能不能拿到地址。Ubuntu新版本没有ifcfg文件，而是用/etc/netplan/下的yaml配置，格式稍微不同，但核心逻辑一样：ens网卡的dhcp4一般默认就是true，不需要额外设置。执行netplan apply让它生效。

这里提醒一下，手动执行dhclient确实能快速测试网络环境是不是通的，但如果系统里同时有NetworkManager又跑了dhclient，可能出现地址互相冲突的奇怪现象，最简单的办法是测试完就停掉dhclient，并把网络重启回正规的服务管理流程。

3.3 第三关：网关通不通，判断问题在内网还是外网

拿到IP之后，下一步确认默认网关。执行ip route看路由表，一般会看到一行“default via 网关地址 dev 网卡名”。如果没有默认路由，那你得从配置文件或DHCP上找原因。CentOS里如果BOOTPROTO=static，必须手动加一行GATEWAY=网关IP，然后重启网络。

网关确认之后，执行ping 网关IP -c 4。这里注意，不要一上来就ping百度，因为ping百度失败时，你分不清到底是网关问题还是DNS问题还是外网链路问题。先把网关ping通，相当于确认了虚拟机到“集散中心”这一段是好的，再去测外网。

如果网关都ping不通，说明问题出在虚拟网络底层，基本不用继续往里查了。你接下来应该去检查宿主机上的VMware虚拟网络设置、确认虚拟网络编辑器里NAT子网地址和DHCP是否正常，或者换一种网络模式试试。

3.4 第四关：出去了但域名解析不了，这是DNS问题

网关通了，但ping baidu.com不通，这时候先不要急着骂运营商，先ping一个公网IP地址，比如114.114.114.114或者223.5.5.5。如果IP能ping通而域名ping不通，那问题就锁定了：DNS解析异常。

Linux的DNS配置文件在/etc/resolv.conf，正常你打开会看到nameserver一行，它的值可能是DHCP自动分配的，也可能是手动写的。如果这个文件里什么都没有，或者指向了一个无效的DNS服务器，那域名自然解析不了，你学再多排障命令也白搭。

修改resolv.conf的常见做法是加一行nameserver 223.5.5.5。但要注意，如果你的系统开启了NetworkManager，它可能会自动覆盖这个文件，改完没效果也是正常的，需要通过nmcli或者图形界面设置DNS才有效。另外Ubuntu的systemd-resolved接管DNS后，直接改resolv.conf也不是长久之计，正确是用resolvectl或者设置里的图形界面配。、如果DNS解析不了，还可以用nslookup或者dig命令验证，但这两个工具不是所有系统都有，需要另外安装。

3.5 最后一道：防火墙和SELinux会不会是自己人拦自己人

系统层面都通透了之后，很可能被忽视的是防火墙。很多刚学Linux的朋友，宿主机Windows防火墙弹窗点了一下“阻止”，就再也不管了，或者在虚拟机里安装完最小化CentOS后，firewalld默认拦截了所有外部流量，导致里面能ping通外面，外面却完全进不了虚拟机。

如果你想快速确认是不是防火墙的问题，用systemctl stop firewalld暂时关闭防火墙，然后测试连通性，如果能通了，说明就是防火墙策略的问题。但远程服务器上做这个操作要谨慎，因为停止防火墙可能会把ssh连接也断了，建议你在VMware控制台界面里操作，不要远程操作。

CentOS上还有一个容易被忽略的“隐形拦截者”叫SELinux，它不一定直接拦截网络，但会让网卡切换配置、端口绑定莫名其妙失败。排查联网问题的时候，如果系统日志里没有任何网络报错，但服务就是起不来，可以尝试临时把SELinux改成permissive模式，setenforce 0，看看问题是否消失。如果是刚装好的系统，我通常建议先把SELinux的策略理清楚再决定是否关闭，因为生产环境不建议长期关闭，但在虚拟机里排障阶段临时放宽限制是没问题的。

4. 我把高频踩坑点整理成了一张排查表

4.1 VMware服务没启动：最容易被忽略的Win端坑

我先给你看一眼这张表里最经典的一个场景。用VMware Workstation的NAT模式时，宿主机Windows侧必须有VMware NAT Service和VMware DHCP Service这两个服务在运行。按下Win+R输入services.msc打开服务管理器，找到这两个服务，如果状态是“已停止”或者“禁用”，右键启动，然后到虚拟机里重启网络服务。

另外还有一个VMware Authorization Service也要顺手检查，它主要负责权限校验，某些版本如果它没启动，虚拟网络编辑器的修改操作会失败。总之，VMware装完不会自动把这些服务设置为开机启动，如果你用了某些“系统优化”工具把它们禁用了，那就只能手动启动并改回自动。

4.2 桥接模式联网失败：八成是宿主机网卡选错了

前面提过，笔记本用户桥接失败的概率比台式机高，就是因为无线网卡和有线网卡的选择问题。打开VMware菜单“编辑 -> 虚拟网络编辑器 -> 更改设置”，选中VMnet0，如果它显示的是“桥接到”，看右边的下拉框选的是哪个网卡。需要选中的是你宿主机当前正在上网的那个网卡，有线联网就选有线那个，无线联网就选无线那个。

如果你的电脑只有一个网卡，那不用纠结，但如果你插了USB网卡、又有板载网卡、还连了Wi-Fi，就一定要看清楚名字。比如“Realtek USB GbE Family Controller”和“Intel(R) Wi-Fi 6 AX201”是两个完全不同的网卡，选错了就上不了网。

这一步操作非常常见且隐蔽，很多时候我在虚拟机里折腾半天，最后发现VMware桥接的网卡根本不是宿主机正在用的那一块。其实还有个办法，就是你干脆把桥接到改成“自动”，有些版本会自动选择。如果“自动”仍然不稳定，那就手动明确指定。

4.3 配置文件字段写错，改完还不生效

编辑ifcfg文件的时候，最容易踩的坑有几个：一是ONBOOT写成了NO而不是no，大小写不敏感，但写成NO可能会引发解析异常；二是BOOTPROTO写成static但没配GATEWAY，虚拟机起来后没有默认路由；三是IPADDR、NETMASK、GATEWAY这几个字段的拼写漏了一个字母，导致系统直接无视这个配置文件。

如果你改完配置，执行systemctl restart network报错，多数情况下可以通过journalctl -xe或者tail /var/log/messages看到具体错误。还有，CentOS 8以后systemctl restart network可能提示找不到该服务，因为默认不再使用network.service了，需要改用nmcli或者networkmanager。

这种情况下你可以直接执行nmcli device connect ens33来激活网卡，或者用nmcli connection modify动态修改IP。学会nmcli操作，本质上跟改配置文件是一个目的，只不过路径不同，但对于新版本系统而言更保险。

4.4 网卡克隆带来的“双地址”和MAC冲突

VMware克隆虚拟机后，原虚拟机和新虚拟机的网卡MAC地址相同，新虚拟机在网络上会出现“IP冲突”或者干脆拿不到IP。这是克隆之后比较常见的网络问题，其实处理起来也不难，在虚拟机设置里重新生成网卡MAC地址，或者修改ifcfg文件里的HWADDR字段。很多模板虚拟机克隆后，ifcfg里写死了旧的MAC，新虚拟机的网卡实际MAC和配置文件里的不匹配，也会导致网络起来失败。

如果是你自己手动指定过IP地址，也建议检查一下是不是和局域网内其他主机重复了。重复IP的表现是时通时不通，特别随机，这类问题上网搜很难搜到准确答案，但对照表能快速定位。

4.5 Ubuntu系统的黑屏和联网其实没关系，但总是同时出现

网上热词里有个“虚拟机ubuntu黑屏进不去桌面”，很多人黑屏之后第一反应是重装，其实黑屏常常跟显卡和内核驱动有关，和联网配置没有直接关系。但如果黑屏导致你看不到终端，那任何排查命令都用不了，好像就被卡死了。

遇到黑屏我一般会先用Ctrl+Alt+F3，切换到文本终端，用命令行先把网络排查完，再回头处理图形界面。如果你只是想临时用，文本终端也够用，至少不用重装系统。还有一种黑屏是因为VMware Tools没装好，网卡驱动也可能加载不全，导致虽然没有断网但系统界面卡死，把open-vm-tools装一遍往往能解决。

5. 分享几个我一直沿用的操作习惯

踩过的坑多了，慢慢就有了一些固定习惯。首先，我不论是新装虚拟机还是克隆现有虚拟机，第一步永远是先看宿主机网络是不是通的，再打开ip addr确认网卡是否UP，这两件事十分钟就能确认完，省掉后面数小时的瞎折腾。

其次，我在配置Linux虚拟机网络时，默认第一选择NAT模式，因为在虚拟化环境里它最不依赖外部网络环境，换Wi-Fi、换公司网线、换个路由器都不影响内部通信，非常适合学习和测试。如果真的有对外提供服务的需求，我才会改成桥接模式，并且一定手动指定正确的桥接网卡。

最后一个习惯是“一次只改一个变量”。修改网卡模式之后，先重启虚拟机网络服务测试；如果不行，再看DHCP服务是否开启；还是不行，才去查DNS和防火墙。不要同时改网络模式、改静态IP、改DNS，那样出了问题你根本不知道是哪一步导致的。这个习惯不光用在虚拟机联网上，整个运维排障都适用。

Linux虚拟机联网这个问题，本质上不难，难的是你可能在一堆互相矛盾的教程里找不到正确的那条路。希望这篇基于实际排查过程整理的内容能帮你少走几步弯路。如果你遇到的问题还没解决，回头再看一眼那张排查表，把网络模式、服务状态、网卡配置、IP地址、网关、DNS逐项过一遍，基本上就能找出问题了。