云主机网络中断如何排查?

凌晨一点，我正在看一部电影，手机突然弹出一条监控告警：服务器宕机。我赶紧打开云服务商控制台，云主机状态显示“运行中”，但网站打不开，SSH也连不上。我用另一台服务器去ping这台云主机的IP，全部丢包。那一刻，我脑子里闪过无数个可能：是被攻击了?是云服务商网络故障?还是我自己把网络配置搞砸了?

那是我第一次真正面对云主机网络完全中断的情况。没有SSH，没有Web访问，甚至连ping都不通，感觉就像这台机器从互联网上消失了一样。我花了将近两个小时才把问题定位清楚，最后发现是云服务商的一个上层交换机出了问题，影响了同机架的部分云主机。虽然最终不是我的配置问题，但那两个小时的排查过程让我深刻体会到：网络中断不可怕，可怕的是没有一套系统的排查思路，像无头苍蝇一样乱撞。

今天我就把自己这些年在云主机网络中断问题上积累的排查经验，从头到尾梳理一遍。下次你的服务器突然“失联”了，希望这篇文章能帮你少走一些弯路。

网络中断到底是什么样的?

先明确一下“网络中断”的范围。它可能表现为：完全无法访问，网站打不开，SSH连不上，ping不通。也可能是部分中断，比如网站能打开但SSH连不上，或者从某个地区能访问但从另一个地区不能。还可能表现为服务异常，比如连接超时、丢包严重、延迟飙升，虽然没有完全断开但已经无法正常使用。

不同的表现对应不同的排查方向。完全中断通常意味着网络层的连通性出了问题，比如IP被封、路由丢失、防火墙拦截。部分中断则可能是端口级别的限制，或者DNS解析异常。丢包严重则可能是带宽打满、网络拥塞或者链路质量差。

我见过最诡异的一次网络中断，是客户的网站只有移动宽带的用户打不开，电信和联通都正常。客户怀疑是服务器的问题，但我用拨测工具从全国各地测试，发现只有移动网络节点的访问全部超时。最后查出来是移动运营商的一个骨干网节点出现了故障，跟服务器没有任何关系。这个案例告诉我们，网络中断的根因不一定在你的服务器上，可能在中间的任何一个环节。

排查前的准备工作

在开始排查之前，有几样东西你需要提前准备好。一是云服务商控制台的访问权限，因为很多排查操作需要在控制台上完成，比如查看监控数据、修改安全组规则、使用VNC远程连接。二是另一台可以正常访问互联网的机器，最好和出问题的云主机在同一个地域或者同一个账号下，用来做对比测试。三是你的手机热点或者另一个网络环境，因为你当前使用的网络可能恰好也无法访问这台服务器，换一个网络能帮你判断问题是在客户端还是服务端。

另外，记录下发生网络中断的精确时间点，这个信息在后面查看日志和监控时非常重要。如果你不清楚具体时间，可以问一下第一个发现问题的用户或者同事。

第一步：确认问题到底出在哪一层

网络问题可以从OSI七层模型的角度去分层排查。从底层到上层依次是：物理层、数据链路层、网络层、传输层、应用层。云主机环境下，物理层和数据链路层由云服务商负责，我们主要关注网络层及以上。

一个简单粗暴的方法是从最基础的ping开始。ping使用的是ICMP协议，属于网络层。如果你能ping通，说明网络层是通的，问题可能在传输层(比如端口没开)或者应用层(比如Web服务挂了)。如果你ping不通，说明网络层已经出了问题，可能是路由不可达、防火墙丢弃了ICMP包、或者IP本身不可用。

我自己的习惯是先用ping测试，再用telnet或nc测试特定端口，最后用curl测试HTTP服务。这三板斧走完，基本就能定位到问题出在哪个层级。

有一个细节需要注意：有些云服务商的安全组默认禁用了ICMP协议，也就是说你ping不通不一定是网络中断，可能只是安全组把ping包给拦了。所以不要只依赖ping，还要结合端口测试来综合判断。

第二步：检查云服务商控制台

很多人遇到网络中断的第一反应是登录服务器去查日志，但问题是网络已经断了，你怎么登录?这时候云服务商的控制台就是你最重要的工具。

首先看看云主机的状态是不是“运行中”。有时候网络中断是因为主机被关机了或者重启了，控制台上会显示。其次看看监控面板，CPU、内存、网络流量的曲线图。如果网络出方向或者入方向的带宽突然飙到了峰值，说明可能遭受了DDoS攻击或者流量突增，导致网络拥堵。很多云服务商在检测到攻击流量时会自动触发黑洞清洗，也就是把受攻击的IP临时封禁一段时间。这时候控制台通常会有一条安全告警，告诉你IP进入了黑洞状态。

