企业官网建设流程全解析

1. 先把"配网"这件事拆开看

Ubuntu 配网这个词，外行看着像"插上网线就完事"，实际上手过的人都知道，它至少包含四层意思：物理链路能不能通、网卡有没有被系统接管、IP 怎么拿到、DNS 和路由怎么走。我见过太多人卡在第三步却一直在第一步折腾网线，也见过不少人把 DNS 写错了，然后花一晚上怀疑是不是系统装了假的。这篇文章就是把这四层从头到尾捋一遍，把桌面版、服务器版、虚拟机、开发板这几类常见场景都覆盖到，你手上不管是刚装完的 Ubuntu 22.04 还是 24.04 LTS，都能照着往下走。

先明确一下适合谁看。第一种是刚把 Ubuntu 装进 VMware 或者 VirtualBox，发现 ping 不通外网、SSH 连不上的新手；第二种是在服务器上要配静态 IP、双网卡、多路由的运维同学；第三种是拿开发板、WSL 当日常开发环境，需要让系统稳定跑起 Docker、GCC、CMake 这类工具链的人。这三类人关注的点其实不太一样：新手最需要的是"先确认链路是不是活的"，老手最在意的是"配置怎么写才不会被系统自己改回去"。下面我会把这两种需求分开讲。

在动手之前先给一个基本认知：Ubuntu 的网络配置这几年变化挺大的。早期是/etc/network/interfaces一家独大，后来 NetworkManager 接管桌面，再后来 Netplan 变成了统一的抽象层，服务器版由它生成 systemd-networkd 的配置。所以你从网上抄到的一份 2016 年的教程，大概率在 24.04 上是跑不通的，不是教程错了，是这套东西已经被换过一轮了。搞清楚"当前这套系统用哪一层在管网络"，比记住某个具体命令重要得多。

1.1 三套网络管理工具，别让它们打架

Ubuntu 里同时存在好几个能改网络的东西，它们的关系不是"哪个更好用"，而是"谁在管这块网卡"。搞混了就会出现"我改了配置怎么不生效"这种情况。

关键点在于 Netplan 的renderer字段：写networkd就交给 systemd-networkd，写NetworkManager就交给 NetworkManager。桌面版默认的/etc/netplan/01-network-manager-all.yaml里写的就是 NetworkManager，所以你在桌面上用图形界面点一下就能生效；服务器版默认是 networkd，必须改 YAML。

注意：同一块网卡不要被两套工具同时声明。我踩过的坑是在桌面版服务器上装了 networkd 的配置，结果 NetworkManager 把网卡标成 unmanaged，两边都不干活，网卡亮着灯但就是没 IP。

1.2 上手第一件事：确认网卡到底叫什么

这一步看起来废话，实际能省掉后面一大半时间。Ubuntu 从 16.04 开始默认用可预测网卡名，eth0变成了ens33、enp3s0、eno1这类名字，虚拟机里常见的是ens33或ens160，无线网卡是wlp2s0这种格式。命名规则大概是：en开头是有线，wl开头是无线，后面跟的是 PCI 总线位置。

ip -br link show # 简洁列出所有网卡和状态 ip -br addr show # 额外显示 IP lspci -k | grep -A 3 -i net # 看网卡的 PCI 信息和正在用的驱动 lshw -C network # 更详细的硬件信息，需要 sudo

ip -br link的输出里如果状态是DOWN，说明链路层没起来，可能是网线没插好、虚拟机网络适配器没连上、或者驱动没加载。如果是UP但没有 IP，那就是配置层面的问题了，往后看第三节。USB 网卡的话用lsusb看有没有被识别，插上后dmesg | tail -20一般能看到内核给它分配的名字。

1.3 四种场景，先想清楚你要哪一种

很多人配网配得痛苦，是因为一开始没想清楚自己到底要什么。实际上无非四种情况：

• 动态 IP（DHCP）：路由器给什么用什么，适合家用、临时虚拟机、随手测试。
• 静态 IP：自己指定地址，适合服务器、需要被别人稳定访问的机器、开发板。
• 双网卡分工：一块对内一块对外，或者一块跑管理流量一块跑业务流量。
• 无线连接：笔记本、树莓派这类没有网口的设备。

选错了场景，后面所有命令都白搭。比如你在家里用桥接模式给虚拟机配了个静态 IP，结果路由器 DHCP 池和这个地址撞了，就会出现时通时不通的玄学问题。判断标准很简单：这台机器需不需要被局域网里其他设备主动访问？需要就静态，不需要就 DHCP。

