企业官网建设流程全解析

装虚拟机的朋友大概都有过这种经历：系统装完、环境配好，正准备更新一下软件源，终端里敲完命令回车，光标转了两圈，弹出一串“连接超时”。切到浏览器刷新，页面转圈转到底也是空白。于是打开设置翻半天，改了几处配置重启，网络还是不通，最后只能靠重装系统碰运气。VM 虚拟机里 Ubuntu 无法联网，本质上是数据包在某个环节走断了，可能是宿主机侧的虚拟网卡、DHCP 和地址转换服务，也可能是客户机侧的网卡识别、IP 配置、默认路由和域名解析。这中间涉及虚拟网络模式选择、VMnet 适配器状态、netplan 配置文件语法、systemd-resolved 解析链路等一连串环节，任何一个环节掉链子，表现出来的症状都一样：网页打不开。

这篇内容面向的是刚接触虚拟化环境的新手，以及那些“上一次能通、这次不通”的老用户。下面我会按数据包从虚拟机走到外部网络的真实顺序，一层一层往外排查：先讲清楚三种网络模式的区别和适用场景，再讲宿主机侧那些看不见的开关，然后落到 Ubuntu 内部的网卡和 IP 配置，最后收尾在路由与 DNS 这两个高频陷阱上。文中给出的配置片段和命令都可以直接复制，虚拟网络的具体参数请根据你自己的环境调整。整个过程不需要重装系统，绝大多数问题十几分钟能定位。

1. 断网先分层，别一上来就改配置文件

多数人遇到断网的第一反应是去改 Ubuntu 的网卡配置，改完不生效就怀疑人生。这个顺序是反的。虚拟机的网络是一条链，链上有五六个节点，从哪一头开始查决定了你排查的效率。正确做法是先用几条命令把故障范围压到最小，确定问题出在“虚拟机自身”还是“虚拟机之外”，再决定动哪里。

1.1 三种网络模式到底差在哪

要排网络，先得知道自己用的是哪种模式，因为三种模式的故障点和修复方式完全不同。

• 桥接模式：虚拟机的网卡直接连到宿主机所在的物理网络，相当于这台虚拟机是局域网里的一台独立设备，会从路由器拿到和宿主机同一网段的 IP。优点是外部设备能直接访问虚拟机，适合搭建需要被访问的测试环境；缺点是对物理网卡依赖极强，宿主机换网络、换 Wi-Fi、切有线，虚拟机就得跟着重新配，而且无线网卡下桥接失败率相当高。
• NAT 模式：虚拟机通过宿主机上的虚拟网卡和地址转换服务对外通信，虚拟机在内网段，宿主机做转发。这是默认也是最省心的模式，虚拟机上网、更新源、访问外部服务都没问题，缺点是外部设备默认访问不到虚拟机，需要额外配置端口映射。
• 仅主机模式：只连宿主机，出不了外网。这个模式本身就不是给你上网用的，很多人误选之后抱怨“没网”，其实不是故障，是模式选错了。它适合做隔离实验，比如测试一台机器被切断外部连接后的行为。

我一般建议新手一上来就用 NAT 模式，把网络通路和环境隔离这两件事分开处理。等你明确需要虚拟机被局域网内其他机器访问时，再考虑桥接。判断当前用的是哪种模式，直接在虚拟机软件的虚拟机设置里看“网络适配器”那一栏就知道，同时留意“已连接”和“启动时连接”两个勾选项是否都勾上了，漏勾“启动时连接”是一个非常隐蔽的坑，表现为每次开机都没网，手动点一下才通。

1.2 从外到内的四步定位法

我习惯按下面这个顺序压范围，每一步都用一个命令给出明确结论，不要凭感觉。

第一步，在虚拟机里执行ip -br link，看有没有一块状态是UP的网卡（名字可能是ens33、ens160、eth0）。如果只有一块lo或者网卡状态是DOWN，问题在客户机内部，往下看第 3 章。如果网卡是UP但没有 IP，继续第二步。

第二步，执行ip -4 addr show，看网卡上有没有inet地址。有地址说明 DHCP 拿到了租约，问题大概率在路由或 DNS；没地址说明 DHCP 链路断了，得回头查宿主机侧的地址分配服务，这是第 2 章的内容。