我遇到过一位做游戏服务器的客户，他的服务器突然全网无法访问。登录控制台一看，监控显示入带宽在事发前五分钟飙到了几个G，远远超过了服务器配置的带宽上限。再一看安全事件记录，果然有一条DDoS攻击告警，IP被黑洞封禁了两小时。这种情况你除了等待黑洞自动解除，或者购买高防IP服务，别的什么也做不了。至少你知道不是自己的配置问题，可以给用户一个明确的答复。

另外，检查一下云服务商的状态页。主流云厂商都有公开的服务健康状态页面，如果某个可用区或者某个产品出现了大面积故障，状态页上会有公告。有时候网络中断不是你一个人的问题，是整个区域的问题。这时候你只需要等待服务商修复，自己折腾也没用。

第三步：检查安全组和防火墙规则

如果云主机状态正常，监控也没有异常流量，那就需要怀疑是安全组或者防火墙把流量拦住了。

安全组是云服务商提供的虚拟防火墙，位于云主机的外部。你在控制台上添加的规则决定了哪些源IP、哪些端口可以访问你的云主机。最常见的配置错误是把SSH端口22的源IP限制成了某个特定的IP，而你现在正从一个不同的IP登录，自然就连不上。另一个常见错误是忘记添加80和443端口的入站规则，导致网站无法访问。

我记得有一次帮一个客户排查，他的网站突然打不开了，但SSH能连上。我检查了Nginx和PHP-FPM，都在正常运行。最后打开安全组规则一看，80端口的入站规则不知道被谁删掉了。重新添加之后，网站立刻恢复。客户回忆说，他之前为了测试某个东西临时删了这条规则，测试完忘记加回去了。所以检查安全组一定要仔细，看看规则是否完整、源IP是否正确、协议类型是否匹配(TCP还是UDP)。

除了云服务商的安全组，云主机内部也有防火墙软件，比如iptables或者firewalld。如果你能通过VNC或者控制台提供的远程连接功能登录到服务器，可以执行iptables -L -n查看当前规则。看看有没有DROP或者REJECT的策略，特别是针对INPUT链的。有时候你可能会不小心执行了iptables -P INPUT DROP，把所有的入站流量都拒绝了。这时候需要执行iptables -P INPUT ACCEPT来恢复。如果你用的是firewalld，执行firewall-cmd --list-all查看当前区域和规则。

第四步：检查云主机内部的网络配置

如果能通过VNC或者救援模式进入系统，接下来要检查系统内部的网络配置是否正常。

先用ip addr命令查看网卡是否获取到了IP地址。云主机通常使用DHCP获取内网IP，如果你手动修改了网卡配置文件，可能会导致IP地址丢失。另外确认一下网卡状态是否是UP，ip link set eth0 up可以启用网卡。

再用ip route查看路由表，确认默认网关是否正确。云主机的默认网关通常是内网网段的第一个地址，比如内网IP是10.0.0.5，网关就是10.0.0.1。如果路由表里没有default条目，或者网关地址错误，数据包就出不去。可以尝试手动添加默认路由：ip route add default via 网关地址。

还有一个容易被忽略的点是DNS配置。虽然DNS故障不会导致网络完全中断，但会导致域名无法解析，看起来就像网站打不开一样。查看/etc/resolv.conf文件，确认里面配置了可用的DNS服务器。你可以用nslookup或者dig命令测试一下域名解析是否正常。如果DNS出了问题，可以临时换成公共DNS，比如1.1.1.1或者8.8.8.8。

另外检查一下ARP表，看看网关的MAC地址是否正确。有时候ARP表被污染或者过期，会导致二层不通。执行arp -n查看ARP缓存，必要时用ip neigh flush all清空ARP表让它重新学习。

第五步：从外部进行路由追踪和端口扫描

如果以上检查都没发现问题，但网络还是不通，那就需要从外部来探测网络路径了。这时候你需要另一台机器，可以是你的本地电脑，也可以是另一台云主机。

用traceroute(Windows下是tracert)命令追踪路由，看看数据包到了哪一跳之后就没有响应了。比如你从本地traceroute到云主机的IP，如果路由在某个运营商的节点上停止响应，说明问题出在那个节点或者之后。如果你从另一台云主机traceroute，结果完全不通，那可能是云服务商内部网络的问题。

我曾经遇到过一个问题，从我的本地网络traceroute到服务器，数据包在经过某个运营商的节点后全部超时。我换了一个不同运营商的网络测试，发现可以正常到达。这说明问题出在第一个运营商和云服务商之间的互联节点上。我联系了云服务商的技术支持，他们确认是该运营商的路由出现了问题，正在修复。这种情况下，除了等待或者切换网络线路，没有别的办法。

用nmap或者nc从外部扫描服务器的端口，看看特定端口是否开放。比如从另一台机器执行nc -zv 你的IP 22，如果连接成功，说明SSH端口是可达的，问题可能在应用层。如果连接失败，可能是防火墙拦截或者服务没有监听。注意，扫描端口时要从多个源IP测试，避免因为安全组限制了源IP而产生误判。

