CentOS 7+ 网卡命名为 ens33、eno1 等不是 bug，而是 systemd/udev 实施的可预测网络接口命名机制，依据固件、PCI 插槽、MAC 地址等生成稳定名称；改回 eth0 必须三步同步：① GRUB 内核参数加 net.ifnames=0 biosdevname=0，② 重命名配置文件并修改其中 NAME 和 DEVICE 为 eth0，③ 重建 GRUB 配置后重启，缺一不可。
为什么 CentOS 7+ 的网卡叫 ens33、eno16777736 而不是 eth0
这不是 bug，是 systemd 和 udev 实施的可预测网络接口命名（Predictable Network Interface Names）。内核启动时根据固件索引、PCI 插槽位置、MAC 地址等生成稳定但难记的名字，比如 ens33（embedded + slot）、eno1（onboard）、enp2s0（PCI bus + slot + function）。好处是多网卡场景下设备名不随加载顺序漂移；坏处是你改配置、写脚本、填监控项时总得查一遍当前叫啥。
修改网卡名为 eth0 的三步实操（CentOS 7/8）
必须同时改三处，缺一不可，否则重启后要么名字回滚，要么 network 服务启动失败报 RTNETLINK answers: File exists 或找不到设备。
- 编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX行末尾追加net.ifnames=0 biosdevname=0（注意空格，别漏biosdevname=0，否则某些 Dell/HP 服务器仍会用em1） - 运行
grub2-mkconfig -o /boot/grub2/grub.cfg生效新内核参数 - 重命名并修改网卡配置文件：
→mv /etc/sysconfig/network-scripts/ifcfg-ens33 /etc/sysconfig/network-scripts/ifcfg-eth0
→ 编辑ifcfg-eth0，把NAME=ens33和DEVICE=ens33全部改成eth0
做完立刻 reboot。别只 reload network 服务——内核没关掉可预测命名，udev 仍会按新规则生成设备节点，旧配置和新节点对不上。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
容易踩的坑：重命名后 network 服务启动失败
常见报错：Failed to start LSB: Bring up/down networking 或日志里出现 device eth0 does not exist。原因基本就两个：
-
ifcfg-ens33文件没删干净，systemd-networkd 或 network.service 启动时会尝试加载它，和ifcfg-eth0冲突 -
UUID字段没删或没更新。CentOS 7 的network服务会校验 UUID 是否匹配实际设备，克隆虚拟机后尤其容易出这问题——直接删掉UUID=...这行最省事 - 忘记改
ONBOOT=yes。默认可能还是no，重启后网卡不自动 up
不重启也能临时切回 eth0？不行，但可以验证配置是否生效
改完 grub 和配置文件后，不重启也能确认内核参数是否加载成功：
- 执行
cat /proc/cmdline，看输出里有没有net.ifnames=0 biosdevname=0 - 执行
udevadm control --reload-rules && udevadm trigger，然后ip link—— 此时设备名仍是ens33，因为 udev 规则已固化，必须重启才能让内核用传统命名方式初始化 PCI 设备
所以别折腾“热切换”，该 reboot 就 reboot。真正麻烦的是多网卡环境——每块卡都要单独重命名配置文件，且确保 NAME/DEVICE 和文件名严格一致，否则第二块网卡（比如想叫 eth1）会静默失效。
