1. 问题现象与初步排查
Ubuntu系统重启后网络配置丢失是个经典问题,我最近在给公司部署Ubuntu 22.04 LTS服务器集群时就遇到了这个头疼的情况。每次重启后,原本配置好的静态IP、DNS设置全都恢复默认,导致自动化部署脚本全部失效。经过三天的问题追踪,终于摸清了背后的完整机制。
首先需要确认的是网络配置丢失的具体表现。通过ifconfig或ip a命令查看,可能会发现以下几种典型情况:
- 原本配置的静态IP变成了DHCP自动获取的地址
- 自定义的网络接口名称(如eth0、ens33)恢复为默认命名
- /etc/netplan/下的配置文件被覆盖或重置
- 网络服务无法正常启动,出现"Device not managed"错误
重要提示:在开始修复前,务必先执行
ip a和cat /etc/netplan/*.yaml记录当前配置,并与重启前的配置对比,这能帮助快速定位被修改的具体参数。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 罪魁祸首:cloud-init的自动重置机制
经过多次测试和日志分析(journalctl -u cloud-init),发现根本原因是cloud-init服务在每次启动时会"热心"地重置网络配置。这个设计本意是为了云环境下的自动初始化,但在物理机或常驻虚拟机中就成了麻烦制造者。
cloud-init的工作流程分为几个阶段:
- 启动时检测系统环境(/run/cloud-init/instance-data.json)
- 读取网络配置数据源(包括缓存和云平台metadata)
- 应用网络配置到netplan
- 生成最终的/etc/netplan/50-cloud-init.yaml
关键问题在于:即使没有云平台metadata,cloud-init仍会生成默认配置覆盖现有设置。通过分析/var/lib/cloud/instance/目录下的缓存文件,可以确认这一点。
3. 彻底解决方案:禁用cloud-init网络配置
3.1 方法一:修改cloud-init配置(推荐)
这是最干净的解决方案,既保留cloud-init的其他功能,又阻止其干扰网络配置:
bash复制sudo vim /etc/cloud/cloud.cfg.d/99-disable-network-config.
