企业官网建设流程全解析

先说一个我自己踩过几次的坑：很多人照着网上早年的Ubuntu教程去配置静态IP，改完/etc/network/interfaces，然后重启网络服务，结果发现配置完全没生效，或者干脆SSH直接断掉，连不上机器。这不是你操作失误，而是Ubuntu从18.04开始，底层网络配置工具已经从ifupdown切换成了netplan。你还在用上一代语法，系统根本不认。

这篇文章就把Ubuntu 18.04、20.04、22.04这几代系统里配置静态IP的方法完整梳理一遍。核心会放在netplan上，因为它是目前Ubuntu Server和Desktop默认使用的配置栈；同时也会讲nmcli命令行方式、传统interfaces文件的适用场景、虚拟机环境下的特殊问题，以及配置完之后的验证和自救手段。无论你是刚接触Linux的新手，还是要给服务器或虚拟机换固定IP的老手，这篇应该都能帮上忙。

1. 为什么Ubuntu 18.04之后，静态IP配置突然变难了

1.1 从ifupdown到netplan的配置栈变迁

Ubuntu 18.04 LTS发布时做了一个影响深远的改动：用netplan替换ifupdown作为默认的网络配置前端。netplan本身不直接管理网络，它只是一个配置渲染器，把你写好的YAML配置转化成后端程序能识别的规则，然后交给systemd-networkd或NetworkManager去执行。

这个设计改变了配置入口。以前你只需要编辑/etc/network/interfaces，然后运行ifup或者systemctl restart networking，配置就生效了。现在你需要在/etc/netplan/目录下维护YAML文件，然后执行netplan apply让配置生效。注意，/etc/network/interfaces文件在18.04以上版本里默认还在，但已经被边缘化，你改它基本不会影响系统实际网络。

很多人配置失败，根本原因就是不知道这个变化。尤其是从14.04、16.04时代迁移过来的老用户，惯性思维太重。网上一搜关键词，搜出一堆老文章，照着操作当然配不通。

1.2 先确认你的系统走的是哪套网络栈

拿到一台Ubuntu机器，先别急着改配置。你得先判断当前系统实际由谁管理网络。我一般用一个命令：

ls /etc/netplan/

如果这个目录存在，并且里面有.yaml文件，说明系统默认走netplan。这个目录在18.04、20.04、22.04里都是标配。

再看一眼NetworkManager的接管状态：

systemctl status systemd-networkd systemctl status NetworkManager

如果是桌面版Ubuntu，NetworkManager大概率在运行；如果是Server版，systemd-networkd可能是主力，或者两者交替使用。netplan通过YAML里的renderer:字段决定把配置交给谁。默认情况下，Server版通常使用networkd作为renderer，桌面版使用NetworkManager。

还有一个很容易忽略的判断点：执行ip addr看网卡状态信息，和你在修改前抓到的IP对不对得上。如果IP地址是由NetworkManager拉的DHCP，你去改netplan文件但renderer还是NetworkManager，就会发生配置不生效的诡异现象。下文会具体讲。

总之，先确认配置栈，再动手。这一步省掉，后面全是坑。

2. 配置静态IP前，必须先想清楚的三个参数

2.1 网卡接口名：ens33、enp0s3还是eth0？

很多教程第一步就让你把eth0改成静态IP，但你实际机器上可能根本没有eth0这个接口。Ubuntu 18.04以上使用systemd的链路命名规则，网卡名取决于硬件拓扑和固件信息，常见的有这些：

• ens33：PCIe总线上的网卡，常见于VMware虚拟机。
• enp0s3：PCI总线0插槽3上的网卡，常见于VirtualBox虚拟机。
• eno1：板载网卡。
• enp2s0：PCIe扩展槽网卡。
• wlan0或类似的wl...开头：无线网卡。

查看当前系统里有哪些网卡，用：

ip addr show

或

ip link

你会看到类似2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP>这样的输出。第一列的数字是接口索引，冒号前的ens33就是接口名。后面的状态里，UP代表已启用，DOWN代表未启用。

