企业官网建设流程全解析

1. 先说清楚：为什么18.04之后配静态IP变得更“麻烦”了

用Ubuntu的老用户应该都有印象，在16.04及更早的版本里，改IP就是编辑一下/etc/network/interfaces这个文件，填上address、netmask、gateway三行，重启网络服务就完事。到了18.04，情况变了——Ubuntu引入了netplan这个新的网络管理方案，默认不再走/etc/network/interfaces那套逻辑，很多人第一次打开/etc/netplan/目录时都有点懵：这玩意儿是什么？配置文件怎么长这样？

先说结论：18.04及以上版本（包括20.04、22.04、24.04）配置静态IP，核心思路就是编辑/etc/netplan/下的YAML配置文件，然后执行sudo netplan apply让配置生效。YAML格式对缩进极其敏感，一个空格错了，轻则配置不生效，重则直接断网。我见过不少朋友在服务器上改完配置一apply，SSH立刻断开，然后人已经在机房外了，那种绝望感经历过一次就再也不想经历第二次。

这篇文章我会把整个流程拆开讲透：从查看当前网络状态、确认网卡名称，到编写netplan配置、处理DNS和网关，再到常见的坑和排查方法。不管你是虚拟机里装的Ubuntu，还是物理机上跑的真实系统，方法基本一致，个别细节我会单独指出来。

顺便说一句，虽然现在Ubuntu已经出到24.04，但18.04的配置方式和后续版本高度相似，学会一套基本通吃。唯一需要注意的差异是不同版本默认的渲染器可能有区别（有的用NetworkManager，有的用systemd-networkd），这个后面细说。

2. 配置前的三件事：网卡名、当前IP、网关和DNS

2.1 确认网卡名称：别再想当然地写eth0

很多人配置静态IP失败，第一步就栽在网卡名称上。从Ubuntu 18.04开始，系统默认使用Predictable Network Interface Names（可预测网络接口命名），网卡名不再是传统的eth0、eth1，而是像ens33、ens160、enp0s3这种带硬件信息的名字。在云服务器上，可能是eth0，但更多时候你会看到类似ens5、enp1s0这样的名称。

查看网卡名称的几种方式：

ip addr show

或者：

ip link show

再或者用传统一点的：

ifconfig -a

如果ifconfig提示命令不存在，需要先安装：

sudo apt install net-tools

这三种方式得出的结果里，带state UP或者有IPv4地址的那个就是你的活动网卡。比如输出里有ens33: <BROADCAST,MULTICAST,UP,LOWER_UP>，那你的网卡名就是ens33。

提示：别用ifconfig的输出去猜网卡名，有些时候你看到一堆docker0、br-xxxx、vethxxxx之类的虚拟网卡，那些是Docker或其他虚拟化软件创建的，跟物理网卡无关。认准有IP地址、状态为UP且MAC地址不是你虚拟网卡的那个。

2.2 记录当前网络参数：有备份才有退路

在动手改配置之前，强烈建议先把当前网络参数记录下来。我自己的习惯是开一个文本文件，把这些信息全存下来：

ip addr show ip route show cat /etc/resolv.conf

关键信息包括：

• 当前IP地址和掩码（比如192.168.1.100/24）
• 网关地址（ip route输出里的default via那一行）
• DNS服务器（/etc/resolv.conf里的nameserver行）

为什么要记录？因为一旦配置出错，你可能需要手动恢复。另外在虚拟机场景里，如果你用的是NAT模式，网关通常是192.168.x.1或者192.168.x.2（VMware的NAT网关一般是192.168.x.2，VirtualBox是192.168.x.1），但不要想当然，一定以ip route的实际输出为准。

2.3 判断网络管理方式：netplan的渲染器到底是什么

netplan本身只是一个配置抽象层，它负责读取YAML配置，然后生成后端配置交给实际的网络管理服务。后端有两种：

• networkd：由 systemd 提供的网络服务，适合服务器环境，轻量、稳定
• NetworkManager：桌面版默认的图形化网络管理工具，适合笔记本、桌面环境

怎么判断当前系统用哪个？看这个文件：

cat /etc/netplan/01-network-manager-all.yaml

如果里面写着renderer: NetworkManager，说明桌面环境在用NetworkManager。如果写着renderer: networkd，或者没有明确指定（默认走networkd），就是systemd-networkd。

服务器版（Server版）默认是networkd，桌面版（Desktop版）默认是NetworkManager。这个差异很重要：如果你在桌面版上手动改了netplan配置，可能会发现不生效，因为NetworkManager可能在你重启后把配置覆盖回去。这时候要么在netplan配置里把renderer设为NetworkManager，要么干脆禁用NetworkManager的网络管理功能。

