新手遇到服务器半夜宕机，先别急着干等，第一步应该做的不是重启，而是判断问题范围：只有你一个人打不开，还是所有人都打不开。这一步能在三分钟内区分是网络线路问题、域名解析问题，还是服务器本身真的挂了，搞清范围再动手，大概率能自己救回来一半的故障。
服务器宕机原因排查：先判断是真死还是假死
半夜爬起来处理服务器,最怕的不是问题严重，而是乱操作把能解决的问题变成不能解决的，业内专家的常见建议都是先观察、再判断、最后动手，别一上来就点重启，强制重启可能让磁盘文件系统出问题，反而把轻症拖成重症。
先看二层症状：打不开到底是哪一端的事
服务器宕机给人的第一信号往往是“网站打不开”“后台登不上”，但这个现象本身有好几种可能：
- 网络线路问题：本地网络到服务器机房的链路断了，物理机和软件环境都正常，纯输电线路的锅。
- 域名解析问题：域名服务商那边生效异常，或本地DNS缓存了旧的解析记录，服务器IP本身是通的。
- 服务器系统问题：操作系统卡死、CPU打满、内存耗尽、磁盘满，导致服务进程被终止或系统无法响应。
- 数据中心侧故障：机房断电、母机故障、网络交换机故障，这类属于基础设施问题，你本地做什么都没用。
- 安全攻击：服务器被持续的流量攻击打瘫，带宽被占满，或者系统被入侵后崩溃。
快速诊断三连：ping、telnet、浏览器
先做三项基础检查,耗时不超过三分钟：
- 在本地电脑打开命令行,执行
ping 你的服务器IP，看丢包率和延迟情况，如果完全超时，说明服务器在网络层不可达。 - 执行
telnet 你的服务器IP 22（Linux）或telnet 你的服务器IP 3389（Windows），看远程管理端口是否响应，如果能连上，说明操作系统大概率还活着。 - 用手机自带的流量访问你的网站域名,避免本地Wi-Fi线路干扰，如果移动网络也打不开，说明问题更可能出在服务器侧。
确认服务器还能不能登录：决定下一步操作
当确认不是本地网络问题时,下一步就是判断你还有没有“抓手”进入服务器，这里有个新手容易踩的坑：以为ping不通就彻底没戏了，其实很多服务器默认禁ping，但SSH端口是通的。
先试SSH登录，别急着物理重启
在电脑上执行 ssh root@你的服务器IP，如果出现输入密码的提示，恭喜你，系统内核还活着，只是某个服务或某项资源出问题了。
- 能登录：进入系统后立刻执行排查命令，看是谁把资源吃满了，按顺序逐项检查。
- 连接超时：说明系统级网络栈卡死了，或者端口被防火墙封了，需要走服务商的控制台。
- 连接被拒绝：SSH服务本身挂了，但系统还在，可以通过服务商网页终端进入。
如果登录不上，服务商控制台是你的最后底牌
打开云服务商的官网,找到“控制台”或“实例管理”，一般都能看到两种后备通道：
- 网页版VNC终端：模拟一个显示器画面，不需要绕开SSH端口，直接在网页上操作。
- 安全组规则检查：确认是否误改了防火墙规则，把22或3389端口拦了，多数情况下，这类“打不开”其实是安全组配置变动引起的。
服务器cpu100%排查：从登录后第一眼开始
登录成功后,不要乱翻日志，按顺序执行四个命令，把系统当前状态摸清楚，这条路径经过大量运维实践验证，顺序不能乱，先看负载再看进程，最后清内存。
查看系统平均负载和CPU占用
先执行 uptime，看load average的三个数值，如果数值明显超过CPU核数，说明系统确实在高负荷运行。
再执行 top，按大写的P键按CPU占用排序，观察前几行：
- 如果某个Java或MySQL进程CPU占用一直稳在100%以上，基本可以锁定嫌疑对象。
- 如果CPU总量不高但load很高,说明大量进程在等待磁盘I/O，问题不在计算而在存储。
- 如果存在多个D状态（不可中断睡眠）的进程，需要重点检查存储设备是否掉盘或卡IO。
清理积压进程的触发命令
找到占用最高的进程后,记下PID，然后执行 ps aux | grep PID 确认这个进程到底是什么业务，确认无误后，执行 kill -9 PID 强制终止。
如果是MySQL或Nginx这类核心服务,不要直接杀进程，先尝试 systemctl restart mysql 这类温和重启方式，不行再考虑Kill。
内存不足导致的问题怎么识别
执行 free -m，看交换分区和实际内存的使用情况：
- 如果可用内存所剩无几,日志里又看不见明显报错，大概率是物理内存耗尽后系统在疯狂使用交换分区。
- 临时释放内存的做法是重启挂掉的进程,长期方案是加内存或排查内存泄漏。
- swap的使用率如果持续高位,说明业务负载已超过配置，需要认真评估扩容。
磁盘满了和文件数耗尽也会导致服务器宕机
这类问题在低配服务器上很常见,日志文件、临时文件、缓存文件日积月累，把磁盘空间和inode数字吃光了，系统不会主动提醒你，直到彻底写不进去新文件才崩溃。
用df和df -i确认磁盘状况
执行 df -h 能看到文件系统使用率，执行 df -i 能看到inode总数占用，两者要结合起来看，空间充足并不代表inode够用，大量小文件会耗尽inode数量。
- 空间满：用
du -sh /var/log/之类命令找出具体占用大头，删除旧日志或归档到别的存储。 - inode满：用
find / -xdev -type f | wc -l统计文件数量，定位到存放海量小文件的目录后，清理无用临时文件。 - 磁盘性能下降：执行
iostat -x 1，观察%util数值，持续100%说明存储IO已经严重阻塞，多半需要联系服务商检查底层的物理磁盘。
日志文件占满磁盘的典型场景
每晚跑备份任务的服务器最容易出这类问题,备份脚本不清理旧压缩包，日志切割策略没配置，几天就能把磁盘塞满，处理的方法是：
- 删除超过保留期的定期备份文件,按天或周设置自动清理。
- 对Nginx或Apache的访问日志配置日志轮转,定期切割，不要等到手动清理。
- 关闭无用的应用调试日志,多数情况下生产环境不需要记录DEBUG级别的信息。
服务器宕机怎么解决：手机远程操作的几条实际路径
新手大半夜被电话叫醒,身边不一定有电脑，别慌，手机基本能支撑完成七成以上的紧急处理操作，以下几类工具足够在断网断电的边缘把系统拉回来。
手机上装SSH客户端，比想象中靠谱
iOS安装Termius,Android安装JuiceSSH，这类工具支持密钥登录和密码登录，在手机上就能执行所有本文提到的命令，操作方式和电脑上没有本质区别，只是键盘小一些、执行速度慢一些，注意力要更集中。
- 保存好你服务器的公网IP、SSH端口、用户名和密码，存在工具的记录里。
- 创建隧道路径,先在手机上跑
uptime和top确认状态，再决定后面怎么办。 - 屏幕横过来显示,能多看到几行进程列表，操作效率提升明显。
服务商App也能应急
主流云厂商的运维类App都支持基础的实例状态查看和远程连接,有的可以直接在手机上打开网页版VNC终端，App里的告警信息也能帮你判断是资源耗尽、网络攻击还是硬件故障。
- 尝试在App里执行“重启实例”操作，如果系统已经无响应，这是最后的手段。
- 在App里查看监控图表,能帮你确认宕机的时间节点和资源趋势，方便后续排查根因。
强制重启的底线规则
如果确认操作系统已经完全无响应,重启实例是可以接受的，但要遵守一个底线规则：连续重启次数不要超过两次，强行重启第一次通常能解除僵死状态，如果重启后依然异常，说明问题出在配置或硬件层面，反复重启只会加速磁盘损坏。
服务器暂不重启时的临时抢救措施
有时候业务不能直接中断,比如正在跑一个长时间任务，重启会导致任务数据丢失，这时候只能做有限的临时处置，争取时间等到白天用户量减少再正式修复。
终止占用资源最多的进程
在top里找到占用最高的进程,先看一下是不是核心业务，如果是备份任务、日志压缩工具、数据处理任务这类可中断的进程，直接终止能立刻释放大量资源。
临时丢包Nginx的请求
如果服务器的流量压力来自外部,执行 systemctl stop nginx 暂时停掉Web服务，让后端应用有时间消化积压的请求，但这种操作只能维持几分钟，需要快速评估流量性质。
给系统降载的常见操作
重启php-fpm释放所有残留的PHP进程、清空Redis或Memcached缓存数据、停止cron里的定时任务调度，这些操作的共同点是：内存和CPU会被快速释放，代价是部分临时数据会被清掉，不影响最终一致性。
服务器宕机处理结果复盘与预防
服务器救回来了,不等于事情结束了，白天把前因后果梳理清楚，能显著降低下次再被半夜叫醒的概率，不少运维事故是同一根因反复触发，一套手动排查流程解决不了根因问题。
排查重点记录
记录宕机时间、处理过程、CPU和内存峰值变化、关键日志片段，云平台一般都有时间轴视图，把这些数据对起来看，很容易发现端倪。
建议配置监控和阈值告警
现在主流云监控都支持自定义CPU阈值、内存阈值、磁盘使用率阈值，配置好后在资源接近临界点时就会通过电话或短信通知，别等到服务器资源耗尽才处理，提前半小时发现和彻底宕机后的影响是完全不同的。
定期检查系统日志和备份恢复
每月的定期维护中,把系统日志和业务日志翻一遍，看看有没有异常的报错记录，对关键配置文件和数据库做异地备份，保证备份内容在测试环境是可恢复的，不做验证的备份没有任何意义。
Q&A：关于半夜服务器宕机的频繁疑问
服务器半夜宕机，第二天重启后还要检查什么？
登录系统后,先看日志里有没有硬件级的报错，以dmesg的输出为主，然后检查所有自启动服务是否正常运行，可能需要手动启动一部分依赖延迟就绪的网络和数据库的服务，最后确认核心服务版本和最近配置变更记录，消除因配置修改导致宕机的可能性。
云服务器拒绝SSH连接但网站能打开是什么原因？
SSH服务自身挂掉是首要怀疑对象,其次检查安全组和防火墙是否在原有的放行规则之外误加了限制，系统负载过高会拒绝新连接，这个也能通过服务商控制台确认，还有一种低频原因是SSH连接数达到上限，需要清理断开不用的旧会话。
低配置云服务器频繁宕机是否只能靠加钱升级？
加配置是直接方案,但不是唯一方案，检查一下业务本身是否有内存泄漏，例如Java进程的堆内存设置不合理、Redis持久化设置过于频繁等，先用便宜的方式把代码和配置层面问题解决，再根据实际业务峰值决定升级到哪个档位，选购前咨询客服关于突发性能实例和稳定性能实例的差别，能让你花更少的钱买到更匹配的资源。