如果你配置的时候写错接口名，比如把ens33写成eth0，netplan apply不会报错，但它只会把配置应用到一个不存在的接口上，你现有的网络完全不动。这种“无声失败”是最坑的。

2.2 网关地址：怎么查、怎么选

网关错了，或者漏写了，最常见的表现是：内网能通，外网不通。因为跨网段的数据包不知道该发给谁。

查看当前网关的快捷方式：

ip route show

输出里，default via 192.168.1.1 dev ens33就是默认网关。192.168.1.1就是当前DHCP分配给你的网关地址。如果你要配置静态IP，正常情况下网关就沿用这个地址，除非你所在的网络规划里静态IP段的网关确实不是它。

需要注意，DHCP获取的网关不一定等于真正的路由器地址。有些复杂网络里，网关可能是内网里某台三层交换机或防火墙的接口地址。你直接沿用ip route显示的地址通常没问题，但如果你发现持续丢包或延迟异常，检查一下网关MAC地址是不是和路由器对得上。

在虚拟机环境下，网关的选择更要谨慎。NAT模式下，VMware的虚拟网关通常是192.168.x.1，VirtualBox的NAT网关通常是10.0.2.2。桥接模式下，网关则是你物理路由器的IP。这个区别要记清楚，不然虚拟机配了静态IP依然上不了网。

2.3 DNS配置：静态IP后域名解析不通的根源

静态IP配置里，DNS是仅次于网关的第二大翻车点。很多人配完静态IP，IP地址确实固定了，但用浏览器打开网页一直转圈，ping 8.8.8.8能通，ping baidu.com却报未知主机名。这基本就是DNS没配好。

查看当前DNS信息可以用：

resolvectl status

或者看/etc/resolv.conf的内容。不过在Ubuntu 18.04以上，这个文件通常是指向/run/systemd/resolve/stub-resolv.conf的软链接，内容是127.0.0.53。不要被这个地址吓到，这是systemd-resolved的本地缓存地址，最终上游DNS还是来自netplan或NetworkManager下发的配置。

配置静态IP时，我建议至少填两个DNS地址，一个主一个备。国内网络环境就用223.5.5.5和119.29.29.29，或者114.114.114.114；国外服务器可以用8.8.8.8和1.1.1.1。具体看你的使用场景，目标是保证一个挂了还能有备用。

3. netplan配置静态IP全过程，含最容易翻车的细节

3.1 找配置文件：/etc/netplan下到底是什么

在Ubuntu 18.04及以上版本里，进入/etc/netplan/，通常能看到一个或多个文件：

• 01-network-manager-all.yaml：桌面版常见。
• 50-cloud-init.yaml：云镜像或自动安装版常见。
• 99_config.yaml：你自己新建的配置文件。

命名规则是数字前缀+名称+.yaml。netplan会按字典序读取这些文件，后面文件里的同类配置会覆盖前面的。这个特性可以拿来用：不直接动默认文件，而是新建一个名称排序靠后的文件，把静态IP配置写进去，优先级更高，还能保留原始配置做参考。

先看下默认文件内容，比如50-cloud-init.yaml通常长这样：

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

这就清楚了：网卡ens33当前由DHCP获取IPv4地址。

3.2 手把手编辑YAML

修改或新建netplan配置文件，推荐用vim或nano。我习惯先备份再改：

sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak

然后编辑，改成：

network: version: 2 ethernets: ens33: dhcp4: no dhcp6: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 119.29.29.29

逐项说明：

• dhcp4: no：关闭IPv4的DHCP，这个是静态IP的第一步。不关掉的话，DHCP可能继续覆盖你的静态配置。
• addresses:：接口IP地址和子网前缀长度。/24就是子网掩码255.255.255.0的CIDR写法。写的时候必须带前缀长度，不能只写IP地址。地址使用列表格式，可以写多个IP，比如同时配IPv4和IPv6。
• routes:：路由表配置。to: default表示默认路由，via:后面跟网关地址。
• nameservers:：DNS服务器列表。注意缩进，addresses:是nameservers:的子项。

