不能在本机用arping检测自身IP冲突，因Linux内核强制应答所有发往本机IP的ARP请求，结果恒为“Reply”，完全失真；必须从另一台同网段、物理可达且ARP缓存干净的Linux主机运行arping，若输出多条不同MAC的Unicast reply即确认冲突。
不能在本机用 arping 检测自己正在用的 IP 是否冲突——Linux 内核会强制应答所有发给本机 IP 的 ARP 请求，结果永远显示“通”，完全掩盖真实冲突。
为什么 arping 必须从另一台同网段主机运行
内核行为无法绕过：arping -I eth0 192.168.1.100 在目标机器上执行，哪怕该 IP 已被别人占用，也会返回 Reply from 192.168.1.100。这不是工具问题，是协议栈设计使然。
真正有效的探测必须满足三个条件：
- 发起方是另一台同子网、物理可达的 Linux 主机（如跳板机、测试机）
- 目标 IP 与探测机在同一广播域（不能跨 VLAN 或被 ACL 阻断）
- 探测机自身未配置该网段其他静态 IP，ARP 缓存干净（否则可能污染结果）
怎么用 arping 判断是否冲突
在第三方主机上运行：
sudo arping -c 3 -w 2 -I eth0 192.168.1.100
关键看输出中的 Unicast reply 行：
- 只有一行
Unicast reply from 192.168.1.100 [xx:xx:xx:xx:xx:xx]→ 当前唯一 - 出现两行及以上，MAC 地址不同（如
[40:f4:ec:76:79:c2]和[50:7b:9d:25:29:59]）→ 确认冲突 - 完全无输出或 timeout → 目标可能关机、禁 ARP、或网络不通，不能直接认为“安全”
发现冲突后怎么快速定位冒用设备
先确认你本机真实 MAC：
ip link show dev eth0 | grep link/ether
再比对 arping 输出中哪个 MAC 不匹配——那个就是抢占者。接着可：
- 用
sudo arp-scan --interface=eth0 --localnet | grep <冲突MAC>扫描全网段，查该 MAC 对应的 IP - 查交换机侧：执行
show arp或show mac address-table，看该 IP 对应几个端口 - 注意边缘场景：Docker 容器需有
NET_RAW权限；宿主机多网卡连同一网段时，若未设arp_ignore=1，会自产“MAC 跳变”，不是外部冲突
容易被忽略的验证前提
很多排查失败，是因为没确认探测机自身状态：
- 探测机是否也配了同网段静态 IP？会导致它自己参与应答
- 它的
ip neigh show缓存里是否已有该 IP 的 stale 条目？建议先ip neigh flush dev eth0 - 是否误用了虚拟网卡（如
docker0、veth*）而非物理网卡？-I参数必须指定真实出口网卡
最常漏掉的一步：在配置新静态 IP 前，不跑一次 arping 验证空闲，也不检查 DHCP 保留池——等业务上线出问题，代价远高于提前 10 秒执行一条命令。
