Ubuntu静态IP配置实战：Netplan网络管理详解

1. 为什么今天还要手动配静态IP？别被“自动获取”惯坏了

在绝大多数家庭和小型办公场景里，Ubuntu装好后连上路由器，网络就通了——DHCP自动分配IP、网关、DNS，一切丝滑得让人忘记底层发生了什么。但这种“开箱即用”的便利，恰恰是新手跨不过去的第一道认知门槛：一旦遇到服务器部署、Docker容器网络调试、内网服务固定访问、远程SSH免密登录配置，甚至只是想让树莓派每次开机都稳定地出现在192.168.1.100这个地址上，DHCP的随机性立刻变成绊脚石。我带过不少刚从Windows转过来的运维新人，他们第一反应是打开图形界面点点点，结果发现“网络设置”里根本找不到“IPv4设置”那个熟悉的填空框；也有人直接改/etc/network/interfaces，却在Ubuntu 20.04+系统上发现重启后配置失效——因为Netplan早已成为默认网络管理器，而它不认老式ifupdown那一套。

这个标题里的“手动设置静态IP及DNS”，表面看是个基础操作，实则是一把钥匙，能帮你打开三扇门：第一扇是网络可控性——你知道每台设备的精确位置，不再靠猜；第二扇是故障可溯性——当服务连不上时，你能快速排除是IP冲突、网关不通还是DNS解析失败；第三扇是自动化基础——所有Ansible脚本、Shell部署流程、CI/CD环境初始化，都建立在IP地址可预测的前提上。关键词“Ubuntu系统”“静态IP”“DNS”不是孤立术语，它们共同指向一个真实工作流：你正在搭建一台需要长期稳定在线、被其他设备明确寻址的服务节点。这不是实验室玩具，而是生产环境里每天都在发生的刚需。如果你正为NAS挂载失败、GitLab无法通过域名访问、或K3s集群节点间通信异常而挠头，那这篇内容就是为你写的——它不讲理论推导，只说我在生产环境里反复验证过的、能直接抄作业的操作路径。

2. 整体设计思路：为什么Netplan是唯一合理选择？

2.1 拒绝“改/etc/network/interfaces”的历史惯性

十年前，Ubuntu用的是ifupdown方案，配置写在/etc/network/interfaces里，语法简单直白：

auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8 114.114.114.114

但现在，Ubuntu 17.10起默认启用Netplan，20.04及之后版本已彻底移除ifupdown作为默认后端。如果你强行修改/etc/network/interfaces并执行sudo ifup eth0，系统会报错：“Cannot find device 'eth0'”，因为Netplan接管了底层接口管理，ifupdown根本看不到它。这不是Bug，而是设计使然：Netplan作为YAML驱动的声明式网络配置抽象层，统一了systemd-networkd、NetworkManager等后端的行为，避免了多套配置工具打架。我试过在Ubuntu 22.04上回退安装ifupdown包并禁用Netplan，结果导致GNOME桌面网络托盘消失、蓝牙共享网络中断——看似省事，实则埋下更大隐患。

2.2 为什么不用NetworkManager图形界面？

GUI确实能点选设置静态IP，但问题在于：它生成的配置藏在/etc/NetworkManager/system-connections/下的加密文件里，格式是ini而非YAML，且每次修改都会触发NetworkManager重载，可能意外断开当前SSH连接（尤其当你远程操作时）。更关键的是，NetworkManager专为移动设备设计，强调热插拔和多网络切换，而服务器场景需要的是“配置即事实”——一份清晰、可版本控制、可批量分发的纯文本文件。我管理着12台Ubuntu服务器，全部用Git仓库托管Netplan配置，每次更新只需git pull && sudo netplan apply，比点十次鼠标还快。

2.3 Netplan的核心逻辑：声明式 ≠ 复杂

Netplan的YAML配置常被吐槽“太啰嗦”，但它的设计哲学非常务实：你只描述“想要什么”，不关心“怎么实现”。比如你要一台机器永远用192.168.1.100这个IP，Netplan会自动判断该走systemd-networkd还是NetworkManager后端，并生成对应的实际配置。这种抽象带来两大好处：一是升级安全——Ubuntu 24.04若更换网络后端，你的YAML无需改动；二是环境一致——同一份配置，在物理机、VM、LXC容器里都能生效。我曾用同一份Netplan文件，在VMware虚拟机、Proxmox LXC容器、以及树莓派4B上完成部署，唯一变化只是把eth0换成enp0s3或ens3，其余参数零修改。