第三步，有了 IP 之后，ip route看默认路由在不在，然后按顺序 ping 三个目标：网关、一个公网 IP、一个域名。这三个 ping 的结果组合起来基本能直接指向病因，具体对应关系我在第 5 章的速查表里列了。

第四步，只有在 IP、路由都正常、ping 公网 IP 通但域名不通的情况下，才把注意力全放到 DNS 上。很多人一上来就改 DNS，改了没用是因为前面的链路本来就没通。

提醒：排查过程中每改一处配置，就用同一套命令复测一次。同时改三五处再重启，通了也不知道是哪一处起的作用，下次出问题照样抓瞎。

这套方法的价值在于它给了你一个可复用的决策树，而不是一堆散落的命令。下次再断，照着走一遍就行。

2. 宿主机侧：那些藏在系统服务里的开关

虚拟机软件在宿主机上安装的时候，会悄悄装两块虚拟网卡和两个后台服务。这两块网卡在“网络连接”里能看到，名字通常带 VMnet 前缀；两个服务在服务管理器里，负责地址分配和地址转换。它们任何一方没跑起来，虚拟机就表现为“网卡在、但拿不到 IP”。这一层的问题是所有故障里最容易被忽略的，因为大家习惯盯着虚拟机内部看。

2.1 VMnet8 虚拟网卡和服务状态自查

如果你用的是 NAT 模式，宿主机上对应的是编号 8 的那块虚拟网卡。打开宿主机的命令行，执行ipconfig /all（Windows 环境），找到那块虚拟网卡，重点看两个东西：它有没有一个形如192.168.x.1的 IPv4 地址，以及“默认网关”是不是空的。正常情况下宿主机这块网卡应该是这个网段的.1，虚拟机的网关则是.2，两个地址不能搞混。

接下来打开服务管理器，找到名字里带“DHCP”和“NAT”的两个虚拟机相关服务，确认状态是“正在运行”，启动类型是“自动”。这两个服务被某些系统优化工具、安全软件的“开机加速”功能关掉是常事，关掉之后虚拟机开机就拿不到地址。手动启动之后，回到虚拟机里执行一次释放和重新获取：

# 先释放当前租约，再重新申请 sudo dhclient -r ens33 sudo dhclient ens33 # 确认是否拿到了地址 ip -4 addr show ens33

如果这条命令能拿到地址，说明问题就是服务没启动，把服务启动类型改成自动即可。如果执行后依然没地址，且终端没有任何输出，那大概率是虚拟网络本身配置有问题，进入下一小节。

另一个容易被忽略的点是宿主机这块虚拟网卡被系统或安全软件禁用了。在“网络连接”面板里看图标是不是灰的，灰的点右键启用。有些安全软件会把这类虚拟网卡识别为可疑设备并主动阻断，表现是网卡显示已启用但虚拟机始终拿不到地址，可以临时关闭安全软件的网络防护做一次对照测试。

2.2 虚拟网络编辑器里的三个参数陷阱

虚拟机软件自带一个虚拟网络编辑器，入口在菜单栏的“编辑”下面，打开需要管理员权限。这个面板里的参数改错一个，整条链路就断，而且它不会给你任何报错提示。

第一个陷阱是子网地址和宿主机实际网段冲突。比如你的办公网络本身就是192.168.100.0/24，而虚拟网络的子网也设成了192.168.100.0，这时候路由表会出现两条指向同一网段的记录，数据包到底走物理网卡还是虚拟网卡就变成了掷硬币。表现是虚拟机时通时不通，或者能 ping 通网关但访问不了任何外部地址。处理办法很简单，把虚拟网络的子网换到一个不冲突的段，比如192.168.137.0，改完点应用，虚拟机重新拿一次地址。

第二个陷阱是“将主机虚拟适配器连接到此网络”这个复选框没勾。这一项不勾，宿主机上就不会出现对应的虚拟网卡，虚拟机和宿主机之间连最基本的通路都没有。检查方式就是前面说的ipconfig /all，看不到那块网卡就是没勾。

