服务器停止响应这个说法本身比较模糊，可能网站打不开，SSH无法连接，甚至ping都不通。不同层面的故障，排查思路完全不一样。不少人遇到问题第一反应就是重启服务器，但重启只能临时解决一部分问题，很多时候重启几分钟故障复发，根本没有定位根源。
先区分故障层级。最外层是网络不通，本地ping服务器IP，如果ping直接超时，数据包根本抵达不了服务器，或者服务器收到包之后没有返回。这类情况可能是机房网络故障、IP封禁，或是服务器整机死机。ping正常但SSH连不上，问题落在系统层面，SSH服务异常、防火墙拦截22端口，或是系统负载过高拒绝新建连接。SSH能够登录，网站打不开，则是Web服务或者数据库的问题。三层故障排查方向不一样，混在一起处理只会浪费时间。
从外层网络开始排查。ping不通的时候，先不要直接提交工单给机房，确认是不是本地网络问题。切换手机热点测试，或者使用在线ping工具，从多个外地节点检测。多地ping全部超时，基本确定服务器侧故障。这时登录服务商后台控制台，查看是否有VNC、IPMI这类带外管理功能。带外管理独立于操作系统，只要服务器通电就能接入，可以直接查看屏幕报错。如果带外管理也无法连接，大概率硬件故障或者机房断电，直接提交工单联系服务商。
ping通但SSH连接失败，是比较常见的故障。先确认SSH端口有没有被修改，不少加固过的服务器会更换默认端口。端口无误，用telnet检测22端口连通性。端口不通，大概率防火墙拦截，或是SSH服务本身停止运行，这种情况依旧依赖带外管理登录排查。登录后先查看系统负载，uptime输出的前三个数值，如果远高于CPU核心数量，代表进程把系统资源耗尽。执行top查看占用CPU和内存的进程。还有一种情况是磁盘占满，根分区100%时，系统无法写入日志，SSH自然无法新建连接，df -h可以快速查看磁盘占用。
SSH正常但网站打不开，问题范围缩小到Web服务。先检查Nginx或者Apache进程状态，systemctl status nginx查看运行状态。进程终止，查看错误日志，日志路径一般在/var/log/nginx/error.log。常见诱因包括配置文件写错、SSL证书过期、端口被占用。进程正常运行网站依旧打不开，在服务器本地执行curl localhost测试，本地访问正常但外网无法打开，属于防火墙或者安全组问题。安全组是云服务商层面的防火墙，和系统内部iptables相互独立，很多人修改系统防火墙，忘记调整安全组，长时间找不到故障原因。
数据库引发服务停止响应也很典型。网站可以打开，页面持续转圈最终超时，大多是数据库查询卡住。MySQL常见场景，一条慢查询锁住数据表，后续请求排队等待锁，数据库连接数快速占满，新请求无法接入数据库。执行show processlist，能看到大量Waiting状态查询。紧急处理手段是kill掉这条慢查询，治本需要增加索引或者优化SQL语句。另一种情况是连接数上限设置过小，max_connections参数偏低，业务流量上涨后资源耗尽。调大参数可以临时缓解，更关键的是检查代码有没有连接泄漏，打开数据库连接之后没有正常关闭。
还有一类故障和硬件相关。服务器可以ping通，SSH登录之后操作卡顿，输入命令等待数秒才返回结果，大概率硬盘异常。dmesg输出大量I/O报错或者SMART告警，立刻备份数据，准备更换硬盘。内存故障也会造成系统行为异常，进程莫名终止、内核报错，检索/var/log/messages里面OOM killer相关记录，出现这类日志就是内存资源耗尽。
排查要遵循从外到内、由简到繁的顺序。先确认网络连通性，再看系统登录状态，接着检查服务进程，最后翻阅日志定位根因。每深入一层，故障范围就缩小。最忌讳跳步排查，一上来直接重装系统，数据丢失，故障根源依旧存在。日志是最重要线索，系统日志、Web日志、数据库日志，故障发生第一时间查看日志，远比盲目猜测靠谱。平时提前配置监控，CPU、内存、磁盘、带宽设置告警阈值，问题刚出现就能收到提醒，不用等到服务器完全失联再紧急处理。