我自己在虚拟机上测试时，通常用Server版镜像，干净利落。如果你是在桌面版上折腾，后面我会专门讲NetworkManager的处理方式。

3. 手动配置静态IP：从改YAML到生效

3.1 找到并理解netplan配置文件

netplan的配置文件统一放在/etc/netplan/目录下。不同版本、不同安装方式的文件名可能不同，常见的有：

• 01-netcfg.yaml
• 01-network-manager-all.yaml
• 50-cloud-init.yaml
• 99_config.yaml

查看一下：

ls /etc/netplan/

然后用sudo cat查看内容。比如云服务器上常见的是：

network: version: 2 ethernets: eth0: dhcp4: true

这个配置的意思很直白：eth0网卡启用DHCP自动获取IPv4地址。我们要做的，就是把这个dhcp4: true改成静态配置。

3.2 编写静态IP配置：一个可以直接抄的模板

假设以下场景：

• 网卡名：ens33
• IP地址：192.168.1.100
• 掩码：255.255.255.0（在netplan里写成/24）
• 网关：192.168.1.1
• DNS：223.5.5.5和114.114.114.114

配置内容如下：

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

编辑方式：

sudo nano /etc/netplan/01-netcfg.yaml

或者：

sudo vim /etc/netplan/01-netcfg.yaml

然后把上面的内容填进去，保存退出。

注意：addresses是一个列表，以-开头，每一项一个地址。如果配置多个IP，就多列几行。掩码用CIDR格式（/24），不要写255.255.255.0。这是新手最容易犯的错误——netplan不识别传统的点分十进制掩码写法，写成255.255.255.0会直接报错。

3.3 应用配置：先试后生效，避免把自己锁在外面

配置写完后，千万别直接执行sudo netplan apply就完事。先做语法检查：

sudo netplan try

netplan try会先验证配置，如果配置有问题，它会在超时后自动回滚到之前的配置，这个机制能救命。执行后它会提示：

Do you want to keep these settings? Press ENTER before the timeout to accept new configuration

如果你看到配置生效且网络没断，按回车确认。如果系统没响应了（比如SSH断了），等120秒它会自动回滚。

确认配置没问题后，再执行：

sudo netplan apply

让配置正式生效。

提示：netplan try和netplan apply的区别在于，前者带自动回滚机制，适合远程操作；后者直接应用，适合本地操作。如果你是通过SSH远程管理服务器，建议在try之前先开一个备用终端（比如通过其他方式能登录到机器的终端），这样万一配置出错，你还有一个入口能救回来。如果实在没有备用入口，就在try期间盯着，一旦发现连接断了，等自动回滚就好。

3.4 验证配置是否生效

配置应用后，用以下命令确认：

ip addr show ens33

输出里应该能看到你设置的静态IP。再检查路由：

ip route show

确认default via 192.168.1.1 dev ens33存在。然后测连通性：

ping -c 4 192.168.1.1 ping -c 4 223.5.5.5

第一个ping是测网关，第二个是测公网。如果网关通但公网不通，多半是DNS或路由问题；如果网关都不通，说明IP、掩码或网关配置有误。

DNS验证：

nslookup www.baidu.com

或者：

dig www.baidu.com

如果nslookup和dig都没安装，可以用ping一个域名来间接验证。比如ping -c 2 www.baidu.com能解析出IP并通，就说明DNS没问题。

4. 不同场景下的差异化配置

4.1 虚拟机（VMware / VirtualBox）里怎么配

虚拟机里的Ubuntu配置静态IP，逻辑跟物理机一样，但有几个虚拟化相关的前提条件要先确认。

VMware场景：

• 网络模式如果是桥接（Bridged），虚拟机需要和宿主机在同一网段，网关指向路由器或宿主机所在网络的网关。比如宿主机IP是192.168.1.10，你可以给虚拟机配192.168.1.100/24，网关192.168.1.1。
• 网络模式如果是NAT，虚拟机通常使用192.168.xxx.0/24网段。VMware的NAT默认网段一般是192.168.xxx.0，但具体的要打开VMware的“虚拟网络编辑器”看。默认网关通常是192.168.xxx.2，不是192.168.xxx.1，这个坑我踩过。
• 网络模式如果是仅主机（Host-Only），虚拟机只能和宿主机通信，不能上外网，配置静态IP时网关不要填公网网关，填了也没用。