第三个陷阱是 DHCP 设置里的地址池范围被改小了甚至清空了。正常情况下它会自动分配一个范围，但如果之前有人手动改过起始和结束地址，可能出现范围极小、甚至起始大于结束的情况，虚拟机自然分不到地址。这里的建议是：不确定就点“还原默认设置”，这个按钮会把所有虚拟网络参数恢复成安装时的状态，是解决疑难杂症最快的一招，代价是你之前自定义的端口映射之类会丢，需要重新配。

2.3 桥接模式为什么总是失败

桥接模式不通的情况，九成以上和物理网卡的选择有关。虚拟机软件在桥接时会自动挑一块物理网卡去桥接，如果宿主机同时有有线和无线两块网卡，它很可能挑错了。在虚拟网络编辑器里把桥接目标从“自动”改成明确指定“有线网卡”或“无线网卡”，通常立刻见效。

无线网卡本身的限制也要说清楚：部分无线网卡驱动不支持桥接所需的混杂模式，这种情况下桥接怎么配都不通，不是配置问题，是硬件能力问题。我遇到过一台笔记本，有线桥接一切正常，切成无线就死活不通，最后只能改成 NAT 模式加端口映射来达到“外部能访问”的目的。所以如果你在无线环境下必须用桥接，先别急着怀疑配置，直接用一根网线插上试一次做对照，能快速排除硬件因素。

还有一种情况是宿主机所在的网络有接入限制，比如办公网做了地址绑定，只允许登记的物理地址上网。桥接模式下虚拟机会用自己的虚拟地址去申请，被网络侧拒绝，表现为拿不到地址或者拿到了但出不去。这种环境下老老实实用 NAT，别跟网络策略较劲。

3. 客户机侧：网卡、IP 与 netplan 配置

宿主机侧确认没问题之后，问题就落在 Ubuntu 内部了。从 17.10 版本开始，Ubuntu 的网络配置统一由 netplan 接管，配置文件放在/etc/netplan/目录下，后缀是.yaml。这个工具的好处是配置集中、声明式；坏处是它对 YAML 语法极其敏感，一个缩进错误就能让整份配置被静默忽略，你重启多少次都没用，而且它不会明确告诉你“你的缩进错了”。

3.1 先确认网卡有没有被认出来

在改任何配置之前，先确认系统认到了这块网卡。执行ip -br link，输出里除了lo之外应该还有一块，名字通常是ens33或ens160（新版用 PCI 位置命名）。如果只有lo，说明网卡根本没被识别，这时候改配置文件毫无意义，得往更底层查。

# 看所有网络设备的状态 ip -br link # 看内核是否识别到了这块虚拟网卡 lspci | grep -i ethernet # 查看详细的硬件信息 sudo lshw -C network

如果内核层面能看到设备但ip link里没有，尝试手动启用：sudo ip link set ens33 up。如果提示“找不到设备”，说明虚拟机的网卡设备本身没挂上，回到虚拟机的设置里检查网络适配器是否被移除、是否勾选了“已连接”。

网卡名搞错是另一个高频问题。教程里写的是ens33，你机器上实际是ens160，照抄配置文件之后 netplan 找不到匹配的网卡，配置整份失效。每次改配置前先确认自己的网卡名，这个习惯能省掉大量时间。

3.2 netplan 配置的正确写法与版本差异

确认网卡名之后，看一下/etc/netplan/目录里现有哪些文件，通常是一个类似01-network-manager-all.yaml或50-cloud-init.yaml的文件。不要新建第二个文件，多个配置文件之间的优先级和合并规则很容易踩坑，直接编辑已有的那个最稳妥。

NAT 模式下最简单的配置就是走 DHCP，整份文件只有几行：

network: version: 2 ethernets: ens33: dhcp4: true

写完应用：sudo netplan apply。注意 YAML 的层级必须用空格缩进，绝对不能用 Tab，两个空格一级，缩进层级错了 netplan 会把这段配置当成不存在，而apply命令依然返回成功，这是最坑的地方。应用之前可以先跑sudo netplan generate，它会在语法有问题时报错，比 apply 更早暴露问题。

