“device or resource busy”是内核硬性限制：接口up时驱动正收发帧，禁止修改mac以防未定义行为；必须严格按down→address→up三步执行，跳过任一步均失败。
为什么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 02:aa:bb:cc:dd:ee（注意用02开头，确保第0位为0单播、第1位为1本地管理） sudo ip link set dev eth0 up
跳过任意一步，都会失败。写成state down或只改address不关接口，报错可能是RTNETLINK answers: Invalid argument，而不是busy。
改完ip link show显示新值，但实际发包还是旧MAC
ip link show读的是内核软状态，不代表真实发出帧的源地址。尤其在云平台（如 AWS 的 ens5）、某些虚拟化环境或启用了 MAC 白名单的交换机上，硬件/驱动/hypervisor 会拦截非白名单地址并静默丢包。
分层验证才可靠：
- 第一层：
ip link show eth0 | grep "link/ether"确认内核已接受新值 - 第二层（关键）：
sudo tcpdump -i eth0 -c 1 -e | head -1抓一个出向包，看首行冒号分隔的六组十六进制是否匹配你设的值
如果第一层对、第二层错，说明底层拒绝了变更——此时任何配置文件修改都无效，得换平台或联系管理员。
NetworkManager 会在几秒内悄悄把你刚设的MAC还原
如果你用ip link set临时改完就up，而网卡正由NetworkManager管理，它大概率在 2–5 秒内检测到“配置不一致”，自动 reload 连接并恢复原始 MAC。
临时规避方法只有两个：
- 改之前停服务：
sudo systemctl stop NetworkManager，操作完再start - 用
nmcli正规修改：nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address 02:aa:bb:cc:dd:ee，然后nmcli connection down "Wired connection 1" && nmcli connection up "Wired connection 1"
注意：nmcli device show eth0 | grep HWADDR 才是 NM 认可的当前值，不是ip link的输出。
防追踪场景下最容易被忽略的细节
防追踪的核心不是“改得快”，而是“不露破绽”。很多用户改完就以为万事大吉，结果被后端设备通过其他特征识别出来：
- 别用
00:11:22:33:44:55这种整数地址——00:11:22是 Realtek 的 OUI，同网段撞车概率不低，且故障难定位 - DHCP 租约没刷新：MAC 变了但 IP 还是旧的，服务器一看“同一IP换MAC”，立刻标记异常
- ARP 表残留：局域网其他设备缓存着旧 MAC→IP 映射，可能发错包，表现为间歇性丢包
真正麻烦的从来不是命令敲错，而是改完之后，你不知道该信ip link、nmcli还是tcpdump——得靠分层抓包确认真实出口帧，否则所谓“防追踪”只是自我安慰。