VirtualBox场景：

• NAT模式的默认网关是10.0.2.2，这是VirtualBox的内置网关，额外DNS可以用10.0.2.3。
• 桥接模式的话，跟VMware桥接逻辑一样，和宿主机同网段。

虚拟机配置静态IP的意义在于：开发环境需要固定IP来访问SSH、跑服务，不配置的话DHCP每次分配可能不同，你连SSH的地址就老变。

4.2 云服务器（AWS / 阿里云 / 腾讯云）上要不要自己改

云服务器上配置静态IP这事，建议谨慎再谨慎。云平台有自己的网络虚拟化层，IP地址通常由平台管理，你在系统内部改了IP，往往会导致网络直接中断，而且平台控制台看到的IP和系统内的IP会不一致。

云服务器正确的做法是：在云控制台里把网卡设置为“静态”或“私有IP固定”，操作系统内部保持DHCP自动获取即可。ECS、EC2这些平台上，私有IP本来就固定，系统内DHCP获取到的始终是同一个地址，没必要画蛇添足。

如果你确实需要在云服务器上配置多个IP（比如辅助私网IP），操作步骤也不是只改netplan，而是先在云控制台绑定辅助IP，再到系统内配置。这个流程各家平台不完全一样，建议以官方文档为准。简而言之：物理机和虚拟机可以放心折腾，云服务器不要轻易手动改IP。

4.3 桌面版Ubuntu（带图形界面）的特殊处理

桌面版Ubuntu默认用NetworkManager管理网络，配置静态IP有两种方式：

方式一：图形界面（适合新手）

设置 -> 网络 -> 有线 -> 点击齿轮图标 -> IPv4 -> 手动 -> 填写地址、掩码、网关、DNS。

这个方式最直觉，而且不会出现YAML缩进错误。缺点是如果你需要批量配置多台机器，效率太低。

方式二：命令行改netplan（适合老手）

如果你坚持用netplan方式，需要注意两点。第一，配置文件里的renderer要写NetworkManager；第二，配置完可能要重启NetworkManager服务：

sudo systemctl restart NetworkManager

或者：

sudo nmcli connection reload

有些桌面版环境里，netplan的配置优先级不如NetworkManager的connection配置高，你可能改完发现不生效。遇到这种情况，可以查一下NetworkManager当前的连接配置：

nmcli connection show

然后直接用nmcli修改当前连接的IP设置：

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

这个方法绕过了netplan，直接操作NetworkManager的配置文件，生效快且稳定。我自己在桌面版上推荐用nmcli，因为少了一层YAML转换，排查问题也直白。

5. 排查与避坑：那些年我们踩过的网络坑

5.1 配完就断网，怎么恢复

这是最高频的故障。如果你还能登录到机器（比如在本地控制台），执行：

sudo netplan apply

不行的话，检查配置文件语法：

sudo netplan generate

如果generate报错，说明YAML有语法问题，按提示修正。如果提示缺少缩进、多了空格，用cat -A查看文件，能看出空格和制表符的区别：

sudo cat -A /etc/netplan/01-netcfg.yaml

YAML里绝对不能出现制表符（Tab），必须用空格缩进。cat -A输出里^I就代表制表符，有的话全部替换成空格。

如果机器已经彻底上不了网了，物理机就直接接显示器键盘，虚拟机就在虚拟机控制台里操作，把配置文件改回DHCP模式再apply，恢复第一步。

5.2 掩码格式错误

netplan的CIDR写法中，/24对应255.255.255.0，/16对应255.255.0.0，/8对应255.0.0.0。写错掩码会导致子网计算错误，网关可能不可达。

举一个典型的错误：

addresses: - 192.168.1.100/255.255.255.0

这是错的。正确的是：

addresses: - 192.168.1.100/24

5.3 DNS配置不生效

有时候IP和网关都通了，但域名解析不了。检查一下/etc/resolv.conf：

cat /etc/resolv.conf

在netplan托管的系统里，这个文件通常是指向systemd-resolved的软链接。查看实际DNS：

systemd-resolve --status

或者新一点的版本：

resolvectl status

如果DNS确实没生效，确认netplan配置里的nameservers段是否写对、有没有缩进错误。还有一种情况是防火墙或路由问题导致DNS服务器可达性差，可以用dig @223.5.5.5 www.baidu.com直接指定DNS服务器查询，绕开系统配置的DNS，判断问题在哪个环节。

5.4 netplan与NetworkManager冲突

