查ipconfig/ifconfig仅得本机配置，非真实对外IP；须结合路由表、监听绑定、云元数据、ARP验证及端口探测交叉确认。
服务器巡检时查ipconfig或ifconfig只能看到本机配置，不是真正在用的IP
很多运维人员一进服务器就习惯性敲ipconfig（Windows）或ifconfig（Linux），看到192.168.1.100就以为这台机器对外暴露的就是这个地址。但实际巡检中，这个值常常失效——比如虚拟网卡混用、多网卡绑定未生效、容器网络覆盖了宿主机IP、或者被iptables或nftables做了DNAT转发。更隐蔽的是，某些云平台（如阿里云ENI、AWS ENA）会把真实业务IP藏在辅助弹性网卡或元数据服务里，ifconfig根本不会显示。
真正要确认“当前对外提供服务的IP”，得结合三层和四层信息交叉验证：
- 查路由表：
route -n或ip route show，看默认出口走哪张网卡、对应哪个源IP - 查监听端口绑定：
netstat -tuln | grep :80，观察Local Address列是否为0.0.0.0:80（全网卡）还是127.0.0.1:80（仅本地） - 查云平台元数据（如阿里云）：
curl -s http://100.100.100.200/latest/meta-data/network/interfaces/macs/ | xargs -I {} curl -s http://100.100.100.200/latest/meta-data/network/interfaces/macs/{}/ipv4s
用arp -a反查IP归属比直接看配置更可靠
当怀疑某台服务器IP被冒用或冲突时，光看它自己报出的IP没用。局域网内真正决定通信走向的是ARP缓存——谁响应了ARP请求，谁才被当成那个IP的主人。巡检中遇到“能ping通但SSH连不上”“HTTP返回内容是另一台机器的页面”，大概率是ARP表项错乱。
实操建议：
- 在网关设备（或任意一台同网段管理机）上执行
arp -a | grep 192.168.1.100，确认该IP对应的MAC是否与目标服务器的ip link show输出一致 - 若发现多个不同MAC映射到同一IP，立刻抓包：
tcpdump -i eth0 arp host 192.168.1.100 -w arp-conflict.pcap，过滤出重复应答 - 注意Windows默认不刷新ARP缓存（超时长达15分钟），
arp -d *后重试可能掩盖问题；Linux可用ip neigh flush dev eth0强制刷新
nslookup和dig查DNS记录不能替代真实IP探测
巡检时经常有人用nslookup server01.internal查到10.20.30.40，就认为服务一定跑在这台机器上。但DNS只是名字到IP的映射，不保证IP当前有效或归属正确。尤其在滚动发布、蓝绿部署、K8s Service ClusterIP场景下，DNS指向的可能是VIP、Ingress控制器、甚至CDN节点。
必须补一手真实探测：
- 用
nc -zv 10.20.30.40 22确认SSH端口是否真在响应，且响应主体是预期机器（可加-o StrictHostKeyChecking=no跳过密钥校验） - 对HTTP服务，用
curl -I http://10.20.30.40 --connect-timeout 3并检查Server或X-Powered-By头是否匹配预期 - 若返回
Connection refused但DNS解析正常，说明服务未启动或防火墙拦截；若超时，则IP可能已漂移或网卡down掉
批量巡检时别只依赖ping，arping才是局域网IP真实性判据
ping只能告诉你“这个IP有设备回应ICMP”，但无法区分是目标机器、中间防火墙、还是另一台冒用者。而arping直接发二层ARP请求，收到谁的MAC回复，谁就是当前持有该IP的实体——防火墙拦不住，ICMP策略无效，连Windows Defender都默认放行。
典型用法：
- 单点验证：
arping -c 3 -I eth0 192.168.1.100，看reply来自哪个MAC - 批量脚本中嵌入：
for ip in $(cat ip_list.txt); do echo "$ip: $(arping -c 1 -f -I eth0 $ip 2>/dev/null | grep "Unicast reply" | awk '{print $5}')" ; done - 注意：需root权限；跨VLAN或路由器后不可用，此时必须退回
ping + traceroute + telnet组合
最常被忽略的一点：ARP缓存老化时间（Linux默认30秒）和交换机MAC表老化时间（通常300秒）不一致，会导致巡检窗口内看到的“唯一归属”其实是过期快照。真要锁定冲突源，得连续抓包+比对MAC变动频率，而不是扫一次就下结论。
