在本地虚拟机里改错Netplan，回到控制台再改一次就行；在只有SSH的远程服务器上，保存后直接执行apply，地址或网关错一个，连接可能当场断掉。
所以这件事的重点不是背一段YAML，而是确保改错了还能回去。
动手前先拿到控制台
云服务器确认网页VNC、串口或救援模式可以使用；物理机确认带外管理或现场有人。没有第二条管理路径时，不建议在业务高峰远程修改主网卡。
先看真实网卡名
官方示例常写enp3s0，你的服务器可能是ens3、eth0或其他名称。用系统状态和现有Netplan配置确认，不能照抄示例。还要看当前由networkd还是NetworkManager管理。
备份当前YAML
Netplan配置通常位于/etc/netplan/。复制原文件并记录权限，先阅读现有云初始化、DNS和路由设置。多份YAML会合并，新增文件不代表旧配置自动失效。
一个常见的静态地址写法
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: false
addresses:
- 192.0.2.10/24
routes:
- to: default
via: 192.0.2.1
nameservers:
addresses:
- 192.0.2.53
- 192.0.2.54
这里的地址属于文档示例网段，不能用于你的生产环境。实际IP、前缀、网关和DNS必须来自云平台或网络管理员。Netplan官方文档当前使用addresses列表和routes中的默认路由。
缩进错误只是最容易发现的错
YAML使用空格表示层级，Tab和错位会导致解析失败。更危险的是语法正确但网关不在可达子网、重复默认路由，或者把错误地址配置到错误网卡。
先generate，再try
先运行语法生成检查，确认没有解析错误；远程环境优先使用netplan try，它要求在限定时间内确认，否则尝试回滚。不同版本和环境行为可能有差异，所以控制台仍然不能省。
为什么不建议直接apply
netplan apply会立即应用配置。SSH路径经过被修改的网卡时，错误配置会让连接中断。即使地址正确，路由和DNS变化也可能只让部分服务失效。
应用后按层检查
先看网卡地址与链路，再查默认路由；测试网关、一个公网IP和域名，最后测试真实业务。能Ping网关但不能解析域名，多半是DNS；本机正常但外部进不来，还要看云安全组和系统防火墙。
云平台为何可能覆盖配置
部分镜像使用cloud-init生成网络文件，重启后可能覆盖手工修改。查看文件头和平台文档，按其推荐方式关闭或调整自动网络配置。不要只确认apply后可用，还要做一次受控重启。
恢复方案提前写在旁边
准备恢复原YAML、重新generate/apply的命令，并把文件路径记录下来。若通过控制台恢复，先确认键盘布局和管理员凭据。修改成功后更新资产表和灾难恢复文档。
如果服务器本身来自雨云等平台，也应先看其控制台、私网和公网地址说明。极跃圈雨云入口注册代码为admin01，优惠以实时订单为准。
Netplan配置本身不复杂。真正专业的做法，是在敲下apply之前就知道：这次改错，自己从哪里回来。