提示：Netplan本身不处理网络，它只是个“翻译器”。真正干活的是后端（backend），目前主流只有两个：networkd（轻量、无GUI依赖，适合服务器）和NetworkManager（功能全、支持WiFi，适合桌面）。本教程默认采用networkd，因为它更符合“静态IP”场景的稳定性需求——没有多余进程干扰，配置变更后生效更快。

3. 核心细节解析：从识别网卡到验证DNS

3.1 第一步：精准识别你的网卡名，别再瞎猜eth0

很多教程一上来就写sudo nano /etc/netplan/01-netcfg.yaml，然后直接填eth0。这是最大坑点——现代Linux发行版使用可预测网卡命名规则（Predictable Network Interface Names），物理网卡可能是enp0s3、ens3、eno1，USB网卡是enx001122334455，而虚拟机里常见ens33。填错名字，Netplan直接报错：“Unknown interface 'eth0'”。

正确做法是执行：

ip -br a | grep -E "UP|LOWER"

这条命令输出类似：

lo UNKNOWN 127.0.0.1/8 ::1/128 enp0s3 UP 192.168.1.5/24 fe80::a00:27ff:fe1a:3b4c/64

注意第二列状态为UP的接口名（这里是enp0s3），这就是你要配置的网卡。如果看到多个UP状态，用ip route | grep default确认默认路由走哪个接口：

$ ip route | grep default default via 192.168.1.1 dev enp0s3 proto dhcp metric 100

dev后面的enp0s3就是主网卡。记住这个名称，后续所有配置都基于它。