第六步：分析云主机内部的日志

如果你能通过VNC或者救援模式进入系统，日志是定位网络中断原因的重要线索。

查看系统日志/var/log/messages或者/var/log/syslog，搜索network、eth0、dhclient、kernel等关键词。看看有没有网卡down掉、DHCP续约失败、内核报错等信息。比如有时候网卡驱动出了问题，内核会打印“eth0： link is not ready”。有时候DHCP客户端因为某种原因没有续约成功，导致IP地址过期。

查看dmesg日志，看看是否有网络相关的错误。我曾经在一台服务器上看到dmesg里反复出现“neighbour： arp_cache： neighbor table overflow!”的错误，这是ARP表溢出了，导致无法学习到网关的MAC地址，网络自然就断了。解决办法是调整内核参数net.ipv4.neigh.default.gc_thresh3，增加ARP表的大小。

另外，如果你的服务器配置了fail2ban或者denyhosts这类安全工具，它们可能会把你的IP加入黑名单，导致你无法登录。检查/var/log/fail2ban.log，看看是否有ban的记录。如果有，可以用fail2ban-client set 规则名 unbanip 你的IP来解封。

一个完整的网络中断排查案例

去年夏天，我接到了一个比较棘手的求助。一个客户的云主机出现了间歇性的网络中断，每天大概会出现两三次，每次持续几分钟到十几分钟不等，然后就自动恢复了。客户非常崩溃，因为他的业务对实时性要求很高，断几分钟就会造成不小的损失。

我先从控制台入手，查看监控发现每次中断发生时，服务器的入带宽都会有一个短暂的尖峰，但尖峰并不高，远没有达到带宽上限。安全组规则和防火墙规则也没有问题。我用VNC登录到服务器，检查了网卡状态、路由表、ARP表，都没发现异常。

然后我从另一台云主机持续ping这台服务器，发现丢包率在中断期间达到了百分之八十以上。我用traceroute追踪，发现数据包在到达服务器的前一跳之后就开始大量丢包。这说明问题不在服务器本身，而在云服务商内部的网络设备上。

我提交了工单，把监控截图和traceroute结果附了上去。云服务商的技术支持经过排查，发现是服务器所在的物理机网卡存在硬件缺陷，在特定流量模式下会出现丢包。他们帮我把云主机迁移到了另一台健康的物理机上，问题彻底解决。

这个案例让我意识到，有些网络中断的根源不在我们可控的范围内，但我们依然需要通过系统的排查来排除自身的问题，才能让服务商帮我们解决底层的问题。

预防网络中断的几个习惯

网络中断不可能完全避免，但你可以通过一些习惯来降低它发生的概率和影响。

第一，为关键服务配置多个IP或者使用负载均衡。单点IP出现故障时，另一个IP可以接管流量。云服务商提供的负载均衡产品可以在后端多台云主机之间分发流量，其中一台网络出问题，负载均衡会自动把流量切到健康的后端。

第二，使用高可用架构。如果你的业务非常重要，可以考虑跨可用区甚至跨地域部署。当一个可用区的网络出现故障，DNS可以解析到另一个可用区的IP，或者通过全局流量管理产品自动切换。

第三，定期备份网络配置。把iptables规则、路由表、网卡配置文件都备份下来。万一哪天你改错了导致网络中断，可以通过救援模式快速恢复。

第四，建立网络监控和告警。不要等用户投诉了你才知道网络断了。使用云监控或者自建监控系统，从多个地域持续ping你的云主机IP，一旦发现连续丢包就立即告警。告警方式要多样化，短信、电话、微信都要配置，确保你能在第一时间收到通知。

第五，熟悉云服务商的救援通道。VNC、串行控制台、救援模式、系统盘挂载，这些功能平时就要知道在哪里开启、怎么使用。不要等到网络断了才去翻文档，那时候每一分钟都是钱。

最后

云主机网络中断是运维工作中最让人焦虑的问题之一，因为一旦网络不通，你就失去了和服务器之间的所有联系，像是被蒙上了眼睛。但只要掌握了正确的排查思路，大多数网络中断都能在较短时间内定位出原因，无论是安全组规则错了、防火墙拦了、网卡配置乱了，还是云服务商底层出了问题。

我总结的排查顺序是：先确认问题现象和范围，然后检查云服务商控制台和监控，再检查安全组和防火墙，接着检查系统内部网络配置，然后从外部做路由追踪和端口扫描，最后分析日志。按这个顺序来，你不会遗漏关键环节，也不会在错误的方向上浪费时间。

记住一个原则：网络中断不一定是你的错，但排查网络中断一定是你的责任。保持冷静，按步骤来，绝大多数问题都能找到答案。希望你的服务器网络永远稳定，但如果哪天它突然“消失”了，希望你能像翻开这本手册一样，从容地把它找回来。