2. 桌面版 Ubuntu 配网实操

桌面版是最省心的，因为 NetworkManager 给了图形界面和 nmcli 两套入口，改完立刻生效，不用重启网络服务。但省心不代表没坑，尤其是当你从图形界面切到命令行的时候，容易把已有的连接配置搞乱。

2.1 图形界面配置：三分钟搞定的标准流程

点右上角网络图标，进"设置"，找到"网络"这一栏。有线连接下会显示当前的连接名，比如"有线连接 1"，点齿轮图标进入详情页，切到 IPv4 标签页。这里有四个选项：

• 自动 (DHCP)：默认，路由器分配。
• 手动：静态 IP，下面填写地址、子网掩码、网关。
• 仅本地链接：只做二层通信，不配 IP。
• 共享到其他计算机：把本机当网关，给别的设备做网络共享。

选手动之后，地址格式要写成192.168.1.50/24这种带掩码位数的形式，只写 IP 不写/24会报错。DNS 那一栏要手动填，比如223.5.5.5,119.29.29.29，逗号分隔。填完点应用，图标上的小问号消失就说明通了。

注意：图形界面里如果不小心把"自动"关掉了却没填网关，会出现"能 ping 通同网段设备但上不了网"的经典症状，本质是缺默认路由。这个时候别急着怀疑 DNS，先ip route看一眼有没有default via。

2.2 nmcli：真正好用的其实是命令行

图形界面适合一次性配置，但要批量改、脚本化改、远程改，还是 nmcli 靠谱。它的逻辑是"连接（connection）"和"设备（device）"分开管理，一个设备上可以挂多个连接配置，按优先级自动切换。这个设计刚接触会觉得绕，习惯了就知道很方便，比如笔记本换到不同办公室可以预存多套 WiFi 配置。

先看现状：

nmcli device status # 设备和当前连接状态 nmcli connection show # 所有连接配置 nmcli connection show "有线连接 1" # 看某个配置的所有细节

配一个静态 IP 的完整流程：

# 1. 先改配置（此时不生效） sudo nmcli connection modify "有线连接 1" \ ipv4.method manual \ ipv4.addresses 192.168.1.50/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5 119.29.29.29" # 2. 再重新激活让它生效 sudo nmcli connection up "有线连接 1" # 3. 验证 ip -br addr show ip route

注意这里ipv4.dns的值是空格分隔的字符串，写在引号里；而ipv4.addresses在较新版本里支持逗号分隔多个地址。nmcli connection modify是改配置文件，不会立即生效，必须up一次，这个"改和生效分离"的机制经常把人绕进去。

如果想退回去用 DHCP：

sudo nmcli connection modify "有线连接 1" ipv4.method auto ipv4.gateway "" ipv4.addresses "" ipv4.dns "" sudo nmcli connection up "有线连接 1"

这里把其他字段清空是好习惯。NetworkManager 在method auto时会忽略静态字段，但有些版本会在两个配置之间反复横跳，清干净最稳。

# 新建一个连接配置（不动原来的） sudo nmcli connection add type ethernet con-name "static-ens33" ifname ens33 \ ipv4.method manual \ ipv4.addresses 192.168.1.60/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5" # 删除某个连接配置 sudo nmcli connection delete "static-ens33"

2.3 WiFi 连接与射频开关那些事

无线网卡的问题比有线多一层：射频开关。rfkill list能看到每个无线设备的软阻塞（software blocked）和硬阻塞（hard blocked）。硬阻塞一般是笔记本上的物理开关或者 Fn 组合键，软阻塞可以用rfkill unblock wifi解除。

rfkill list nmcli device wifi list # 扫描周边 WiFi sudo nmcli device wifi connect "SSID名称" password "密码" nmcli connection show --active

笔记本上有个很常见的坑：有线连上后 WiFi 会自动断开，这是 NetworkManager 的"单连接策略"在起作用。要两个都留着，得把连接配置的connection.autoconnect-priority和connection.secondary改一下，把 WiFi 设成ipv4.may-fail yes的辅助连接。这个配置在写多网卡分流脚本时很有用，但普通人一般遇不到。

2.4 DNS 缓存和 resolv.conf 的真实关系

