必须先执行sudo ip link set dev eth0 down，再sudo ip link set dev eth0 address aa:bb:cc:dd:ee:ff，最后sudo ip link set dev eth0 up；内核禁止up时修改mac，因驱动正收发帧，强行修改将引发未定义行为。
直接改 ip link set 是最稳妥的临时方案，但必须严格按 down → address → up 三步执行；跳过任意一步，Device or resource busy 或静默失败是常态。
为什么 ip link set dev eth0 address 报 “Device or resource busy”
内核禁止在接口 UP 状态下修改 MAC，因为底层驱动可能正收发帧，强行改会触发未定义行为。这不是权限或语法问题，而是强制设计约束。
- 必须先执行
sudo ip link set dev eth0 down - 再执行
sudo ip link set dev eth0 address aa:bb:cc:dd:ee:ff - 最后执行
sudo ip link set dev eth0 up - 写成
state down或只改address不关接口，都会报RTNETLINK answers: Invalid argument
改完发现网络断了，但 ip link show 显示 MAC 已变
MAC 地址确实改成功了，但网络层没恢复——常见于 DHCP 连接未重续租约，或 IP 地址仍沿用旧配置。
- 检查接口状态：
ip link show eth0 | grep "state "，确认是UP而非DOWN - 查看是否有 IP：
ip addr show eth0 | grep "inet "，若为空，需手动运行dhclient eth0或配置静态 IP - 别误判为“改 MAC 导致断网”，本质是网络栈未同步刷新
怎么验证 MAC 真生效，而不是界面骗人
ip link show 只读内核软状态，不能代表真实发出帧的源地址。有些云平台（如 AWS 的 ens5）或虚拟化环境会拦截非白名单 MAC 并丢包。
- 第一层验证：
ip link show eth0 | grep "link/ether"，看输出是否为你设的值 - 第二层验证（关键）：
sudo tcpdump -i eth0 -c 1 -e | head -1，抓一个出向包，检查首行里冒号分隔的六组十六进制数是否匹配 - 若
ip link显示新值，但tcpdump仍是旧值，说明硬件/驱动/hypervisor 拒绝了变更，此时任何配置文件修改都无效
NetworkManager 会悄悄覆盖你刚设的 MAC
如果你用 ip link set 临时改完就 up，而网卡正由 NetworkManager 管理，它可能在几秒内检测到“配置不一致”，自动 reload 连接并还原原始 MAC。
- 临时规避：改之前停掉服务
sudo systemctl stop NetworkManager - 持久化方案：
nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address aa:bb:cc:dd:ee:ff，再nmcli connection down "Wired connection 1"&&nmcli connection up "Wired connection 1" - 注意：修改后
nmcli device show eth0 | grep HWADDR才是 NM 认可的当前值，不是ip link的输出
真正麻烦的从来不在于命令敲错，而在于你改完没验证真实发包地址，也没考虑 NetworkManager 或 hypervisor 的干预——这两点最容易被忽略，也最难排查。
