当我的服务器突然”失联”：一次公网IP冲突的血泪实录

大家好，我是33blog的运维老司机。今天要分享的是上周亲身经历的一场”灵异事件”——我们的生产服务器突然从公网神秘消失，排查过程堪比侦探破案。如果你也遇到过服务器突然失联的情况，这篇实战记录或许能帮你少走弯路。

1. 平静的周三早晨

那是个普通的周三，我正喝着咖啡检查监控面板。突然，企业微信炸了——客服团队反馈客户无法访问我们的API服务。我第一反应是：”又双叒叕被DDoS了？”

但监控显示CPU、内存、带宽一切正常，服务器内网SSH连接畅通。诡异的是，从外部网络ping公网IP完全不通，就像这个IP从未存在过：

# 来自外部网络的测试
$ ping 203.0.113.88
Request timeout for icmp_seq 0...
Request timeout for icmp_seq 1...

2. 排查开始：自底向上大作战

我立即启动标准排查流程：

• ✅ 服务器本地ifconfig显示IP配置正常
• ✅ 本地ping 8.8.8.8外网畅通
• ❌ 从外部traceroute在运营商骨干网就断了

这时候我后背开始冒汗——这症状太像IP被回收了。但联系云厂商后，对方坚称IP仍在我们的账户下。

3. 转折点：ARP日志里的蛛丝马迹

在几乎要重装系统时，我鬼使神差地检查了arp -a，发现网关MAC地址与正常情况不符！更可怕的是，这个MAC对应的厂商居然是某家竞争对手：

# 异常ARP记录
? (192.0.2.1) at 00:1a:79:xx:xx:xx [ether] on eth0
# 正常应该是 00:1a:79:yy:yy:yy

瞬间醍醐灌顶——这是经典的公网IP冲突！有人错误配置了和我们相同的公网IP。

4. 解决之道：MAC地址大作战

临时解决方案很暴力但有效：在服务器上手动绑定正确的网关MAC：

# 清除错误缓存
arp -d 192.0.2.1
# 强制绑定正确MAC
arp -s 192.0.2.1 00:1a:79:yy:yy:yy

服务立即恢复！但这是治标不治本。最终通过运营商协调，对方承认是新上架的设备配置错误，耗时6小时的事件终于落幕。

5. 经验总结

这次事件教会我几个重要经验：

1. 公网IP冲突比想象中更常见（特别是跨运营商时）
2. ARP日志是网络问题的”显微镜”
3. 提前记录关键网络设备的基准MAC地址
4. 云厂商控制台显示的IP状态≠实际路由状态

现在我们的监控系统新增了ARP监控项，算是因祸得福。如果你有类似的惊险经历，欢迎在评论区分享交流~