Ubuntu 18.04 以后用 systemd-resolved 做 DNS 缓存和转发，/etc/resolv.conf实际上是一个软链接，指向/run/systemd/resolve/stub-resolv.conf，里面只写了一个127.0.0.53，真正的 DNS 服务器地址在别处。很多人vi /etc/resolv.conf改了半天发现重启就丢，原因就在这里。

ls -l /etc/resolv.conf # 看它指向哪里 resolvectl status # 看每块网卡实际用的 DNS resolvectl query example.com # 用 systemd-resolved 查一次

如果确实需要手写 resolv.conf（比如某些容器环境），先把它从软链接改成真实文件：

sudo rm /etc/resolv.conf sudo tee /etc/resolv.conf <<'EOF' nameserver 223.5.5.5 nameserver 119.29.29.29 EOF

注意：这么做会绕过 systemd-resolved 的缓存，长期看反而更容易出问题。我的建议是优先在 NetworkManager 或 Netplan 里配 DNS，让系统自己维护 resolv.conf，不要直接改文件。

3. 服务器版 Ubuntu 配网：Netplan 是主角

Server 版没有图形界面，默认用 Netplan 加 systemd-networkd。配置文件放在/etc/netplan/下，文件名一般长这样：00-installer-config.yaml（手动装的）、50-cloud-init.yaml（云主机自动生成的）、01-netcfg.yaml（老一点的版本）。多个文件会按文件名排序合并，后面的覆盖前面的，所以改配置的时候先ls一下，别只看一个文件就下手。

3.1 一份能直接用的静态 IP 配置

YAML 的缩进是硬要求，必须用空格，不能用 Tab，缩进错了netplan apply会直接报错。下面这份是我在 22.04 和 24.04 上都在用的模板：

network: version: 2 renderer: networkd ethernets: ens33: dhcp4: false dhcp6: false addresses: - 192.168.1.50/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [223.5.5.5, 119.29.29.29] search: [local]

24.04 之前的教程里常见gateway4: 192.168.1.1这种写法，从 22.04 开始它被标记为废弃了，虽然还能用，但会打警告。现在统一用routes里的to: default，好处是能写多条路由，方便做策略路由或者多网卡分流。

应用配置的标准动作是三步：