实操心得：我习惯在配置前先备份原始配置。执行sudo cp /etc/netplan/*.yaml /tmp/netplan-backup.yaml，万一配错导致断网，还能用Live USB挂载恢复。另外，别用ifconfig——它已被废弃，显示信息不全，ip命令才是现代标准。

3.2 第二步：理解子网掩码与网关的数学关系

静态IP配置里最常填错的是gateway和subnet-mask。很多人直接抄“255.255.255.0”和“192.168.1.1”，却不知道这背后是CIDR（无类别域间路由）计算。Ubuntu Netplan要求用CIDR格式写子网，如192.168.1.0/24，而不是255.255.255.0。

换算很简单：/24表示前24位是网络位，对应255.255.255.0；/16是255.255.0.0；/28是255.255.255.240。关键是要确保你设的IP地址落在子网范围内。例如，若路由器LAN口是192.168.1.1/24，那么可用IP是192.168.1.2到192.168.1.254（.1被路由器占，.0和.255是网络地址和广播地址）。你设192.168.1.100/24完全合法，但若设192.168.2.100/24，就和路由器不在同一网段，必然不通。

网关必须是路由器LAN口的IP，且必须和你的IP在同一子网。查路由器IP的方法：在能上网的机器上执行ip route | grep default，via后面的就是网关。千万别填成公网IP（如114.114.114.114），那是DNS服务器，不是网关。

注意：有些企业网络用/16大子网（如10.0.0.0/16），此时可用IP范围是10.0.0.1到10.0.255.254，网关可能是10.0.0.1或10.0.1.1。务必先确认网络规划，否则配完发现连不上内网打印机。

3.3 第三步：DNS配置的双重保险机制

Netplan中DNS配置有两层：nameservers指定DNS服务器IP，search定义域名搜索后缀。很多人只配nameservers，结果ping gitlab不通，但ping gitlab.local可以——这就是缺了search。

典型配置：

nameservers: addresses: [8.8.8.8, 114.114.114.114, 1.1.1.1] search: [local, home.arpa]

addresses是DNS服务器列表，建议至少填两个，第一个失效时自动切第二个。8.8.8.8（Google）、114.114.114.114（国内公共）、1.1.1.1（Cloudflare）是可靠组合。search用于补全域名：当你执行ssh nas时，系统会依次尝试nas.local、nas.home.arpa、nas，直到解析成功。家庭NAS常用.local，企业内网常用.corp或.internal。

实操心得：DNS配置后，别急着测试网页，先用nslookup和dig验证。执行nslookup google.com，看是否返回IP；再执行nslookup nas.local，确认内网域名是否解析。如果nslookup通但浏览器打不开，问题大概率出在防火墙或服务本身，而非DNS。

4. 实操过程：从零开始配置并验证

4.1 创建并编辑Netplan配置文件

Ubuntu的Netplan配置文件通常放在/etc/netplan/目录下，以.yaml结尾。系统可能已有00-installer-config.yaml（安装时生成）或01-network-manager-all.yaml（桌面版）。我们不修改原文件，而是新建一个更高优先级的配置（文件名数字越大优先级越高），避免覆盖系统默认配置。

执行：

sudo nano /etc/netplan/02-static-ip.yaml

粘贴以下模板（请根据你的实际信息替换方括号内容）：

# /etc/netplan/02-static-ip.yaml network: version: 2 renderer: networkd ethernets: [你的网卡名]: # 例如 enp0s3 dhcp4: false dhcp6: false addresses: [192.168.1.100/24] # 静态IP及子网 routes: - to: default via: 192.168.1.1 # 网关IP nameservers: addresses: [8.8.8.8, 114.114.114.114] search: [local]

重点说明：

• renderer: networkd明确指定后端为systemd-networkd，避免桌面版误用NetworkManager；
• dhcp4: false和dhcp6: false关闭IPv4/IPv6自动获取，这是静态IP的前提；
• addresses必须带CIDR后缀（如/24），不能只写192.168.1.100；
• routes下的to: default等价于传统配置中的gateway，这是Netplan推荐写法；
• 文件末尾必须空一行，YAML对缩进和空行敏感，少一个空格都会报错。

保存后，执行语法检查：

sudo netplan generate

如果无输出，说明YAML语法正确；若报错，按提示修正缩进（YAML用空格，不用Tab）。

4.2 应用配置并验证网络连通性

执行应用命令：

sudo netplan apply

此命令会立即生效，无需重启。但注意：如果你是SSH远程连接，且配置错误（如网关填错），连接会瞬间中断。因此，强烈建议在本地终端或带屏幕的机器上操作。若必须远程操作，先开一个screen会话：

screen -S netplan sudo netplan apply # 若断开，重新SSH后执行 screen -r netplan 恢复

配置生效后，验证步骤分三层：

第一层：IP地址是否生效

ip a show [你的网卡名] | grep "inet " # 应输出类似：inet 192.168.1.100/24 brd 192.168.1.255 scope global enp0s3

第二层：路由表是否正确

ip route # 应包含：default via 192.168.1.1 dev enp0s3 # 以及：192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.100

第三层：基础连通性测试

ping -c 3 192.168.1.1 # 测试网关（路由器） ping -c 3 8.8.8.8 # 测试外网IP（绕过DNS） ping -c 3 google.com # 测试DNS解析（需前两步成功）

常见问题速查表：

4.3 DNS深度验证与故障定位

/etc/resolv.conf是DNS解析的最终生效文件，但Netplan不直接写它，而是由systemd-resolved服务动态生成。验证DNS是否真生效：

# 查看systemd-resolved状态 sudo systemctl status systemd-resolved # 查看当前DNS配置（Netplan生成的） sudo resolvectl status # 手动测试DNS解析（绕过缓存） sudo resolvectl query google.com

resolvectl query会显示查询路径：从/etc/resolv.conf指向的stub resolver（127.0.0.53），再到上游DNS服务器。如果这里失败，说明Netplan的nameservers没生效。

若resolvectl query正常但ping google.com仍失败，检查/etc/nsswitch.conf中hosts行是否包含resolve：

grep "^hosts:" /etc/nsswitch.conf # 正确应为：hosts: files resolve [!UNAVAIL=return] dns

resolve代表使用systemd-resolved，dns是备用方案。缺少resolve会导致跳过stub resolver，直接查/etc/resolv.conf，而后者可能被其他服务覆盖。

实操心得：我遇到过一次DNS失效，原因是公司网络策略禁止UDP 53端口，但允许TCP 53。Netplan默认用UDP，需在nameservers后加options启用TCP回退：

nameservers: addresses: [8.8.8.8, 114.114.114.114] search: [local] dhcp4-overrides: use-dns: false

然后在/etc/systemd/resolved.conf中添加：

[Resolve] DNSOverTLS=yes FallbackDNS=1.1.1.1

最后重启服务：sudo systemctl restart systemd-resolved。

5. 常见问题与排查技巧实录

5.1 “netplan apply后网络全断，连本地都ping不通”

这是新手最高频事故。根本原因只有一个：新IP与原有DHCP分配的IP冲突，或网关配置错误导致路由表混乱。Netplan应用时会先清空旧配置，再加载新配置，中间存在毫秒级断连。若新配置有误，系统无法自动恢复。

我的标准抢救流程：

1. 立即拔掉网线/禁用Wi-Fi（物理隔离），避免IP冲突影响局域网其他设备；
2. 用ip a确认当前IP是否还在——如果enp0s3下仍有192.168.1.5/24（DHCP旧IP），说明Netplan未完全接管，执行sudo ip addr flush dev enp0s3清空；
3. 临时恢复DHCP：编辑/etc/netplan/02-static-ip.yaml，将dhcp4: false改为true，删掉addresses和routes，保存后sudo netplan apply；
4. 确认网络恢复后，用journalctl -u systemd-networkd -n 50 --no-pager查看日志，找ERROR关键词，定位具体哪行配置触发失败。

注意：不要用sudo systemctl restart networking——Ubuntu已弃用该服务，执行会报错“Unit networking.service not found”。

5.2 “配置生效了，但内网服务域名解析不了”

现象：ping 192.168.1.101通，ping nas.local不通，nslookup nas.local返回server can't find nas.local: NXDOMAIN。

根源在于search域未生效或DNS服务器不支持.local。.local域名由mDNS（Multicast DNS）协议处理，传统DNS服务器（如8.8.8.8）不解析它。解决方案分两种：

• 若内网有Avahi服务（Ubuntu默认安装）：确保sudo systemctl status avahi-daemon是active，且/etc/avahi/avahi-daemon.conf中[server]段有domain-name=local；
• 若只想用传统DNS：把NAS主机名改成nas.example.com，并在路由器DNS设置里添加nas.example.com -> 192.168.1.101的静态映射，同时将Netplan的search改为[example.com]。

我测试过，Avahi在局域网内解析.local平均延迟<20ms，比查路由器DNS快得多，且无需额外配置。

5.3 “多网卡场景下，如何让某张卡走静态IP，另一张走DHCP？”

企业服务器常有双网卡：一张接内网（静态IP），一张接外网（DHCP）。Netplan完美支持：

network: version: 2 renderer: networkd ethernets: enp0s3: # 内网卡 dhcp4: false addresses: [10.0.0.100/16] routes: - to: 10.0.0.0/16 via: 10.0.0.1 enp0s8: # 外网卡 dhcp4: true dhcp6: false

关键点：routes中to指定目标网段，via指定下一跳，这样10.0.0.0/16流量走enp0s3，其他流量（包括默认路由）自动走enp0s8的DHCP网关。无需手动加metric调优，Netplan会自动为DHCP接口设置更低metric值。

5.4 “配置没问题，但重启后又变回DHCP”

这通常是因为系统存在多个Netplan配置文件，低优先级文件（如00-installer-config.yaml）覆盖了你的设置。执行：

ls -la /etc/netplan/ # 查看所有.yaml文件 sudo netplan get # 输出当前生效的完整配置（合并后）

若sudo netplan get显示的配置里没有你的静态IP，说明其他文件优先级更高或语法错误被忽略。解决方法：重命名其他配置（如sudo mv /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak），再sudo netplan apply。

最后分享一个小技巧：为防止配置错误导致失联，我写了一个一键回滚脚本/usr/local/bin/netplan-rollback：

#!/bin/bash # 回滚到DHCP模式 echo "Reverting to DHCP..." sudo tee /etc/netplan/02-static-ip.yaml << 'EOF' network: version: 2 renderer: networkd ethernets: $(ip -br a | awk '$2 ~ /UP/ {print $1; exit}') : dhcp4: true dhcp6: false EOF sudo netplan apply echo "Done. Network restored via DHCP."

赋予执行权限：sudo chmod +x /usr/local/bin/netplan-rollback。断网时，只要能本地登录，敲sudo netplan-rollback秒恢复。

我在实际使用中发现，Netplan的YAML配置虽需适应，但一旦掌握，其可维护性远超旧方案。上周我给客户部署一套监控系统，12台Ubuntu服务器的网络配置全部用Ansible模板生成，从编写到上线仅用23分钟——而用图形界面逐台配置，保守估计要3小时。真正的效率，从来不是点得快，而是配置得准、改得稳、查得清。