很多新手卡在YAML格式过不了：netplan generate报错。最常见的原因是用了Tab缩进。YAML对缩进敏感，而且netplan的配置明确要求使用空格，不能用Tab。编辑器设置里把Tab自动替换成两个空格，或者干脆手工用空格缩进。

3.3 应用配置：netplan apply和netplan try的区别

配置写好后，先运行：

sudo netplan generate

这个命令只做语法检查和生成后端配置文件，不改动当前网络。如果这里报错，先修格式问题，别急着apply。

确认无报错后：

sudo netplan apply

这个命令会真正应用配置。但我强烈建议使用另一个更安全的命令：

sudo netplan try

netplan try会自动应用配置，然后等待你确认。如果配置有问题导致网络断开，系统会在等待超时后自动回滚到之前的可用配置。这相当于给自己留了一条退路。执行后终端会提示“Do you want to keep these settings?”，按回车确认保留，超时则自动恢复。

如果是远程SSH操作，我特别建议用netplan try，因为你配置错了导致断网时，netplan apply可不会自动帮你恢复。你只能跑到物理控制台或者用IPMI硬恢复，非常狼狈。而netplan try在等待期间如果检测到连接中断，你直接不理会，超时后它自己就回滚回去了。

3.4 配置后SSH断连、无法上线的自救方法

远程服务器配置静态IP，最经典的翻车现场就是：apply之后SSH直接断开，再也连不上，只能让机房重启或者本人去现场。

避免这种现场的最好办法，有几个原则：

1. 用netplan try而不是netplan apply。这是第一道保险。
2. 别改默认路由和当前SSH连接所在的IP段。如果你SSH用的IP是192.168.1.10，现在要把IP改成192.168.1.100，改的时候要确认192.168.1.100不在其他设备上占用，而且你改完后要马上用新IP去连。
3. 保留一个临时救急配置。有些老手会在服务器上额外写一个备用网络配置，比如在/etc/netplan/里放一个带DHCP的备用文件，需要时通过物理控制台切换。这个做法比较高级，不推荐新手一上来就搞，但心里要知道有这条退路。

如果已经断连，而且你人在控制台前，操作顺序是：

sudo netplan try

不行的话，直接恢复备份：

sudo cp /etc/netplan/50-cloud-init.yaml.bak /etc/netplan/50-cloud-init.yaml sudo netplan apply

再检查一下ip addr，确认网络回来没有。整个过程不需要重启系统。很多人习惯配完网络就重启机器，其实没必要，netplan apply足够。

4. 不想碰YAML？用nmcli和传统interfaces补齐方案

4.1 nmcli命令行配置静态IP

如果你觉得YAML格式容易出错，或者你更喜欢命令行操作，可以用nmcli。它是NetworkManager的命令行工具。前提是你的系统装了NetworkManager并且相关接口由它管理。

查看当前连接名：

nmcli connection show

输出类似：

NAME UUID TYPE DEVICE Wired connection 1 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet ens33

NAME那列的Wired connection 1就是连接名，注意空格，命令里要加引号。

然后修改连接：

sudo nmcli connection modify "Wired connection 1" \ ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5 119.29.29.29"

这条命令把连接改为手动（manual）模式，设置静态地址、网关和DNS。执行后重启连接：

sudo nmcli connection down "Wired connection 1" sudo nmcli connection up "Wired connection 1"

nmcli对新手更友好，因为它有补全提示，而且语法比较直白。缺点是它只管理NetworkManager范围内的连接，如果你的服务器用的是systemd-networkd纯后端，nmcli可能无法真正接管。

顺带说一句：有些方法在网上流传是把/etc/network/interfaces文件改回auto eth0、iface eth0 inet static这类写法，这是针对旧版Ubuntu或者改用了ifupdown的系统。手工安装ifupdown包并切换也是可以的，但如果你不想折腾底层服务，还是老实用netplan或nmcli。

4.2 什么时候你会需要回到/etc/network/interfaces写法

有一类特殊场景需要传统写法：你在跑一个精简版Ubuntu，或者一个从旧版本滚动升级上来的系统，netplan没装或者没接管所有网卡；再比如你在做系统裁剪，希望最小化依赖，不想引入systemd-networkd。这种情况下，可以手动启用ifupdown：

