1. 为什么固定 IP 这件事值得认真对待在局域网里折腾过服务的人大概都有过这种体验明明昨天还能访问的测试机今天开机后地址变了SSH 连不上、数据库客户端配置失效、容器编排里的节点地址对不上排查半天才发现是 DHCP 重新分配了租约。这种问题不致命但极其消耗时间尤其是在多机协作、自建服务、远程调试的场景下地址漂移带来的连锁反应会让人抓狂。Ubuntu 设置固定 IP 地址这件事本质上是在解决地址稳定性这个基础问题。它适合所有需要在局域网内提供稳定服务的场景自建文件服务器、数据库主机、开发测试环境、容器宿主机、监控采集节点、打印服务器等等。对刚接触 Linux 网络配置的新手来说这是一道绕不开的坎对有经验的从业者来说这也是每次新机器上线时必做的一步标准动作。但这里有个现实问题Ubuntu 从 17.10 开始把网络配置从传统的/etc/network/interfaces迁移到了Netplan而桌面版和服务器版的行为还不完全一样再加上 Ubuntu 22.04、24.04 在 Netplan 版本上的演进网上大量老教程直接照抄会踩坑。我见过不少人照着几年前的博客改配置结果netplan apply报错、网络直接断掉只能跑到机器跟前接显示器救场。这篇内容就把这件事从头到尾讲透Netplan 的配置逻辑是什么、YAML 文件怎么写、静态地址和网关 DNS 怎么配合、桌面环境和服务器环境有什么差异、改完之后怎么验证、出问题了怎么回滚。所有步骤都可以直接照着操作参数选择也会给出计算和判断依据不是那种复制粘贴就完事的流水账。2. Netplan 的设计逻辑与方案选型2.1 为什么 Ubuntu 要用 Netplan 这层抽象要理解 Netplan先得理解它想解决什么问题。在 Netplan 之前Ubuntu 用的是ifupdown这套体系配置文件是/etc/network/interfaces写法偏命令式不同发行版之间差异大而且和 NetworkManager、systemd-networkd 这些后端管理工具容易打架。Netplan 的思路是引入一层声明式的 YAML 描述层你只负责描述我想要什么网络状态具体怎么落地交给后端渲染器去执行。这个设计的好处很直接同一份 YAML 可以渲染给不同的后端。Ubuntu 服务器版默认用systemd-networkd作为渲染器桌面版默认用NetworkManager。你在 YAML 里写的是同一套语法Netplan 根据/etc/netplan/下配置文件的renderer字段决定交给谁执行。这就避免了以前桌面用一套、服务器用另一套的割裂感。从实操角度看这意味着你改配置时不需要关心底层是 networkd 还是 NetworkManager只要 YAML 写对、渲染器指定对netplan apply一执行就生效。但反过来说如果渲染器指定错了或者 YAML 缩进有问题报错信息往往不够直观这是新手最容易卡住的地方。2.2 静态 IP、DHCP 保留、手动绑定三种方案怎么选在动手改配置之前先想清楚一件事固定 IP 不一定非得在系统里配。实际有三种常见做法各有适用场景。方案实现位置优点缺点适用场景系统内静态配置主机 Netplan不依赖路由器地址绝对稳定换网段要改配置多机管理分散服务器、固定机房环境DHCP 地址保留路由器/ DHCP 服务端集中管理主机零配置依赖 DHCP 服务可用性家庭网络、小型办公网手动绑定 ARP交换机/路由器不改主机配置配置繁琐维护成本高特殊兼容场景我的建议很明确服务器和需要长期稳定提供服务的机器直接在系统里配静态地址。原因是它不依赖任何外部服务的可用性DHCP 服务挂了、路由器重启了你的机器地址照样不变。DHCP 保留适合那种机器多、又不想逐台登录改配置的场景但它有个隐性风险——如果 DHCP 服务本身出问题机器可能拿不到地址或者拿到错误地址。手动绑定 ARP 这种方式现在用得很少了除非是某些老旧设备不支持静态配置否则没必要绕这个弯。2.3 配置文件命名与优先级规则/etc/netplan/目录下的配置文件按文件名字典序加载后加载的会覆盖先加载的同名配置项。Ubuntu 安装后默认会生成一个类似50-cloud-init.yaml或01-network-manager-all.yaml的文件具体名字取决于安装方式。这里有个实操细节不要直接改默认生成的那个文件尤其是50-cloud-init.yaml因为 cloud-init 在某些环境下会重新生成它把你的修改覆盖掉。正确做法是新建一个编号更靠前的文件比如99-static.yaml或者01-static.yaml让它的配置优先生效。命名用两位数前缀是社区惯例99-表示最后加载、优先级最高01-表示最先加载。我一般用99-开头语义上更符合这是我的最终配置的直觉。注意如果目录里同时存在多个配置文件且都定义了同一块网卡Netplan 会按加载顺序合并后加载的覆盖先加载的。改之前先ls /etc/netplan/看清楚有哪些文件避免配置冲突。3. 核心配置细节与参数计算3.1 先搞清楚网卡名字和当前网络状态改配置前必须先确认两件事网卡的实际名称、当前使用的地址和网关。Ubuntu 现在的网卡命名规则是可预测网络接口名不再是eth0这种简单名字常见的有ens33、enp3s0、eno1等。名字搞错配置写了也不生效。查看网卡名称和状态用这几条命令ip addr show ip route showip addr show会列出所有网卡及其地址找到那个有state UP且有地址的接口。ip route show输出的第一行通常是default via x.x.x.x dev xxx这里的x.x.x.x就是网关xxx就是出口网卡名。如果想看更结构化的信息可以用networkctl status这条命令在 systemd-networkd 环境下会给出每个接口的详细状态包括 DHCP 租约信息、DNS 服务器等排查问题时很好用。3.2 地址、掩码、网关、DNS 的取值逻辑静态配置需要四个关键参数IP 地址、子网掩码或 CIDR 前缀、网关、DNS。这四个值不是随便填的得和你的局域网规划对齐。IP 地址要选一个在当前网段内、且没有被 DHCP 池占用、也没有被其他设备使用的地址。判断方法先看当前 DHCP 分配的地址段比如192.168.1.100/24那网段就是192.168.1.0/24可用范围是.1到.254。避开路由器常用的.1、.254避开 DHCP 池的范围很多路由器默认池是.100到.200选个池外的地址比如.50或.250。子网掩码用 CIDR 表示/24对应255.255.255.0这是最常见的家用和小型办公网配置。如果是/16对应255.255.0.0/25对应255.255.255.128。CIDR 和点分十进制的换算记住一个简单规律/24是 24 个 1即前三个字节全 1每减少一位掩码范围翻倍。网关通常是路由器的 LAN 口地址从ip route show的default via后面直接读出来就行不用猜。DNS可以填网关地址很多路由器自带 DNS 转发也可以填公共 DNS。企业内网如果有内部 DNS 服务器必须填内网的否则域名解析会出问题。多个 DNS 用逗号分隔按顺序尝试。3.3 YAML 配置文件的完整写法与缩进陷阱Netplan 的配置文件是 YAML 格式缩进必须用空格绝对不能用 Tab。这是新手翻车率最高的地方一个 Tab 就能让netplan apply报出让人摸不着头脑的解析错误。一个完整的静态配置长这样假设网卡名是ens33地址192.168.1.50/24网关192.168.1.1DNS 用192.168.1.1和8.8.8.8network: version: 2 renderer: networkd ethernets: ens33: dhcp4: no addresses: - 192.168.1.50/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1 - 8.8.8.8逐行解释一下关键点。version: 2是 Netplan 的配置版本现在固定写 2。renderer: networkd指定用 systemd-networkd 渲染服务器版用这个桌面版如果 NetworkManager 在管理网络要改成renderer: NetworkManager。ethernets下面是网卡定义键名就是网卡实际名称。dhcp4: no关闭 IPv4 的 DHCP。addresses是地址列表注意 CIDR 后缀不能省。routes里to: default表示默认路由via是网关地址。老版本 Netplan 用的是gateway4字段但新版本已经废弃用routes写法更稳妥兼容性更好。nameservers下的addresses是 DNS 列表。这里有个容易忽略的点如果你只写 DNS 不写dhcp4: noDHCP 拿到的 DNS 可能会和静态配置的混在一起导致解析行为不确定。所以静态配置时一定要显式关掉 DHCP。提示写完配置后先用netplan try而不是直接netplan apply。netplan try会应用配置并等待你确认如果在规定时间内没有确认或者按了 CtrlC会自动回滚到之前的配置。这个机制在远程操作时是救命稻草能防止配置写错导致失联。3.4 桌面版与服务器版的渲染器差异前面提到渲染器要匹配环境这里展开说清楚。判断当前用的是哪个渲染器看/etc/netplan/下默认配置文件里的renderer字段或者直接看哪个服务在跑systemctl is-active systemd-networkd systemctl is-active NetworkManager哪个返回active基本就是哪个在管网络。Ubuntu 服务器版默认systemd-networkd活跃桌面版默认NetworkManager活跃。如果两个都活跃以 Netplan 配置里指定的renderer为准。桌面版用 NetworkManager 有个额外好处图形界面里的网络设置和 Netplan 配置是联动的改完 YAML 后桌面右上角的网络图标状态会同步更新。但反过来如果在图形界面里手动改了 IPNetworkManager 可能会生成自己的配置文件和你的 YAML 产生冲突。所以桌面版建议要么全用图形界面配要么全用 Netplan 配别混着来。4. 完整实操流程与验证方法4.1 从零开始配置静态地址的完整步骤假设场景一台 Ubuntu 服务器网卡ens33当前 DHCP 地址192.168.1.123/24网关192.168.1.1要改成静态192.168.1.50/24。第一步备份现有配置。这一步别省出问题时能快速回滚sudo cp -r /etc/netplan /etc/netplan.bak第二步查看现有配置文件确认没有冲突ls -l /etc/netplan/ cat /etc/netplan/*.yaml第三步新建配置文件。用nano或vim都行文件名用99-static.yamlsudo nano /etc/netplan/99-static.yaml把前面 3.3 节的 YAML 内容按你的实际参数填进去。注意网卡名、地址、网关、DNS 都要换成你自己的。第四步设置文件权限。Netplan 对配置文件权限有要求太开放会报警告sudo chmod 600 /etc/netplan/99-static.yaml第五步先试运行sudo netplan try如果配置语法没问题会提示你按 Enter 确认。确认后配置生效。如果报错根据错误信息检查 YAML 缩进和字段拼写。第六步正式应用如果netplan try已经确认过这步可跳过但有些场景下try的超时机制会干扰直接 apply 更干脆sudo netplan apply第七步验证。用ip addr show ens33看地址是否变成192.168.1.50/24用ip route show看默认路由是否指向192.168.1.1用ping -c 3 192.168.1.1测网关连通性用ping -c 3 8.8.8.8测外网连通性用ping -c 3 www.example.com测 DNS 解析。4.2 验证清单与逐项排查配置改完不是看到地址变了就完事得逐项验证。我整理了一个验证清单按顺序过一遍基本能覆盖所有问题点。验证项命令预期结果异常含义地址生效ip addr show 网卡显示配置的静态地址配置未加载或网卡名错默认路由ip route showdefault via 网关网关字段写错或路由未渲染网关连通ping -c 3 网关有回包网关地址错或链路问题外网连通ping -c 3 8.8.8.8有回包路由或上游问题DNS 解析ping -c 3 www.example.com解析出地址并回包DNS 配置错渲染器状态networkctl status 网卡显示 configured渲染器未接管如果地址生效但外网不通优先查路由如果外网通但域名解析不了查 DNS如果网关都 ping 不通查网卡名和链路。这个顺序是从底层往上排能快速定位问题层级。4.3 远程操作时的安全操作规范在远程 SSH 会话里改网络配置风险比本地操作高得多因为一旦配置错误导致网络断开你就失去了连接手段。几个必须遵守的规范第一永远先netplan try再netplan apply。try的超时回滚机制是远程操作的保险绳。第二开两个 SSH 会话。一个用来操作另一个保持连接不动。如果操作会话断了另一个还能用前提是配置没有彻底破坏网络栈。第三改配置前记录当前状态。把ip addr、ip route、cat /etc/resolv.conf的输出保存下来出问题时能对照恢复。第四避免在配置里同时改网卡名和地址。一次只改一个变量改完验证通过再改下一个降低排查难度。第五如果机器有带外管理IPMI、iDRAC 之类提前确认带外通道可用这是最后的兜底手段。注意netplan apply执行后如果网络断了SSH 会话会卡住但机器本身可能还在运行。这时候不要反复重试连接等一两分钟有些配置需要时间收敛。如果确认断了只能通过本地控制台或带外管理恢复。5. 常见问题排查与避坑实录5.1 配置不生效的六种典型原因改完配置netplan apply没报错但地址就是没变这种情况我遇到过很多次原因基本集中在以下几类。YAML 缩进错误。这是最高频的。YAML 对缩进极其敏感同一层级必须对齐子层级必须比父层级多缩进。用netplan generate可以单独验证语法它会渲染配置但不应用报错信息比apply更详细sudo netplan generate网卡名写错。ens33写成ens3或者eth0配置会静默失效因为 Netplan 找不到匹配的接口。用ip link show确认准确名称。渲染器不匹配。服务器上写了renderer: NetworkManager但 NetworkManager 没装或没跑配置就不会生效。反过来桌面版写了networkd但 networkd 没启用也一样。配置文件权限不对。权限过于开放时 Netplan 会拒绝加载netplan apply可能只给个警告。用chmod 600修正。多个配置文件冲突。目录里有多个文件都定义了同一网卡加载顺序导致你的配置被覆盖。ls /etc/netplan/看清楚把冲突的旧文件移走或改名。cloud-init 覆盖。云环境或某些安装方式下50-cloud-init.yaml会被 cloud-init 重新生成。解决办法是在/etc/cloud/cloud.cfg.d/下加一个配置禁用网络配置或者直接改 cloud-init 的 network 配置源。5.2 网络断开后的紧急恢复手段配置写错导致网络彻底断开这是最让人紧张的时刻。恢复手段按可用性排序如果还能本地登录物理机接显示器、虚拟机开控制台直接编辑/etc/netplan/下的配置文件改回正确值或者从备份恢复sudo cp /etc/netplan.bak/*.yaml /etc/netplan/ sudo netplan apply如果只能远程但还有另一个会话连着在另一个会话里操作恢复。如果所有会话都断了只能走带外管理或请人到现场。预防永远比恢复重要。我现在的习惯是任何网络配置改动前先确认带外管理可用或者确认机器物理可达。这个习惯救过我很多次。5.3 静态配置后 DNS 解析异常的排查地址配好了、网关通了、外网 IP 能 ping 通但域名解析不了这是静态配置后很常见的问题。原因通常是/etc/resolv.conf的内容和 Netplan 配置不一致。Netplan 配置的nameservers会通过渲染器写入/etc/resolv.conf或者通过 systemd-resolved 管理。检查实际生效的 DNSresolvectl status cat /etc/resolv.conf如果resolv.conf是个软链接指向systemd/resolve.conf说明 systemd-resolved 在管理 DNS这时候要看resolvectl status里每个接口的 DNS 配置。如果 Netplan 里配了 DNS 但resolvectl里没显示说明渲染器没把 DNS 传下去检查nameservers字段的缩进层级是否正确。还有一种情况/etc/resolv.conf被其他工具比如某些容器运行时或手动修改覆盖了。检查文件是否是软链接如果不是说明有东西在直接写这个文件需要找到源头处理。5.4 双网卡与多网段环境的注意事项机器有两块以上网卡时静态配置的复杂度会上升。核心问题是默认路由只能有一个多网卡都配网关会导致路由冲突。正确做法是只有一块网卡配默认路由to: default其他网卡只配地址和网段内路由不配默认网关。如果确实需要多路径得用策略路由那是另一个话题了。多网卡配置示例ens33走默认路由ens34只配内网地址network: version: 2 renderer: networkd ethernets: ens33: dhcp4: no addresses: - 192.168.1.50/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1 ens34: dhcp4: no addresses: - 10.0.0.50/24ens34不写routes和nameservers它只负责同网段通信。跨网段流量走ens33的默认路由。这个结构在多网卡环境里最稳不会出现路由抖动。6. 我踩过的坑与实操心得6.1 几个反直觉的细节第一个坑netplan apply不一定会重启网卡。在某些情况下它只是重新渲染配置并通知后端如果后端判断配置变化不影响链路网卡不会 down/up。这意味着某些依赖链路状态变化才能生效的设置可能不生效。遇到这种情况可以手动sudo ip link set 网卡 down再up或者重启网络服务。第二个坑gateway4字段的废弃。老教程里大量用gateway4: 192.168.1.1新版本 Netplan 虽然还兼容但会给出 deprecated 警告而且和routes混用时行为不确定。统一用routes写法别用gateway4。第三个坑DNS 的search域。企业内网经常需要配搜索域让短主机名能解析。这个在 Netplan 里是nameservers下的search字段不是addresses。写错位置不报错但解析行为不符合预期。第四个坑虚拟机快照和静态 IP 的冲突。用虚拟机做实验时如果从一台配了静态 IP 的机器克隆出多台所有克隆机地址都一样网络直接冲突。克隆后第一件事就是改地址或者克隆前先改回 DHCP。6.2 配置管理的长期建议机器多了之后逐台登录改 Netplan 不现实。我的做法是把 Netplan 配置纳入配置管理用 Ansible 之类的工具批量下发。模板里把网卡名、地址、网关做成变量按主机清单渲染。这样新机器上线时一条命令搞定也避免了手改出错。对于少量机器至少把配置文件纳入版本控制。/etc/netplan/目录用 git 管理每次改动有记录出问题能 diff 出改了什么。这个习惯成本很低收益很高。6.3 什么情况下不该用静态 IP最后说个反向的经验不是所有机器都该配静态 IP。临时测试机、频繁迁移的容器宿主机、笔记本这类会换网络的设备配静态反而添麻烦。判断标准很简单这台机器是否需要在固定地址上长期提供服务。是就配静态不是用 DHCP 保留或者干脆动态分配更省心。我见过有人给开发笔记本配了静态 IP结果换个办公室网络就上不了网还得手动改回来。这种场景用 DHCP 加路由器端的地址保留体验好得多。工具是为人服务的别为了稳定两个字给自己找不必要的工作量。