在Linux内核启动参数中加入net.ifnames=0 biosdevname=0，并重新生成GRUB配置，绝大多数系统都能恢复为熟悉的eth0命名，若此方法失效，多半是网络管理服务或udev规则在作祟，需要针对性排查。
为什么你的网卡不叫eth0
很多朋友在虚拟机里装完Linux,第一眼看到ens33、enp0s3这类名字就懵了，这不是系统抽风，而是systemd引入的可预测命名规则在起作用。
过去的内核靠探测网卡物理位置顺序来编号,启动快、设备少，eth0、eth1挺好用，但服务器网卡多了以后，顺序容易乱，比如拔掉一块网卡再插上，名字可能全变，于是systemd干脆按硬件拓扑信息来命名：
en代表以太网o表示板载设备，比如eno1s表示PCIe插槽位置，ens33就是插在33号槽位的网卡p表示PCI总线地址，比如enp0s3中的0是总线号，3是设备号
这套规则的好处是名字和硬件绑定,不会因为网卡插拔顺序而漂移，但对于单网卡的虚拟机来说，ens33远没有eth0看着顺眼，运维脚本里写eth0也到处报错，行业共识认为，在云主机和虚拟机场景下，保持eth0这类简洁命名仍然有实际价值，尤其是兼容老脚本。
linux修改网卡名称 eth0 的两种主流方法
内核参数法（推荐，适用于大多数发行版）
这是最干净的方法,直接在引导阶段告诉内核：别用可预测命名，用老式的ethX编号。
第一步，编辑GRUB配置文件：
vim /etc/default/grub
找到GRUB_CMDLINE_LINUX这一行，在引号内加上两个参数：
GRUB_CMDLINE_LINUX="... net.ifnames=0 biosdevname=0"不同发行版原来的内容可能不一样,比如CentOS默认带crashkernel=auto，只需要追加，不要删掉原有参数。
第二步，重新生成GRUB引导配置，这一步最容易被忽略，很多人只改了/etc/default/grub没执行下面的命令，重启自然没效果。
- CentOS / RHEL / Rocky / AlmaLinux（BIOS引导）：
grub2-mkconfig -o /boot/grub2/grub.cfg
- CentOS / RHEL 7+（UEFI引导）：
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
- Ubuntu / Debian
：
update-grub
第三步，重启系统，开机后执行ip addr或ifconfig -a，网卡应该已经变成eth0了。
改完参数后重新命名配置文件
内核参数生效后,网卡名变成eth0，但系统里的网络配置文件还是旧名字，比如/etc/sysconfig/network-scripts/ifcfg-ens33，这一步不做，网络照样起不来。
CentOS / RHEL系的操作：
cd /etc/sysconfig/network-scripts/ mv ifcfg-ens33 ifcfg-eth0
然后用vim打开ifcfg-eth0，把NAME和DEVICE两项都改成eth0：
NAME=eth0
DEVICE=eth0Ubuntu 18.04及以下用的是/etc/network/interfaces，不存在单独的配置文件，相对省事，改完内核参数后直接把auto ens33改成auto eth0就行。Ubuntu 20.04及以上用Netplan，需要编辑/etc/netplan/.yaml，把里面的网卡名改掉并执行netplan apply。
centos7网卡eth0改不了？先查这几个原因
很多人在CentOS 7虚拟机里操作完上面几步，发现网卡名还是ens33，或者变成eth0了但网络不通，问题多半出在下面几个环节。
网络管理服务覆盖了你的配置
CentOS 7默认跑NetworkManager，它有自己的连接配置识别逻辑。即使内核参数生效，NetworkManager可能还绑着旧的ens33连接，导致网卡被改名后连接状态丢失。
处理办法是顺手删掉或改掉NM的连接配置：
nmcli connection show nmcli connection delete ens33
如果nmcli connection show里显示的是Wired connection 1这类名字，也一并清理，然后重启NetworkManager：
systemctl restart NetworkManager
顺带提醒,CentOS 7的network.service和NetworkManager同时管理网卡会打架，如果你走的是/etc/sysconfig/network-scripts/老路线，建议直接关掉NetworkManager：
systemctl disable NetworkManager systemctl stop NetworkManager systemctl enable network systemctl start network
udev规则残留导致名字被锁死
CentOS 6时代留下一个好管闲事的文件：/etc/udev/rules.d/70-persistent-net.rules，它会根据MAC地址绑定网卡名，明明内核参数说了要叫eth0，它偏要给你绑定成eth1。
CentOS 7虽然默认不带这个文件，但
很多虚拟机模板、运维脚本会自己生成一个，检查一下：
ls /etc/udev/rules.d/ | grep persistent
如果有,先备份再删除，然后重启。注意，CentOS 8/9已经移除了这个文件的生成逻辑，网上很多旧教程还在教你编辑它，属实是刻舟求剑。
BIOS和虚拟化平台的影响
如果以上都试了还不行,问题可能出在虚拟机平台本身。VMware、VirtualBox在BIOS里暴露的网卡PCI位置信息各不相同，有些型号就是不按常理出牌，这时候可以改用下面说的替代方案。
不想改内核参数时的替代方案
net.ifnames=0是全局开关，一刀切，但有些场景下你只想改某一块网卡的名字，或者内核参数法在特定硬件上失灵，那就得换个思路。
用systemd link文件精准改名
现代Linux系统里,systemd提供了.link文件方案，相当于按MAC地址给网卡自定义名字，创建一个配置文件：
vim /etc/systemd/network/10-eth0.link
如下：
[Match]
MACAddress=00:0c:29:ab:cd:ef
[Link]
Name=eth0保存后执行networkctl reload，重启系统即可，这套方式比udev规则先进，不受net.ifnames参数影响，Match规则匹配的是MAC地址，精准且不会误伤。
具体虚拟机网卡MAC地址怎么看？在VMware里进虚拟机设置 - 网络适配器 - 高级就能看到，或者在系统里执行ip link，会显示link/ether 00:0c:29:xx:xx:xx。
临时改名应急
不想重启,或者只是临时调试用，可以用ip命令直接改：
ip link set ens33 down ip link set ens33 name eth0 ip link set eth0 up
这个改法重启即失效，而且对SSH连接的远程服务器不友好网卡名变了连接会断，适合本地终端操作或使用带外管理（比如VMware控制台、IPMI）的场景。
虚拟机网卡名称修改实操场景与坑点
VMware克隆后网卡MAC变化导致配置失效
这是运维老手也会踩的坑：VMware模板机设好了eth0，克隆十台出来后，所有机器的udev规则或systemd link文件都匹配同一个旧MAC地址，新机器网卡全变成eth1、eth2甚至rename2。
解决方案是克隆完成后、开机之前，在VMware里给每台机器重新生成MAC地址：虚拟机设置 - 网络适配器 - 高级 - MAC地址 - 生成，然后进系统对应更新.link文件的MACAddress=
字段，如果已经开机了，就进入单用户模式或救援模式修改。
KVM/libvirt虚拟机的网卡命名差异
KVM环境下网卡默认走virtio驱动,设备名通常是ens3、ens4，这个数字由PCI槽位决定，和VMware的编号逻辑不同，有些OpenStack镜像干脆直接忽略net.ifnames参数，改用cloud-init的/etc/systemd/network/配置来管理，这时候你改了GRUB参数，重启会发现网卡名没变，因为cloud-init每次启动时可能重新应用网络配置，排查时先看/etc/cloud/cloud.cfg里有没有网络配置相关模块。
改完后网卡起不来
最常见的原因是配置文件里的MAC地址和实际网卡对不上，检查方法：
ethtool -P eth0 ip link
确认无误后,再排查NetworkManager的连接配置是否还残留旧网卡名，多数情况下这两步能解决90%的问题。
Q&A：虚拟机网卡名称怎么修改的常见遗留问题
问：改完内核参数后，Ubuntu 22.04网卡名没变，为什么？
答：Ubuntu 20.04以后引入了/etc/default/grub.d/目录下的配置文件，某些云镜像会在50-cloudimg-settings.cfg里额外设定命名规则，需要检查/etc/default/grub.d/下的文件是否覆盖了主配置，必要时直接修改该文件，再执行update-grub。
问：用systemd link文件改名后，网络管理工具显示的名字没变，算改成功了吗？
答：systemd .link文件的匹配规则要求文件名前缀数字越小优先级越高，且[Match]段必须准确，如果networkctl或ip link显示没变，先执行networkctl reload，再检查是否有更高优先级的.link文件（比如99-default.link）拦截了规则。
问：云服务器（简米云、酷番云）能不能改网卡名？
答：多数云服务器启动时会读取用户数据或使用cloud-init初始化网络，自定义网卡名可能在重启后被云平台重置，部分云厂商的镜像直接编译时去掉了eth0支持，强行改名可能导致网络不通，建议云服务器保持默认命名，只有自建虚拟机环境（VMware、VirtualBox、KVM）适合修改。
改网卡名本质是权衡取舍：eth0简洁顺手，systemd命名严谨防漂移，虚拟机环境里改一改无伤大雅，生产环境多块物理网卡的服务器还是保持默认更稳妥，记住核心操作路径内核参数、GRUB配置、网络配置文件三处对齐，基本就稳了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/629879.html