sudo apt update sudo apt install ifupdown

然后在/etc/network/interfaces里写：

auto ens33 iface ens33 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 223.5.5.5 119.29.29.29

注意，dns-nameservers依赖resolvconf包。如果没装，这行配置不会生效，你需要手动处理/etc/resolv.conf。

启用配置：

sudo systemctl enable networking sudo systemctl restart networking

但我要明确说，除非你确实在维护一个比较特殊的系统，否则不建议走这条路。netplan在18.04以上版本里已经非常稳定，没必要逆着系统默认设计去折腾。

5. 虚拟机里配静态IP和物理机有什么本质区别

5.1 NAT、桥接、仅主机模式对IP规划的影响

虚拟机上配静态IP比物理机多一层变量：虚拟网卡的工作模式。VMware和VirtualBox都提供了几种常见的虚拟网络模式，不同模式下，你的静态IP地址段、网关、DNS策略完全不同。

• NAT模式：虚拟机通过宿主机访问外部网络。虚拟机的流量经过宿主机转发出NAT，外部设备无法主动访问虚拟机。VMware下默认网关通常是192.168.x.1，VirtualBox下通常是10.0.2.2。在NAT模式下，静态IP必须配置在虚拟网卡的网段内，网关必须是虚拟网卡提供的网关，不能随手填一个。
• 桥接模式：虚拟机直接接入物理局域网，和宿主机在同一网段，拥有独立IP。这是最接近物理机的模式。静态IP就按你局域网的真实规划填，网关和DNS都是真实路由器的。这种模式下，如果局域网开启了DHCP，你要注意避免IP冲突；如果局域网没有DHCP，桥接模式下虚拟机可能完全无法自动获取IP，这也是很多新手在宾馆、公司网络里配不通虚拟机的关键原因。
• 仅主机模式：虚拟机和宿主机之间有一个私有网络，虚拟机无法直接访问外部网络。这种模式一般用来做本地实验，静态IP填在仅主机网卡的私有网段里即可。

5.2 VMware/VirtualBox常见静态IP问题

在虚拟机上配静态IP，真实踩坑频率最高的几个问题，我列一下：

网卡类型导致接口名不固定。VMware里把网卡类型从e1000换成vmxnet3，或者VirtualBox里改网卡类型，接口名可能从ens33变成enp0s3之类。你原来的netplan配置里写死了接口名，改完网卡类型后配置对不上，网络就废了。虚拟机硬件变动前，记得先看ip link确认接口名。

主机快照回滚导致配置丢失。很多人给虚拟机做完快照才去折腾网络，配完静态IP后测试不通，直接回滚快照，结果网络配置也跟着回滚了。这倒不是配置问题，是操作习惯问题。建议配静态IP前先确认系统里没有未保存的快照状态，配完确认稳定后再打新快照。

复制虚拟机导致MAC地址和连接绑定异常。在VMware里克隆虚拟机时，如果选择“复制物理网络地址”，两台机器用同一个MAC地址，接入同一网络会冲突，网络时通时断。克隆后建议重新生成MAC地址，然后用ip link确认接口名，再检查netplan配置。

专用工具的坑。标题里提到的vm kylin v11 静态ip能上网这类场景，本质上还是需要正确处理网关和DNS链路。我之前使用银河麒麟和统信UOS这类基于Ubuntu衍生的系统时，遇到不少情况是系统自带的网络管理工具把配置写进了它自己的配置文件里，然后netplan没接管，导致配置完成但网络不通。遇到这种衍生系统，先检查/etc/netplan/是否存在，以及系统systemctl status NetworkManager里的状态，不要盲目套用主版本Ubuntu的步骤。

6. 验证、回滚与故障排查顺序

6.1 检查网络生效的完整命令链路

配置应用之后，不能只看一眼IP就完事。我按顺序操作：

ip addr show ens33

确认接口上的IP是否为指定的静态地址。同时看状态，state UP才是正常。如果发现接口状态是DOWN，说明接口被手动关了或者驱动没加载。

