记一次极其诡异的 Linux 断网排错：从硬件到系统的全链路排查

最近遇到一件让人头秃的事儿：一台跑得好好的 Linux 服务器突然就断网了。既不是防火墙拦截，也没有明显的报错，就是彻底失联。经过一番“福尔摩斯式”的排查，终于把问题解决。今天就把这次排错的过程整理成一篇实战笔记，下次再遇到类似情况，大家可以少走弯路。

第一步：先别急着重启，从硬件和物理层查起

刚开始怀疑是猫或者网线问题，但是 ping 内网其他机器是通的，排除物理链路故障。接着检查网卡状态：

ip link 显示网卡是 UP 状态，但是 ping 外网地址（比如 8.8.8.8）完全不通，也没有任何返回包。这时候心里有点慌，不会是中毒了吧？

网络排查往往需要从物理层开始，确保连接无误。

第二步：看系统日志，寻找蛛丝马迹

直接上 dmesg | grep -i eth 和 journalctl -xe 查看内核日志。结果发现一条异常记录：

br0: port 1(veth123) entered blocking state

原来是虚拟网卡卡住了！这台机器上跑着 Docker，之前为了方便管理，配置了虚拟网桥。重启 Docker 服务后，网络居然恢复了。但好景不长，半小时后又断网了。

检查路由表是否冲突是解决网络问题的关键步骤。

第三步：排查路由表和网关配置

既然重启 Docker 治标不治本，那就深入看路由表。ip route show 发现有两条默认路由冲突：

• 一条指向物理网卡的网关
• 另一条指向 Docker 创建的虚拟网桥

系统在路由时产生了歧义，导致部分流量走丢了。解决方案是在 Docker 配置里禁用默认路由注入（--iptables=false），并手动清理无效路由：

ip route del default dev docker0

第四步：防火墙和 NAT 规则的影响

修好路由后，还有一个坑：内网能通，但公网 IP 无法访问。检查 iptables -L -n -v 发现 nat 表规则被重置了。由于 Docker 启动时覆盖了默认的 POSTROUTING 规则，导致出站流量没有正确 SNAT。

最后手动添加一条 MASQUERADE 规则才彻底搞定：

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

总结

Linux 断网的原因千奇百怪，但排查思路其实是有迹可循的：

1. 先确认物理链路和驱动状态
2. 看内核和系统日志里的异常
3. 检查路由表是否冲突
4. 最后关注防火墙/NAT 规则

遇到问题别慌，照着这几步来，大概率能找到原因。大家有没有遇到过更诡异的断网情况？欢迎在评论区交流！