更新于

凌晨两点网站打不开：一个人值班时的前 15 分钟排查顺序

半夜被用户消息或告警叫醒，说网站打不开，手边只有笔记本或手机。第一反应往往是“先重启整台机器”，但重启可能抹掉故障现场，也可能让数据库在写入中途被打断。本文给一个人值班的开发者或创始人一个固定的前 15 分钟顺序：先确认影响 → 再看机器还活着吗 → 入口和应用在不在跑 → 只看故障窗口的日志 → 写下三行再动手。以下适用于常见的 Linux VPS（systemd、Nginx、Docker）；路径、服务名和端口请按你的实际环境替换。本文只做第一轮分流，深入步骤链接到对应的专题指南。

1. 第 0–2 分钟：从外面确认影响

在你自己的电脑上执行（不是在服务器上），把 example.com 换成你的域名：

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' --max-time 10 https://example.com/
dig +short example.com A
dig +short example.com AAAA

这组命令不能说明：单个网络位置的结果不代表所有用户；如果前面有 CDN，看到的状态码可能是 CDN 生成的错误页，不是源站的真实状态。可以再用手机流量打开一次作对照。

2. 第 2–5 分钟：机器还活着吗

先试着 SSH 登录。如果 SSH 连不上，先去云厂商控制台看实例状态、监控图和安全组，必要时用控制台自带的 VNC/串口登录；这种情况下 OpsMate 也连不上这台机器，帮不上忙。能登录的话：

uptime
nproc
free -h
df -h
df -i

这组命令不能说明：是哪个进程在占资源，也看不到故障发生那一刻的峰值；它们只是当前快照。

3. 第 5–8 分钟：入口和应用在不在跑

systemctl --failed --no-pager
systemctl status nginx --no-pager
sudo ss -ltnp
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

再在服务器上直接请求一次应用，绕开 DNS、CDN 和 Nginx（端口和路径只是示例，换成你的实际上游和一个安全的健康检查路径）：

curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 http://127.0.0.1:3000/

本机能返回正常状态码、外面却打不开，问题更可能在 Nginx、防火墙、证书或 DNS；本机也失败，就先查应用。注意：端口在监听不等于应用健康，应用可能在监听但每个请求都卡住或报错。

4. 第 8–12 分钟：只看故障窗口的日志

先问自己“大概从几点开始坏的”，然后只看那段时间附近的日志，不要从头翻：

journalctl -p err --since "30 min ago" --no-pager | tail -n 100
sudo tail -n 100 /var/log/nginx/error.log
docker logs --since 30m --tail 200 --timestamps YOUR_CONTAINER
sudo dmesg -T | grep -i -E 'out of memory|killed process' | tail -n 20

分享或提交这些日志前，先遮盖密码、令牌、连接串、客户邮箱和内部地址。

5. 第 12–15 分钟：动手前先写三行

在任何重启或修改之前，先写下来（发到自己的笔记或团队群都行）：

  1. 现象：几点开始、谁受影响、外部 curl 结果。

  2. 证据：哪条命令、哪行输出支持你的判断；哪些还没确认。

  3. 最小动作 + 回退：准备做的那一个动作，做完怎么验证，失败了怎么退回去。

几个常见的最小动作，每一个都是需要你拍板的变更，不是诊断步骤：

做完动作后，再跑一遍第 1 步的外部 curl 和第 2 步的资源检查，确认恢复，并记下时间。

在 OpsMate 里怎么走这 15 分钟

OpsMate 把 SSH 终端和 AI 放在同一个服务器页面。上面的命令你可以直接在终端里手敲；记不清命令时，也可以用一句话把情况告诉 AI。AI 会提出排查命令，除了看日志，也可以用 ps、df、ss、docker、journalctl 这类命令做检查；命令跑完后，点击「需要分析」，AI 会根据输出给出结论。命令和输出都留在终端里，方便你核对，也方便事后复盘。人在外面时，巡检和 Telegram 告警可以先把异常推给你。只收 Telegram 告警不需要把凭证存到云端；想直接从 Telegram 远程 SSH 排障，才需要把该服务器的凭证托管到云端，参见 用 Telegram 收服务器告警。手机上具体怎么操作，见 在 Telegram 里处理服务器问题。

边界要说清楚：

说明性示例

说明性示例（不是真实客户案例）：凌晨两点，外部 curl 返回 502。服务器能登录，uptime 负载不高；systemctl status nginx 显示 Nginx 正常运行，但 ss -ltnp 里应用的 3000 端口没有进程监听。docker ps -a 显示应用容器反复 Restarting，docker logs 里第一条异常是数据库写入失败。回头看 df -h，根分区 100%。这时 502 只是表象，真正要处理的是磁盘：先按磁盘指南确认是日志还是业务数据占满，只清理确认可丢弃的内容，再观察容器是否自己恢复。如果在第一步就重启了整台机器，磁盘依然是满的，问题会在几分钟后重演，而且现场记录更少。

AI 排查提示词

网站从大约 30 分钟前开始打不开。请先只做检查、不做任何改动，看看这台服务器的：负载、可用内存、磁盘容量和 inode、失败的 systemd 服务、监听端口、Docker 容器状态，以及最近 30 分钟的系统、Nginx 和应用错误日志。请区分已证实的事实和推测，并列出还缺少哪些信息。不要重启服务、删除文件或修改配置；如果需要变更，先给出最小步骤、风险、验证方法和回退方案，等我确认。

试用

每月免费 500 次 AI 调用；服务器数量不限。桌面端默认把 SSH 凭证保留在本机。

需要帮助理解排查结果？

OpsMate 帮助开发者和运维人员用 AI 辅助排查，由你核对证据。点击「需要分析」后，命令输出会发送给云端 AI 分析，请先去除敏感信息。

免费开始 本地凭证桌面端

排障指南