ip route show

确认默认路由存在，default via 192.168.1.1 dev ens33这一行不能少。少了说明网关配置没生效。

ping 192.168.1.1

先ping网关，这一步通了，说明二层链路和IP设置基本OK。不通的话，检查IP和子网掩码，以及网线、交换机端口这些物理层。

ping 223.5.5.5

这一步通，说明出网的路由链路没问题。如果上一步通而这一步不通，问题出在网关和公网之间的路由，或者防火墙配置。

ping baidu.com

这一步通，说明DNS解析和域名访问都正常。到这一步才算是真正的配置成功。

还有一条容易被忽略的检查：

systemctl status systemd-networkd

如果你用netplan+networkd，这个服务状态要确认是active。如果服务没起来，配置再对也没用。顺手看一眼journalctl -u systemd-networkd的日志，有报错信息就直接对症排查。

6.2 网络不通时，按什么顺序排查

网络出问题的时候，切忌乱试。我一般按这个顺序排查：

1. 检查接口状态和IP：ip addr。如果接口是DOWN，先ip link set ens33 up把它拉起来，再确认IP是否还在。
2. 检查路由表：ip route。缺默认路由是外网不通的常见原因。出现多条默认路由时也要注意，可能互相打架。
3. 检查物理链路：在虚拟化环境里，看虚拟交换机、物理交换机端口状态；在物理机上检查网线、光模块。
4. 检查防火墙：Ubuntu默认装了ufw。sudo ufw status看看是不是挡住了出站或入站流量。很多“配好了但连不上”的问题，其实是别人的防火墙或你的防火墙在起作用。
5. 检查DNS链路：resolvectl status和cat /etc/resolv.conf。确认DNS配置确实生效，而不是停留在默认生成的本地回环地址。
6. 检查ARP表：ip neigh。如果网关的ARP条目显示FAILED或INCOMPLETE，说明二层都到不了网关。这个步骤在看“虚拟机里ping不通物理机”这类问题尤其好用。

每一步都确认无误，再往上层查。用排除法把问题缩小到一个环节，是最快的手段。

6.3 被cloud-init覆盖配置的情况

最后一个平时很容易踩中的坑：cloud-init。

Ubuntu官方云镜像、或者你用自动安装镜像装出来的Ubuntu，默认会在启动时通过cloud-init配置网络。cloud-init会在启动早期读取/etc/netplan/里的50-cloud-init.yaml，并可能修改它。这意味着，你在系统运行中手动改了50-cloud-init.yaml，重启后配置可能被覆盖回原来的DHCP模式。

解决办法有两个路径：

路径一是直接停用cloud-init对网络的接管：

sudo touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

写入一行配置：

network: {config: disabled}

然后清理cloud-init已生成的状态：

sudo cloud-init clean --logs

再重启，或者至少重启netplan：

sudo netplan apply

路径二是手动编辑50-cloud-init.yaml后，同时禁用cloud-init的配置覆盖。我实际使用中推荐直接禁用cloud-init对网络的管理，因为你要配置静态IP，说明网络是固定的，没必要让cloud-init每次启动动态生成。

另外提醒一句：在阿里云、腾讯云这类云平台上，如果你的Ubuntu镜像是云市场版，网络配置通常由云平台的agent和cloud-init合作管理。手动改netplan虽然能生效，但可能会和云平台的网络配置机制冲突。这类环境我建议使用云平台控制台的弹性网卡IP管理功能，而不是下到系统里去改netplan文件。

说回标题这件事。Ubuntu 18.04以上配置静态IP，核心就一句话：找对配置文件，写对YAML，Safe apply。把这三点做好，哪里都能配通。静态IP配置本身不是难点，真正难的是配置之后各种环境变量导致的问题叠加。多花两分钟做信息收集和备份，配完多执行几步验证，基本不会翻车。我自己的习惯是，配完静态IP之后顺手把/etc/netplan下的所有配置目录打一个整体备份包，下次再改任何网络相关的配置，先还原到这份基准再动手，省得越调越乱。这个做法推荐给所有需要长期维护服务器网络的同行。