需要固定 IP 的时候，不同版本的写法有差异。20.04 及更早的版本流行用gateway4指定网关，这个字段在 22.04 之后已被标记为弃用，虽然可能还能用，但新版本应该改用routes：

network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.137.50/24 routes: - to: default via: 192.168.137.2 nameservers: addresses: [8.8.8.8, 114.114.114.114]

这里的地址和网关要和你宿主机上看到的虚拟网络参数对上。网关填错了，表现就是能 ping 通同网段的其他机器，但出不去。写完执行sudo netplan apply，如果报“Permissions for xxx are too open”的警告，按提示把权限收紧：

sudo chmod 600 /etc/netplan/*.yaml

提示：sudo netplan try比 apply 更安全，它会应用配置并给你 120 秒确认时间，超时没确认就自动回滚。远程连着的机器上改网络配置，一定要用 try，不然改错一次就得去物理机前救场。

3.3 桌面版和服务器版的分工不同

桌面版 Ubuntu 默认由 NetworkManager 管理网络，netplan 配置文件里通常写着renderer: NetworkManager，意思是把配置交给 NetworkManager 执行。这种情况下你用nmcli改的配置和 netplan 文件里的内容可能会打架，改完重启又被覆盖回去。

# 查看设备与连接状态 nmcli device status nmcli connection show # 用命令行改一个连接为自动获取 nmcli connection modify "有线连接 1" ipv4.method auto nmcli connection up "有线连接 1"

服务器版默认用 systemd-networkd 作为渲染器，不装图形界面，nmcli可能压根没有。这时候所有配置都走 netplan 文件，改完netplan apply即可。判断当前用的是哪个渲染器，看 netplan 文件里有没有renderer那一行就行。混用两套工具是桌面版配置反复失效的常见原因，我一般建议：桌面版就用图形界面或 nmcli 管理，别去手改 netplan；服务器版就老老实实改 netplan 文件，别装 NetworkManager。

3.4 克隆与复制导致的网卡名错位

这条专门写给用克隆功能的人。从一台模板机克隆出新虚拟机之后，经常出现新机器没网，而且网卡名从ens33变成了ens34甚至ens36。原因是被克隆的机器里保留了一份网络设备与网卡名的绑定记录，新机器生成的新虚拟网卡特征对不上旧记录，系统就给它分配了一个新名字，而你原来的 netplan 配置还写着旧名字，自然匹配不上。

处理方式有两种。省事的做法是把 netplan 文件里的网卡名改成新的那个，重新 apply。更彻底的做法是清掉旧的绑定记录再重启：

# 查看绑定记录（记录文件按实际系统路径为准） cat /etc/udev/rules.d/70-persistent-net.rules 2>/dev/null || echo "无此文件" # 新版系统多用下面这个位置的记录 ls /etc/systemd/network/

新版 Ubuntu 一般不再用 udev 规则文件绑定网卡名，而是按 PCI 总线位置命名，所以克隆后改名的现象比老版本少。但如果你是从很老的镜像克隆的，还是会遇到。另外克隆时虚拟机软件会问你“已移动”还是“已复制”，选“已复制”会重新生成虚拟机的唯一标识和虚拟网卡地址，选“已移动”则保留原值。同一个网络里出现两台虚拟网卡地址相同的机器，会直接导致网络异常，这也是克隆后断网的一个原因。凡是克隆出来的机器，一律选“已复制”。

4. 能 ping 通 IP 却上不了网：DNS 和路由收尾

到这一步，网卡有 IP、网关能 ping 通、公网 IP 也能 ping 通，但浏览器就是打不开页面，ping example.com提示“名称解析失败”或“Temporary failure in name resolution”。这就是典型的域名解析问题，也是最容易被误判成“没联网”的一种情况。区别方法很简单：ping 8.8.8.8通、ping example.com不通，就是解析的问题；两个都不通，回去查路由。

4.1 DNS 三层配置的优先级

Ubuntu 上的域名解析配置有三个层次，优先级从高到低分别是：netplan 里写的nameservers、NetworkManager 连接配置里的 DNS、以及/etc/resolv.conf。很多教程让你直接改/etc/resolv.conf，改完重启就失效，因为在新版系统上这个文件往往是个软链接，指向 systemd-resolved 管理的运行时文件，重启就被重新生成。

# 先看这个文件到底是什么 ls -l /etc/resolv.conf # 典型输出可能指向 /run/systemd/resolve/stub-resolv.conf # 查看解析服务的整体状态 resolvectl status

正确的做法是在 netplan 里写nameservers，让它成为持久配置，然后重启解析服务：

sudo systemctl restart systemd-resolved

如果你想临时验证是不是 DNS 的问题，可以不改任何配置，直接用一个公网地址做解析测试：

# 直接用指定服务器解析域名，绕过系统配置 nslookup example.com 8.8.8.8 # 或者 dig @114.114.114.114 example.com

如果这条命令能返回结果，而ping example.com依然失败，那问题就百分百锁定在系统解析配置上。还有一种少见但真实的情况是解析服务本身没启动，systemctl status systemd-resolved显示 failed，重启服务或者检查配置文件里的DNS=那部分有没有写错。

4.2 路由表和默认网关

默认路由缺失的表现是：能 ping 通同网段的地址（比如网关），但任何跨网段的地址都不通，ping 8.8.8.8直接提示“Network is unreachable”。

# 查看路由表，重点看有没有 default 那一行 ip route # 正常应该类似：default via 192.168.137.2 dev ens33 proto dhcp metric 100

没有 default 行就是没默认路由。原因通常是 DHCP 拿地址的时候没同时下发网关，或者静态配置里网关字段漏了、写错了。手动加一条临时路由验证：

sudo ip route add default via 192.168.137.2 dev ens33

加上之后立刻能上网，说明判断正确，接着把网关写进 netplan 配置里做成永久的。注意网关地址必须是虚拟网络里的那个.2地址，写成宿主机虚拟网卡的.1是不通的，这两个地址长得很像，我见过不少人就是在这里卡了半天。

还有一种更隐蔽的情况：路由表里同时存在多条 default 记录，metric 值不同，数据包走了错误的那条。常见于同时启用了有线和无线、或者装过其他虚拟化软件的环境。用ip route看清楚，把多余的那条删掉，或者在配置文件里显式指定 metric。

4.3 防火墙与安全软件造成的干扰

网络配置全对、路由正常、DNS 正常，网页还是打不开，这时候应该怀疑防火墙。Ubuntu 自带的防火墙默认是关闭的，但如果你装过某些服务端软件，可能会被顺手打开。

# 查看防火墙状态 sudo ufw status verbose # 如果确实开着且规则有问题，临时关闭做对照测试 sudo ufw disable

宿主机側的防火墙同样可能拦截。特别是 NAT 模式下，虚拟机的流量要经过宿主机转发，宿主机上的安全软件如果对虚拟网卡做了限制，虚拟机就出不去。判断方法是在宿主机上临时关闭安全软件的网络防护，虚拟机里重试；通了这个锅就是安全软件的，去它的规则里把虚拟机相关网卡加进白名单。

还有一个和防火墙无关但常被误认成防火墙的问题：宿主机上开启了某些系统级的虚拟化功能，和虚拟机软件争抢底层虚拟化能力，导致虚拟网卡工作异常。这种问题的典型特征是虚拟机的网络时断时续、速度异常慢，或者虚拟机软件启动时就弹兼容性提示。处理办法是在系统功能里关掉与之冲突的那一项，重启宿主机。

5. 问题速查表与实操踩坑记录

排查这件事最怕的就是每次都从零开始想。我把这些年遇到的典型症状和对应的病因、处理动作整理成表，遇到问题先对号入座，能省掉大量试错时间。

5.1 现象与病因对照表

这张表覆盖了我经手过的绝大多数情况。对着表走，通常两三分钟就能定位到大方向，剩下的就是具体配置的微调。

5.2 几个我实际踩过的坑

第一个坑是改完 netplan 忘了看网卡名。有次在一台新装的机器上照着自己以前的笔记配静态地址，写完 apply，提示成功，网络依然不通。折腾了快二十分钟才想起来ip -br link看一眼，人家网卡叫ens160，我写的是ens33。netplan 对不存在的网卡不会报错，它只是默默跳过。

第二个坑是 YAML 里混进了 Tab。从网页上复制配置片段的时候，某些编辑器会把缩进转成 Tab，肉眼完全看不出来，netplan apply照样返回成功。后来我养成习惯，改完配置先跑netplan generate，它有语法错误会直接指出行号。再后来干脆用cat -A 文件名看一眼，Tab 会显示成^I，一眼就能发现。

第三个坑是宿主机换了 Wi-Fi 之后虚拟机没网。当时用的是桥接，宿主机从公司网络换到家里的网络，网段从10.x变成了192.168.x，虚拟机的静态地址还在老网段里，自然出不去。这个教训让我在需要经常移动的场景下一律用 NAT，DHCP 自动适配，省心。

第四个坑是虚拟机服务被“优化”掉了。某次用系统清理工具做了一次开机项精简，第二天虚拟机全线断网。查了半天才发现那两个虚拟机相关的后台服务被设成了手动启动。这件事之后我给自己定了个规矩：任何清理工具动系统服务之前先看一眼列表，把虚拟化相关的服务加进白名单。

第五个坑是同时开了两个虚拟化平台。有一台机器上装了两套不同的虚拟机软件，两套的虚拟网卡互相打架，路由表里一堆乱七八糟的记录。这种环境下的排错成本极高，建议一台机器只保留一套虚拟化软件，或者至少不要同时运行。

提醒：每次调通之后，立刻给虚拟机打一个快照。网络配置这玩意儿，改崩了回滚比修快得多，尤其是你在做一堆不确定的试验时。

6. 让配置不再反复失效的固化手段

折腾通了不算完，很多人过几天开机又断，回头一看是某个配置没持久化。这一章讲怎么把临时的修复变成永久生效的配置，以及怎么给自己留条后路。

6.1 把临时命令沉淀成配置文件

排查过程中用的ip addr add、ip route add、dhclient这类命令，全都是临时的，重启即失效。验证有效之后，必须把它们翻译成 netplan 里的字段。对应关系很直接：手动加的地址对应addresses，手动加的路由对应routes，手动指定的 DNS 对应nameservers。

沉淀完之后做一次完整验证：重启虚拟机，用同一套命令重新检查一遍网卡状态、IP、路由和解析。这一步不要省，很多人就是在这里翻车——临时命令生效了，配置文件写错了却没发现，重启之后又回到原点。

固化之后还可以做一层保险：在/etc/hosts里写几条常用的静态解析记录。这不是替代 DNS，而是在 DNS 出问题的时候保证最基本的访问能力，属于兜底手段。

6.2 快照、模板与恢复默认

我给自己的习惯是，一台虚拟机网络调通、环境配好之后，立刻打一个命名清晰的快照，比如“网络正常-基础环境”。后面不管装什么软件把网络搞坏了，回滚几分钟的事，比重新排查快得多。虚拟机软件的快照功能对磁盘占用不大，值得用起来。

如果你需要批量创建同配置的虚拟机，更好的做法是把调好的这台做成模板，从模板克隆。克隆出来的机器网络配置是完整的，只需要注意前面说的选“已复制”避免地址冲突。

最后是那个“还原默认设置”按钮。当虚拟网络被改得面目全非、自己都记不清改了哪些参数时，别硬修，直接还原。代价是自定义的端口映射会丢，但换来的是一个确定可用的干净起点，从干净的起点重新配，比在烂摊子上打补丁效率高得多。

我在实际使用中的体会是，虚拟机的网络问题九成以上不是“疑难杂症”，而是排查顺序错了。先确认模式选对没有，再看宿主机的虚拟网卡和服务在不在，然后看虚拟机里网卡认没认出来、地址拿没拿到，最后才是路由和 DNS。这个顺序反过来，就容易在一堆表象里打转。另外，养成改配置前先看一眼网卡名、改完先跑netplan generate的习惯，能挡掉大部分低级错误。真要说还有什么技巧，那就是善用快照——它不能帮你解决问题，但能让你在试错的时候毫无心理负担，而心理负担小的时候，人反而更容易找到问题在哪。