sudo chmod 600 /etc/netplan/*.yaml # 权限不对会报警告 sudo netplan generate # 只生成后端配置，不生效 sudo netplan try # 试运行，120 秒内不确认自动回滚 sudo netplan apply # 真正生效

netplan try这个命令值得单独说一句：它会临时应用配置，然后等你按回车确认，如果 120 秒内没确认（比如你把自己 SSH 搞断了），会自动回滚到之前的状态。远程改网络配置的时候，一定要用try而不是直接apply，这是保命操作。我第一次在云主机上改静态 IP 就是直接apply，然后和机器失联了二十分钟，最后靠控制台救回来。

3.2 网卡名不固定怎么办：match 加 set-name

虚拟机克隆、云主机重建、换硬件，都可能让网卡名变化，写死了ens33就失效了。Netplan 提供了匹配的写法：

network: version: 2 renderer: networkd ethernets: lan: match: macaddress: "00:0c:29:aa:bb:cc" set-name: lan0 dhcp4: true

这样配置就跟着 MAC 地址走，不管内核给它起什么名字，最后都会被统一命名成lan0。多网卡服务器上这个技巧特别实用，配置文件读起来清楚得多，脚本里也不用改来改去。

3.3 双网卡与多默认路由：metric 决定谁优先

服务器上经常是两块网卡，一块接内网一块接外网，或者一块管理一块业务。如果两块网卡都有默认网关，系统就懵了，到底从哪块出去？解决办法是给路由加 metric，数值小的优先。

network: version: 2 ethernets: ens33: dhcp4: true dhcp4-overrides: route-metric: 100 ens34: addresses: [10.0.0.10/24] routes: - to: 10.10.0.0/16 via: 10.0.0.1 metric: 200

这里ens33走默认路由，metric 100；ens34只负责10.10.0.0/16这个网段，且不设默认网关。这是最干净的写法：只有一块网卡有默认路由，另一块只写明细路由。比两块都写默认路由再靠 metric 抢，要可靠得多。

3.4 云主机上的"改了不生效"问题

云主机（各家都类似）第一次启动时，cloud-init 会根据元数据生成一份 netplan 配置，通常叫50-cloud-init.yaml。你手改之后重启，发现配置被覆盖回去了，这就是 cloud-init 在干活。

标准做法是禁掉它的网络管理：

sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg <<'EOF' network: {config: disabled} EOF

然后再去改自己的 netplan 文件。另外要注意，云主机的静态 IP 通常不能随便改，很多平台是靠 DHCP 下发固定地址的，你硬配一个别的地址可能直接失联。要改的话一般走控制台改弹性地址，而不是改系统里的配置文件。

4. 虚拟机与开发板场景的配网

前面两节讲的是通用逻辑，这一节说说几个高频场景，因为大部分人第一次接触 Ubuntu 配网都是在虚拟机里。

4.1 桥接、NAT、仅主机三种模式怎么选

三种模式的差别，用一句话概括就是"虚拟机在不在你的局域网里"。

桥接模式下最容易出的问题是"IP 拿到了但上不了网"，通常是宿主机所在网络有 MAC 地址限制、或者公司网络对陌生设备做了准入。NAT 模式则相反，能上网但 SSH 连不进去，需要做端口转发。VMware 里在"编辑 - 虚拟网络编辑器"里配置 NAT 设置；VirtualBox 里在网卡高级选项里点"端口转发"。

# 在虚拟机里确认自己是不是 NAT ip route # 看到 192.168.x.0/24 且网关是 .1，多半是 NAT ip -br addr show # 地址落在 10.0.2.x 段则基本可以确定是 NAT 模式

4.2 虚拟机装完黑屏只有两个小图标：先别慌

有人在虚拟机里装 Ubuntu 时遇到黑屏，屏幕下方只有两个小图标转圈，第一反应是镜像坏了。实际上大概率是显卡和显示服务不兼容，属于显示层面的问题，跟配网没关系。处理办法是先等两三分钟，如果确实卡死，就在启动时按 Esc 进 GRUB，在内核参数后面加nomodeset，先进到系统再装合适的显卡驱动。装完之后网络配置照常做，不受影响。

注意：虚拟机里配静态 IP 时，一定要先确认宿主机的虚拟网卡网段。VMware 默认 NAT 网段是192.168.x.0/24里的一段，VirtualBox 默认是10.0.2.0/24，如果你在虚拟机里配的地址不在这两个网段里，直接就不通，跟写错网关是两回事。

4.3 WSL 里的网络是另一套逻辑

WSL2 本质上是一台轻量虚拟机，网络默认是 NAT，每次重启后 IP 都可能变。所以在 WSL 里配静态 IP 意义不大，真正该做的是把服务监听地址设成0.0.0.0，然后在 Windows 侧用端口转发或者防火墙规则放行。

最近几个版本的 WSL 支持"镜像网络模式"，在用户目录下的.wslconfig里加一行：

[wsl2] networkingMode=mirrored

开了之后 WSL 会和 Windows 共享网络接口，不再有独立的虚拟网卡，localhost直接互通，访问局域网设备也顺了。这个改动对开发体验提升挺大，尤其是以前老是要去查 WSL 当前 IP 的人。不过它对 Windows 版本有要求，太老的版本不支持，改之前先确认一下自己的版本。

4.4 开发板通过串口挂载：网络共享的正确姿势

拿开发板做 Zephyr 或者其他嵌入式开发的同学，经常需要让开发板在没接网线的情况下联网，做法是把 PC 的网络共享给开发板。PC 上的 USB 转串口芯片（常见的 CH340、CP2102）Ubuntu 内核自带驱动，插上后dmesg | grep -i ch34能看到识别日志，串口设备是/dev/ttyUSB0。

用 picocom 或者 minicom 连上去：

sudo apt install picocom sudo picocom -b 115200 /dev/ttyUSB0 # 退出是 Ctrl+A 然后 Ctrl+X

串口通了之后，在开发板系统里配网，网关指向 PC 的局域网地址就行。如果 PC 上用的是 NetworkManager，还能用"共享到其他计算机"这个选项，它会自动在 PC 上起一个内部网段并把这块网卡设成网关，开发板从它拿 DHCP 地址，省事不少。前提是开发板得有线口或者 USB 网卡。

5. 连不上网时的排查顺序

前面聊的都是"怎么配"，这一节聊"配完不通怎么办"。我给的建议是：严格按层排查，别跳步。链路层、网络层、传输层、应用层，一层一层看，比东试西试快得多。

5.1 第一步永远是看链路和地址

ip -br link # DOWN 就是链路问题，去查网线/虚拟机设置/驱动 ip -br addr # 没有 IP 就是配置或 DHCP 问题 ping -c 3 192.168.1.1 # 网关通不通，这一步验证二层和三层 ping -c 3 223.5.5.5 # 直接 ping 公网 IP，验证路由和出口 ping -c 3 example.com # 域名能解析说明 DNS 正常

这四步的结果组合能直接定位问题：

• 链路 DOWN：物理层，跟配置无关。
• 有 IP，网关不通：子网掩码或网段错了，或者交换机 VLAN 隔离。
• 网关通，公网 IP 不通：缺默认路由，或者宿主机 NAT 没开。
• 公网 IP 通，域名不通：DNS 配置问题，去查 resolv.conf 或者 resolvectl。

这个判断逻辑看起来简单，但我见过太多人一上来就 ping 域名，不通就以为没网，实际上只是 DNS 没配。分层排查能把范围一下子收窄。

5.2 SSH 连不上的完整排查链条

SSH 连不上是高频问题，排查顺序我一般是这样：

systemctl status ssh # 服务在不在跑 ss -tlnp | grep :22 # 有没有监听 22 端口，监听的是 0.0.0.0 还是 127.0.0.1 sudo ufw status # 防火墙有没有拦 ip -br addr show # 是不是 IP 变了，DHCP 租约到期很常见

四个点里最容易忽略的是第三个。Ubuntu 桌面版默认不装 ufw 或者装了但没开，Server 版有些镜像会默认开启。开了之后如果不放行 22 端口，外面是永远连不上的，而且本机测试ssh localhost还是通的，特别容易误导人。

还有一种情况是监听地址绑在了127.0.0.1，外部连不上。这个是sshd_config里ListenAddress被改过，改回0.0.0.0或者直接注释掉即可。改完记得sudo systemctl restart ssh。

如果只在局域网内连不上，但同一个网段的其他机器能连通它，那问题多半在对端：客户端所在网段和服务器之间被路由器隔离了，或者服务器上有 iptables 规则。云主机的话还要看安全组，这个经常被忘，明明系统里所有配置都对，就是连不上，最后发现是控制台的安全组没放行 22 端口。

5.3 常见问题速查表

5.4 几个只有踩过才知道的细节

说几个文档里不太会写、但实际会遇到的点。

第一个是netplan apply之后网络会有短暂中断，如果此时你正在用 SSH，连接会卡一下但一般不会断，因为 Netplan 是先配置新地址再摘旧地址。但如果你把网卡名改错了，那就真的断了，所以还是推荐netplan try。

第二个是虚拟机快照。很多人配好网之后拍了个快照，后面恢复快照发现网络又坏了。原因通常是快照恢复后 MAC 地址变了，而你的 netplan 里写死了网卡名或者 MAC。要么改用 DHCP，要么确认虚拟机设置里"保留 MAC 地址"是勾上的。

第三个是时间同步。看起来跟配网无关，但系统时间偏差太大时，某些基于时间的认证会失败，表现出来像是"网络不通"。装完系统先timedatectl status看一眼时间对不对，顺手sudo timedatectl set-ntp true打开自动同步，能省掉不少莫名其妙的麻烦。

第四个是软件源。刚装完的系统如果连不上外网，apt 装什么都失败，看起来像是网络全坏了。实际上先ping一下源地址，如果通就只是源站问题，换一个源或者等一会儿再试就行，别急着回滚网络配置。反过来说，如果确实需要在没有外网的环境下装东西，提前把 deb 包下好拷进去，用dpkg -i装，比在现场折腾网络靠谱。

我自己这几年的习惯是：任何一次网络配置改动之前，先ip -br addr show > /tmp/net-before.txt和ip route >> /tmp/net-before.txt存一份。改完之后如果不对，照着这份记录手动退回去。这个习惯救了我不止一次，尤其是那些隔了一层虚拟化、隔了一层云平台的机器，你永远不知道中间哪一层在悄悄改你的配置。

还有一个建议是给服务器配完静态 IP 之后，把配置文件和当时的输出日志一起记到自己的笔记里。半年后机器出问题，你翻笔记比翻系统快得多，因为netplan生成的运行态配置在/run/systemd/network/下面，机器重启后是空的，想回溯都回溯不了。配网这事，本身就是个"做好记录比技术强"的活。