网站宕机快速排查流程：网站崩了？这套排查流程救命

做独立站这些年，最怕的就是半夜收到手机监控的推送：“您的网站已无法访问”。那一刻，后脑勺发凉，脑子里的弦立马就绷紧了。作为一名混迹在 Linux 命令行和 SEO 排查一线的老站长，我这些年整理出一套网站宕机快速排查流程。这套流程不是实验室里的理论，而是无数次服务器宕机、SEO 排名暴跌后，我一个一个坑踩出来的“救命经”。今天不聊那些虚头巴脑的，直接上干货，教你在网站罢工时，怎么像个老手一样有条不紊地把它救回来。

第一步：排除“虚假宕机”，别被自己的眼睛骗了

很多新手站长一看到网页打不开，就开始联系空间商投诉，或者胡乱重启服务器。这是大忌。 搞不好只是你家网断了，或者运营商的 DNS 抽风了。

1. 使用第三方拨测工具

你自己打不开，不代表全世界都打不开。先用 itdog.cn、17ce.com 或者国外的 ping.pe 跑一下。

• 现象： 全国/全球红了一大片。
• 结论： 网站真挂了。
• 现象： 只有你所在的地区绿了，或者部分地区变红。
• 结论： 可能是 CDN 节点故障，或者是当地运营商屏蔽。

2. 检查域名解析（DNS）

有时候是域名没续费，或者是 Cloudflare 的解析出了问题。

• 避坑点： 别光看后台域名状态是“Active”，去搜一下域名的 WHOIS 状态。如果显示 clientHold，那是被注册商封禁了，这种时候你折腾服务器一点用都没有。

老站长建议： 即使是自己运维，也一定要挂个监控，比如 UptimeRobot。它能让你在客户投诉之前，先接到“阵亡通知”。

第二步：登录 SSH，看看服务器是不是“累瘫”了

如果确定网站真挂了，第一时间连上 SSH。如果 SSH 都连不上，那基本上是服务商母机炸了，或者你被超大规模 DDoS 打穿了。能连上 SSH 的话，按这三板斧走：

1. top 或 htop：看 CPU 和内存

执行 top 命令，重点看最上面两行。

• 案例： 某个 PHP 进程占用了 99% 的 CPU。
• 分析： 可能是某个插件写死循环了，或者是被人在刷搜索页。
• 操作： 找到那个 PID，直接 kill -9 紧急避险。

2. df -h：看磁盘空间（高频踩坑点）

这是无数老手都翻过车的坑。网站宕机快速排查流程里，这一步权重极高。

• 真实场景： 很多站长配置了自动备份，结果备份文件塞满了磁盘；或者是 Nginx 的 access.log 攒了几个月，把几百 G 的硬盘直接撑爆。
• 后果： 磁盘一满，数据库（MySQL）就自动关闭，且死活重启不了。
• 避坑技巧： 看到 Use% 那一列显示 100%，别废话，赶紧去 /var/log 删大日志。

3. free -m：看内存余量

如果内存只剩几十 M，PHP 环境经常会直接 502。这时候要考虑是不是该加 Swap（虚拟内存），或者是该升级机器配置了。

第三步：检查 Web 服务与数据库的状态

如果资源都正常，网站还是报 502 或 503，那就是具体的服务“罢工”了。

1. Nginx 是否活着？

systemctl status nginx
# 或者
nginx -t

如果你刚改过配置文件，执行 nginx -t 能救命。它会告诉你哪一行代码写错了。

• 错误示例： 漏了一个分号，或者证书路径填错了。
• 避坑点： 永远不要在没备份配置文件的情况下直接修改。

2. MySQL 连不上了？

如果你看到网站提示 Error establishing a database connection，别怀疑，数据库崩了。

• 排查方案： systemctl status mariadb 或 mysql。
• 实战经验： 绝大多数 MySQL 崩溃是因为内存不足导致的 OOM (Out Of Memory)。如果你是 1G 内存的小水管，还跑个大 WordPress，建议开启 MySQL 的慢查询日志，看看是哪个查询在拖后腿。

第四步：从 SEO 角看宕机，怎么把损失降到最低？

作为一个老站长，我关心的不只是网站能不能跑，我更担心我的 Google 排名。

1. 503 是 SEO 的“免死金牌”

如果你正在修网站，千万不要让网站返回 404 或者一直转圈。

• 操作： 给 Nginx 配置一个临时的 503 状态码。
• 原理： 告诉 Google 爬虫：“我正在装修，马上回来。”这样爬虫会晚点再来，而不会直接把你从索引里剔除。

2. 检查 access.log 是否被攻击

有时候网站宕机是因为被人盯上了。

tail -n 1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 10

这条命令能让你瞬间看到访问量最高的 Top 10 IP。

• 应用场景： 如果某个 IP 一秒钟请求你 50 次，那就是 CC 攻击。
• 解决方案： 别犹豫，直接用 iptables 封掉，或者开启 Cloudflare 的“我正受到攻击”模式（Under Attack Mode）。

第五步：网站宕机排查的“文案与沟通”技巧

如果你的网站是有客户的（比如 B2B 企业站或外贸独立站），宕机期间的“安抚文案”非常重要。一个只会写 "System Error" 的站长是不合格的。

1. 别写“网站正在维修”

这会让客户觉得你很不专业。

• 推荐文案： "Scheduled Maintenance in Progress. We’re upgrading our systems to serve you better."（例行维护中，我们正在升级系统以提供更好的服务。）
• 适用场景： 虽然你是宕机了，但对外要说是“升级”。

2. 标题优化（如果是发布维护页面）

• 坏标题： Error 500
• 好标题： Temporary Service Optimization - [YourBrandName]
• 理由： 即使是报错页面，也要带上品牌名。这在 SEO 抓取快照时，能保留一点点品牌词的相关性。

总结：老站长的“防宕机”日常清单

在网站宕机快速排查流程之外，真正的功夫在平时。如果你不想半夜爬起来改代码，请记住这几点：

1. 日志轮转（Logrotate）： 必须配置。不要让日志文件大到能撑爆硬盘。
2. 定期异地备份： 别把备份文件放在同一台服务器上。万一硬盘坏了，你连哭的地方都没有。
3. 配置监控告警： 哪怕是个简单的 Ping 监控，也比看客户投诉强。
4. 改动前必留备份： 改 Nginx 配置前，cp nginx.conf nginx.conf.bak 是职业素养。

搞网站就像养孩子，总会有头疼脑热的时候。别一宕机就慌神，按照这套网站宕机快速排查流程走一遍：先看外部连通性，再看服务器资源，最后查服务状态和攻击日志。 只要逻辑不乱，没有救不回来的站。

如果你在排查中遇到了什么邪门的问题，比如 CPU 占用极低但网页就是打不开，那多半是文件权限或者缓存锁死的问题，咱们评论区接着唠。作为一个在坑里摸爬滚打出来的老站长，我最不怕的就是解决这些“疑难杂症”。