这个问题在桌面版尤其常见。症状是：你改了netplan，apply也成功了，但过几分钟或者重启后IP又变回DHCP获取的了。

原因很简单：NetworkManager在启动时接管了网络接口，netplan生成的配置被忽略。解决思路有三种：

• 一是按照前面说的，直接用nmcli配置，不走netplan；
• 二是把netplan配置文件里的renderer改为NetworkManager，让netplan只做配置生成，实际执行交给NetworkManager；
• 三是禁用NetworkManager对特定网卡的管理：

sudo nmcli device set ens33 managed no

然后sudo systemctl restart NetworkManager。这个方式适合确定不想让NetworkManager管理某个网卡的场景。

5.5 网卡名不对，配置了无效果

如果你在配置里写的网卡名跟系统实际的不一样，netplan apply不会报错，但会给出warn日志，或者干脆没有任何反应。验证网卡名是否匹配：

sudo netplan get

这个命令会输出当前netplan实际读取到的配置。如果你看到配置里指向的网卡名跟ip link show的输出对不上，改过来就好了。

5.6 多个网卡时配置错乱

服务器上双网卡甚至四网卡很常见。比如ens33连接内网，ens160连接外网。配置时需要注意routes段的写法。默认路由（to: default）只能有一个，如果你给两个网卡都配置了默认路由，系统会出现路由冲突，表现为时通时不通。

正确做法是：主力出口网卡配置默认路由，另一个网卡只配置内网网段的路由。例如：

network: version: 2 ethernets: ens33: addresses: - 10.0.0.100/24 routes: - to: 10.0.1.0/24 via: 10.0.0.1 ens160: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1

记住：谁负责出网，谁就写to: default。

6. 一些操作会上瘾的小技巧

6.1 用模板文件加速批量部署

如果你管理的机器多，每台都手写YAML容易出错。我的做法是维护一个模板：

network: version: 2 renderer: networkd ethernets: __IFACE__: dhcp4: no addresses: - __IP__/24 routes: - to: default via: __GATEWAY__ nameservers: addresses: - 223.5.5.5 - 114.114.114.114

用sed批量替换变量：

sed -e 's/__IFACE__/ens33/' -e 's/__IP__/192.168.1.100/' -e 's/__GATEWAY__/192.168.1.1/' template.yaml | sudo tee /etc/netplan/01-netcfg.yaml

这样不仅速度快，还能避免手抖写错缩进。

6.2 临时切换DHCP和静态

有时候排查网络问题，需要临时切回DHCP。不用把配置文件大改，只要把dhcp4改回true，addresses和routes注释掉即可：

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

然后sudo netplan apply。测试完再改回静态。

6.3 保留一份能用的配置备份

我自己的服务器上习惯保留一份确认可用的配置副本：

sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

下次改配置前先cp一份新的备份，改出问题直接恢复备份再apply，比手忙脚乱重新写配置快得多。

6.4 关于IPv6

如果你的环境不需要IPv6，建议在netplan里显式关掉：

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

dhcp6: no禁止DHCPv6，accept-ra: no禁止接受路由器通告。有些网络环境IPv6不稳定，反而导致部分应用优先走IPv6然后超时，显式关闭能减少这类问题。

7. 从18.04到24.04：这些配置方式一直没怎么变

文章写到这，我个人的实际使用体会是：Ubuntu的网络配置从18.04引入netplan之后，整个大框架一直延续到了24.04，核心逻辑没变过。变化比较大的反而是周边工具和命名规则。比如22.04开始，/etc/resolv.conf的软链接指向方式有所调整；某些云镜像里默认带cloud-init，它会在启动时覆盖netplan配置——如果你在自己做的虚拟机上发现改了配置重启后又恢复原样，多半是cloud-init在搞鬼，可以把它的网络配置功能关掉：

sudo touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg echo "network: {config: disabled}" | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

这个操作在新版本虚拟机镜像中非常有用。

最后再说一个小技巧：配置完静态IP后，建议顺手把hostname和/etc/hosts里的对应关系也确认一下。很多SSH连接慢的问题，说到底是反向DNS解析超时，跟IP配置本身无关。你可以在/etc/hosts里加上一行：

192.168.1.100 ubuntu-server

这样既能避免一些解析延迟，也能让SSH连上后快速显示主机名。

配置静态IP这事，说难不难，说简单也不简单。核心就是记住YAML格式的规则，理解网卡名和网络管理方式这两个变量，剩下的就是多练几次手。踩过的坑多了，自然就记住了。希望这篇经验之谈能帮你少走几次弯路。