arping必须从另一台同网段主机运行，不能在本机检测自身IP冲突，因Linux内核会对本机IP的ARP请求强制应答，掩盖真实冲突；需用sudo arping -c 5 -I eth0 192.168.1.100在第三方主机探测，若输出多条不同MAC的Unicast reply即确认冲突。
arping 必须从另一台同网段主机运行
你不能在本机用 arping 检测自己正在使用的 IP 是否冲突——Linux 内核会对发给本机 IP 的 ARP 请求强制应答，哪怕该 IP 已被别人占用。结果永远显示“通”，完全掩盖真实冲突。
必须换一台同网段、能通信的 Linux 主机（比如跳板机、测试机），执行探测：
-
sudo arping -c 5 -I eth0 192.168.1.100：明确指定网卡和目标 IP，发 5 次请求 - 目标 IP 必须与探测机在同一子网，且物理链路可达（不能跨 VLAN 或被 ACL 拦截）
- 如果目标设备设置了
arp_ignore=1（常见于 VIP 高可用场景），可能不响应；此时需配合tcpdump -i eth0 arp看是否真没包，还是策略过滤了
看输出判断是否冲突
arping 输出里出现多条不同 MAC 的 Unicast reply 就是铁证。关键不是“谁先响”，而是“谁不该响”：
- 只有一行
Unicast reply from 192.168.1.100 [xx:xx:xx:xx:xx:xx]→ 该 IP 当前唯一 - 出现两行及以上，MAC 不同（如
[40:f4:ec:76:79:c2]和[50:7b:9d:25:29:59]）→ 确认冲突 - 完全无输出或超时 → 该 IP 可能空闲，但也可能是目标关机、禁 ARP、或网络不通，不能直接断定安全
快速定位冲突源设备
知道有冲突还不够，得找出哪个设备在冒用 IP：
- 先确认你配置该 IP 的设备真实 MAC：
ip link show dev eth0 | grep link/ether - 比对
arping结果中哪个 MAC 与之不符——那个就是抢占者 - 用
arp-scan --interface=eth0 --localnet | grep扫描全网，查该 MAC 对应的 IP（注意：需 root，且可能触发交换机端口安全告警） - 若扫不到，可能是抢占设备离线、休眠，或 MAC 被伪装（某些 IoT 固件刷写后 MAC 错乱）
别忽略容器和多网卡场景
冲突常藏在边缘位置：
- Docker 容器内跑
arping前，先确认是否装了iputils-arping（Debian）或iproute2（Alpine），并确保容器有NET_RAW权限 - 宿主机多个网卡（如
eth0和ens33）连同一网段时，若未设arp_ignore=1，会同时应答同一个 IP，表现为“MAC 跳变”，这不是外部冲突，而是内核行为 - 排查时优先用
ip neigh show替代arp -n，它更准、状态更细（如STALE/FAILED切换可提示不稳定应答）
实际操作中最容易被跳过的，是验证探测机自身网络路径是否干净——比如你用跳板机去测，结果发现它自己也配了同网段静态 IP，或者它的网关 ARP 缓存已污染，那所有 arping 结果都不可信。
