CentOS云主机重启后eth0变eth1，MAC绑定漂移修复法
云主机一重启，远程直接断，登上控制台一看，eth0没了，冒出来一个eth1，IP地址也跟着消失。这种“网卡漂移”在CentOS里不算新鲜事，却能把人逼出一身冷汗。下面把踩坑、定位、修复的全过程压成一篇干货，照着做，十分钟内能让网卡乖乖回到原位。
一、为什么重启后eth0会变成eth1
CentOS把MAC地址当身份证。云平台克隆、快照恢复、手动更换实例类型，都会让虚拟网卡的MAC发生变化。系统启动时，udev会根据/etc/udev/rules.d/70-persistent-net.rules给“新脸”颁发新名字eth1，旧记录eth0因MAC对不上被直接跳过。于是原配eth0被系统判“失联”，新网卡顶着eth1上岗，配置文件却还躺在ifcfg-eth0里，IP自然起不来。
二、先别急着改配置，两步确认漂移真相
1. 控制台执行
ip link
看实际识别到的网卡名与MAC。
2. 对比
cat /etc/udev/rules.d/70-persistent-net.rules
如果里面记录的MAC与ip link结果不一致，漂移实锤。
三、临时抢救：手动把eth1提起来
生产环境先救命再治病。复制一份配置：
cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1
把ifcfg-eth1里的DEVICE=eth0改成DEVICE=eth1，确认ONBOOT=yes，然后
ifup eth1
IP回来，SSH能进，先稳住业务。
四、永久修复：让eth0这个名字固定下来
目标是把新MAC重新注册成eth0，让系统下次不再乱起名。
1. 打开规则文件
vi /etc/udev/rules.d/70-persistent-net.rules
2. 找到NAME="eth1"那一行，把MAC替换成当前实际值，NAME改成eth0，直接覆盖旧eth0条目。
3. 删除多余条目，只保留一段，保存退出。
4. 回到网卡脚本
vi /etc/sysconfig/network-scripts/ifcfg-eth0
确认DEVICE=eth0、HWADDR=新MAC，其余IP、掩码、网关保持原样。
5. 重建initramfs，避免早期启动仍读旧规则
dracut -f
6. 重启验证
reboot
重启完再ip link，eth0回归，IP正常，漂移解决。
五、一键脚本：懒得手打也能修
把下面内容存成fix-eth.sh，丢进云主机，chmod +x后root执行，全程自动：
#!/bin/bash
MAC=$(ip link show eth0 | awk '/link/ether/{print $2}')
echo "SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$MAC", NAME="eth0"" > /etc/udev/rules.d/70-persistent-net.rules
sed -i "s/^HWADDR=.*/HWADDR=$MAC/" /etc/sysconfig/network-scripts/ifcfg-eth0
dracut -f
echo 'Done. Please reboot.'
脚本跑完重启，eth0漂移概率直接归零。
六、云平台侧也能防：绑定MAC到实例
部分云厂商支持“保留弹性网卡”功能。创建实例时勾选“保留源MAC”，后续即使停机重启，虚拟网卡MAC不会变，系统侧udev也抓不到新脸，漂移从根源消失。若业务对IP、MAC有硬绑定需求，直接上这招最省心。
七、常见翻车点提醒
1. 只改ifcfg不碰udev，重启后系统照漂不误。
2. 规则文件里留多段MAC，udev按顺序匹配，结果仍是eth1。
3. 忘记更新initramfs，早期启动阶段依旧读旧规则，导致修复失败。
4. 云主机装了cloud-init，它会自动写规则，修复后需加锁：
chattr +i /etc/udev/rules.d/70-persistent-net.rules
防止cloud-init重启时覆写。
八、总结回顾
CentOS云主机重启后eth0变eth1，本质是udev把新MAC当新设备。想根治，就两步：把新MAC写回eth0的udev规则，再让网卡配置与规则对应。临时提eth1保业务，永久改规则防复发，配合云平台保留MAC功能，漂移从此不再半夜吓人。
