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起默认启用Netplan20.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这个IPNetplan会自动判断该走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. 核心细节解析从识别网卡到验证DNS3.1 第一步精准识别你的网卡名别再瞎猜eth0很多教程一上来就写sudo nano /etc/netplan/01-netcfg.yaml然后直接填eth0。这是最大坑点——现代Linux发行版使用可预测网卡命名规则Predictable Network Interface Names物理网卡可能是enp0s3、ens3、eno1USB网卡是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 100dev后面的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 defaultvia后面的就是网关。千万别填成公网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服务器IPsearch定义域名搜索后缀。很多人只配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.8Google、114.114.114.114国内公共、1.1.1.1Cloudflare是可靠组合。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避免桌面版误用NetworkManagerdhcp4: false和dhcp6: false关闭IPv4/IPv6自动获取这是静态IP的前提addresses必须带CIDR后缀如/24不能只写192.168.1.100routes下的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解析需前两步成功常见问题速查表现象可能原因排查命令ping 192.168.1.1超时网关IP填错或网卡未UPip link show [网卡名]看state是否UPping 8.8.8.8通但ping google.com不通DNS配置错误cat /etc/resolv.conf看是否生成正确nameservernetplan apply后SSH断开且无法恢复网关或IP与路由器不在同网段用另一台电脑ping该IP或重启进恢复模式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.comresolvectl query会显示查询路径从/etc/resolv.conf指向的stub resolver127.0.0.53再到上游DNS服务器。如果这里失败说明Netplan的nameservers没生效。若resolvectl query正常但ping google.com仍失败检查/etc/nsswitch.conf中hosts行是否包含resolvegrep ^hosts: /etc/nsswitch.conf # 正确应为hosts: files resolve [!UNAVAILreturn] dnsresolve代表使用systemd-resolveddns是备用方案。缺少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] DNSOverTLSyes FallbackDNS1.1.1.1最后重启服务sudo systemctl restart systemd-resolved。5. 常见问题与排查技巧实录5.1 “netplan apply后网络全断连本地都ping不通”这是新手最高频事故。根本原因只有一个新IP与原有DHCP分配的IP冲突或网关配置错误导致路由表混乱。Netplan应用时会先清空旧配置再加载新配置中间存在毫秒级断连。若新配置有误系统无法自动恢复。我的标准抢救流程立即拔掉网线/禁用Wi-Fi物理隔离避免IP冲突影响局域网其他设备用ip a确认当前IP是否还在——如果enp0s3下仍有192.168.1.5/24DHCP旧IP说明Netplan未完全接管执行sudo ip addr flush dev enp0s3清空临时恢复DHCP编辑/etc/netplan/02-static-ip.yaml将dhcp4: false改为true删掉addresses和routes保存后sudo netplan apply确认网络恢复后用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 cant find nas.local: NXDOMAIN。根源在于search域未生效或DNS服务器不支持.local。.local域名由mDNSMulticast DNS协议处理传统DNS服务器如8.8.8.8不解析它。解决方案分两种若内网有Avahi服务Ubuntu默认安装确保sudo systemctl status avahi-daemon是active且/etc/avahi/avahi-daemon.conf中[server]段有domain-namelocal若只想用传统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小时。真正的效率从来不是点得快而是配置得准、改得稳、查得清。