Cloud-init 初始化失败导致 Droplet 无法启动时，优先通过恢复控制台（Recovery Console）登录系统禁用 cloud-init 服务，而不是直接重建实例。
直接重建会清空磁盘数据，仅建议在无法通过控制台修复或无需保留数据时使用。
先说结论：Cloud-init 阻塞启动通常是因为网络元数据获取超时或用户脚本错误，优先尝试控制台修复而非直接重建。
- 先确认：通过云厂商提供的 VNC 或恢复控制台访问实例。
- 先处理：在控制台内临时禁用 cloud-init 服务以完成启动。
- 再验证：检查系统日志确认启动流程恢复正常后再排查脚本。
命令速用版
若能通过控制台登录，执行以下命令临时禁用 cloud-init 并重启：
sudo touch /etc/cloud/cloud-init.disabled
sudo reboot若必须重建实例，确保在控制面板中清除或修正 User Data 字段后再操作。
为什么会这样
Cloud-init 在系统启动早期运行，依赖网络连通性来获取元数据或执行用户脚本。
如果网络配置错误、元数据服务不可达或脚本中存在死循环，cloud-init 会阻塞后续启动流程，导致 SSH 无法连接或系统看似无响应。
分步处理
按照以下顺序操作，避免不必要的数据丢失：
- 访问恢复控制台：在云厂商控制面板找到 Droplet 的“访问控制台”或"Recovery Console"入口，这是唯一能在网络不可用时登录的方式。
- 查看启动日志：登录后可查看
/var/log/cloud-init.log或/var/log/cloud-init-output.log定位报错行。 - 禁用服务：执行
sudo touch /etc/cloud/cloud-init.disabled创建禁用标记文件。 - 重启实例：执行
sudo reboot观察是否能正常进入系统。 - 修正配置：启动成功后，检查
/etc/cloud/cloud.cfg或用户数据脚本，修复错误后删除禁用文件。
怎么验证是否生效
重启后使用 SSH 正常连接，且系统负载不再持续偏高。
检查 systemctl status cloud-init-local.service 状态，若已禁用则显示 inactive 或 disabled。
常见坑
- 直接点击“重建 Droplet"会清空所有磁盘数据，除非已有快照备份。
- 禁用 cloud-init 后，后续重启不会自动应用新的元数据变更，需手动恢复服务。
- 部分镜像默认配置了强依赖网络的 mount 点，网络未就绪时会卡住启动，需在 fstab 中调整 _netdev 参数。
常见问题
重建 Droplet 能解决 cloud-init 失败吗？
不能直接解决，若 User Data 脚本未修正，重建后 cloud-init 会再次失败。
禁用 cloud-init 会影响系统更新吗？
不会影响系统包更新，但会影响实例首次启动时的主机名设置、密钥注入等自动化配置。
如何永久修复而不是临时禁用？
修复用户数据脚本中的语法错误或网络依赖，删除 /etc/cloud/cloud-init.disabled 文件后重启。
参考来源
- DigitalOcean 官方文档 - Product Documentation (https://docs.digitalocean.com/)
- Cloud-init 官方文档 - Logging and Debugging (https://cloudinit.readthedocs.io/)