韩国服务器故障排查记录

一、故障概述

故障时间：2026年1月11日 08:00 - 20:00（约12小时）
故障现象：博客网站 example.com 无法访问，SSH 连接超时
影响范围：网站完全不可访问，无法远程登录服务器
解决方式：通过阿里云控制台重启服务器
恢复时间：2026年1月11日 21:27 左右
根本原因：服务器内存从正常水平飙升至 1.4G/2G，导致服务无响应

二、服务器基本信息

项目	信息
云服务商	阿里云轻量应用服务器
服务器位置	韩国首尔（ap-northeast-2）
公网 IP	1.2.3.4
VPC 内网 IP	10.0.0.1
操作系统	Ubuntu 24.04.2 LTS
内核版本	6.8.0-63-generic x86_64
总内存	2GB（实际可用约 1.6G）
磁盘空间	39GB（使用 11.4%）
SSH 端口	2894（非默认 22）
SSH 用户	root
部署服务	Nginx、MyChat 后端（uvicorn）、Nuxt 前端（node）、proxy_control

三、故障时间线

08:00  - 内存开始异常飙升（根据阿里云监控）
08:00~20:00  - 内存持续占用 1128.54M/2G
20:00  - 发现网站无法访问
20:30  - 开始排查，测试网络连通性
20:35  - 排除 GFW 封锁可能
20:40  - 尝试 SSH 登录失败
20:45  - 尝试 WorkBench 登录失败
20:50  - 通过阿里云控制台重启服务器
21:27  - 服务器重启完成，服务恢复
21:42  - 确认网站正常访问
21:50  - 完成故障排查

08:00 - 内存开始异常飙升（根据阿里云监控）:

四、故障排查过程详解

第一步：确认问题存在

操作：我21:10左右正在处理网站SEO搜索引擎优化的方案，突然发现网站无法访问

思考：首先需要确认问题确实存在，而不是本地网络问题。需要从多个角度测试。

第二步：测试网络连通性

命令 1：ping 测试

ping -n 3 1.2.3.4

（命令解释）：

ping：测试网络连通性的基础工具，发送 ICMP 包并等待响应
-n 3：只发送 3 个包（Windows 参数，Linux 用 -c 3）
1.2.3.4：服务器公网 IP

此时的执行结果如下：

Pinging 1.2.3.4 with 32 bytes of data:
Reply from 1.2.3.4: bytes=32 time=62ms TTL=46
Reply from 1.2.3.4: bytes=32 time=54ms TTL=46
Reply from 1.2.3.4: bytes=32 time=66ms TTL=46

结果分析：

3 个包全部收到响应
延迟 54-66ms，正常（韩国到中国）
TTL=46，表示经过了约 18 个路由器（64-46=18）

结论：服务器网络是通的，ICMP 协议正常。

命令 2：测试 HTTPS 访问

curl -I -k --connect-timeout 10 https://example.com/

命令解释：

curl：命令行 HTTP 客户端工具
-I：只获取 HTTP 响应头（HEAD 请求）
-k：忽略 SSL 证书验证（测试时使用）
--connect-timeout 10：连接超时 10 秒
https://example.com/：测试目标 URL

执行结果：

curl: (28) Connection timed out after 10009 milliseconds

结果分析：

连接超时（exit code 28）
表示 TCP 连接无法建立

结论：HTTPS 服务无法访问。

命令 3：测试 HTTP 访问

curl -s -o /dev/null -w "%{http_code}" --connect-timeout 10 http://example.com/

命令解释：

-s：静默模式，不显示进度
-o /dev/null：丢弃响应内容
-w "%{http_code}"：只输出 HTTP 状态码
--connect-timeout 10：连接超时 10 秒

执行结果：超时

结论：HTTP 服务也无法访问。

第三步：端口连通性检查

为什么要做端口检查？

HTTP/HTTPS 访问失败可能有多种原因：

服务器宕机
防火墙阻止
服务未运行
端口未开放

需要逐个排查。

命令 4：用 bash 测试单个端口

timeout 5 bash -c 'echo > /dev/tcp/1.2.3.4/443' 2>&1 && echo "443 open" || echo "443 closed"

命令解释：

timeout 5：5 秒后超时退出
bash -c '...'：执行 bash 命令
echo > /dev/tcp/1.2.3.4/443：尝试向目标端口发送数据
/dev/tcp/...：bash 内置的网络设备文件
2>&1：将错误输出重定向到标准输出
&& echo "443 open" || echo "443 closed"：成功输出 open，失败输出 closed

测试结果：

端口	结果	说明
22	CLOSED	SSH 默认端口（服务器用 2894）
80	OPEN	HTTP 端口正常
443	OPEN	HTTPS 端口正常
8080	CLOSED	常用测试端口（未使用）
2894	OPEN	SSH 自定义端口正常

重要发现：所有关键端口都是开放的，但服务不响应！

这说明：

✅ 服务器本身在运行
✅ 防火墙没有阻止
❌ 服务（Nginx、SSH）可能挂了

命令 5：用 Python 脚本批量测试端口

python -c "
import socket
import concurrent.futures

def test_port(port):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(5)
        result = sock.connect_ex(('1.2.3.4', port))
        sock.close()
        return port, result == 0
    except:
        return port, False

ports = [22, 80, 443, 8080, 2894]
with concurrent.futures.ThreadPoolExecutor() as executor:
    results = list(executor.map(test_port, ports))
    
for port, is_open in results:
    status = 'OPEN' if is_open else 'CLOSED'
    print(f'Port {port}: {status}')
"

命令解释：

使用 Python 的 socket 库测试端口
socket.SOCK_STREAM：TCP 协议
sock.connect_ex()：尝试连接，返回错误码（0 表示成功）
concurrent.futures.ThreadPoolExecutor：多线程并发测试
timeout=5：5 秒超时

执行结果：

Port 22: CLOSED（这里是因为安全组关闭了22，改为2894ssh）
Port 80: OPEN
Port 443: OPEN
Port 8080: CLOSED
Port 2894: OPEN

结论：端口开放但服务不响应，问题在服务层面，不是网络层面。

第四步：排除 GFW（防火长城）封锁

为什么怀疑是 GFW？

因为服务器在韩国，部署了 Hysteria2 代理服务，理论上可能被 GFW 检测并封锁。（要是这个原因真的后悔莫及啊，固定公网ip的损失太大了）

为什么排除了 GFW？

证据 1：端口扫描显示开放

如果 GFW 封锁，通常会：

直接 RST（重置）连接
完全无法建立 TCP 连接

但我们的扫描显示端口是 OPEN 的。

证据 2：阿里云 WorkBench 也连不上

这是最关键的证据！

WorkBench 的链接显示：

InstanceLoginInfo.Host=10.0.0.1

10.0.0.1 是 VPC 内网 IP，阿里云首尔机房内部网络。

VPC 内网的工作原理是什么呢：

本地电脑 → 阿里云控制台 → 阿里云首尔机房内部网络 → 服务器

因为这条路径完全不经过 GFW！GFW 只能监控出境流量，无法监控机房内部流量。

所以如果内网都连不上，说明问题在服务器本身，不是网络封锁。

证据 3：Ping 正常

GFW 封锁通常会阻断 TCP/UDP，但 ICMP（Ping）可能还能通。这符合我们的观察。所以初步判断不太可能是被防火长城给ban掉。

GFW 封锁的特征（科普）

GFW 主要通过以下方式封锁：

DNS 污染：返回错误的 IP 地址
TCP RST 注入：发送重置包中断连接
IP 封锁：完全阻止特定 IP 的流量
端口封锁：只封锁特定端口（如 443）

但 GFW 无法做到：

阻止 VPC 内网通信
阻止 ICMP（Ping）除非特别配置
阻止所有端口（成本太高）

第五步：尝试远程登录

命令 6：SSH 登录测试

ssh -p 2894 -o ConnectTimeout=30 root@1.2.3.4 "systemctl status nginx"

命令解释：

ssh：SSH 客户端
-p 2894：指定端口 2894
-o ConnectTimeout=30：连接超时 30 秒
root@1.2.3.4：用户名@服务器 IP
"systemctl status nginx"：登录后执行的命令

执行结果：

ssh: connect to host 1.2.3.4 port 2894: Connection refused

结果分析：

Connection refused：连接被拒绝
表示端口是开放的，但服务拒绝连接

结论：SSH 服务（sshd）可能挂了。

第六步：尝试 WorkBench 登录

操作步骤：

登录阿里云控制台
进入「轻量应用服务器」
找到服务器实例
点击「远程连接」

看到三个选项：

WorkBench 一键连接 - 通过浏览器终端连接
WorkBench 密码登录 - 使用密码认证
救援登录 - 使用独立的救援系统

为什么选择救援登录（vnc）？

WorkBench 一键连接/密码登录的原理：

依赖服务器上的 SSH 服务
需要服务器系统正常运行
如果 SSH 挂了或系统崩溃，就无法连接

救援登录的原理：

使用阿里云独立的救援系统
不依赖服务器本身的状态
即使服务器系统损坏也能连接

选择救援登录的原因：

SSH 连接失败（Connection refused）
说明服务器上的 SSH 服务有问题
只能通过不依赖服务器的救援登录进入

救援登录成功后看到：

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-63-generic x86_64)

System information as of Wed Jul  1 09:29:05 PM CST 2026

System load:  0.24              Processes:             120
Usage of /:   11.4% of 39.01GB  Users logged in:       0
Memory usage: 23%               IPv4 address for eth0: 10.0.0.1
Swap usage:   0%

关键信息：

系统负载 0.24（正常）
内存使用 23%（重启后恢复正常）
进程数 120（正常）

结论：服务器已重启完成，系统正常。

第七步：检查服务状态

命令 7：检查 Nginx 状态

systemctl status nginx

命令解释：

systemctl：systemd 服务管理工具
status nginx：查看 nginx 服务状态

执行结果：

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-07-01 21:27:06 CST; 4min 40s ago

结果分析：

active (running)：服务正在运行
since 21:27:06：21:27 启动，运行了约 5 分钟
enabled：开机自启

结论：Nginx 正常运行。

命令 8：检查内存使用

free -h

命令解释：

free：显示内存使用情况
-h：人类可读格式（GB/MB）

执行结果：

               total        used        free      shared  buff/cache   available
Mem:           1.6Gi       468Mi       823Mi       2.6Mi       473Mi       1.1Gi
Swap:             0B          0B          0B

结果分析：

total 1.6Gi：总内存 1.6GB
used 468Mi：进程占用 468MB
free 823Mi：空闲 823MB
buff/cache 473Mi：缓冲/缓存 473MB
available 1.1Gi：可用内存 1.1GB
Swap 0B：没有交换分区

重要概念：

buff/cache 是 Linux 用空闲内存做的文件缓存，可以随时释放
available 才是真正可用的内存
当前内存状态非常健康

结论：内存恢复正常，之前飙升到 1.1G 的问题已解决。

命令 9：查看内存占用最高的进程

ps aux --sort=-%mem | head -10

命令解释：

ps：查看进程状态
a：显示所有用户的进程
u：以用户为主的格式
x：显示没有控制终端的进程
--sort=-%mem：按内存使用率降序排序
head -10：只显示前 10 行

执行结果：

USER    PID  %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root    779   0.2 11.5 360420 191416 ?       Ssl  21:27   0:02 /root/blog/backend/venv/bin/python3 .../uvicorn
root    780   0.0  5.0 11785696 84184 ?      Ssl  21:27   0:00 /usr/bin/node /root/blog/frontend/.output/server/index.mjs
root    869   0.6  2.1 1290588 34560 ?       Sl   21:27   0:02 /usr/local/cloudmonitor/bin/argusagent

结果分析：

uvicorn（11.5%）：MyChat 后端，正常
node（5.0%）：Nuxt 前端，正常
argusagent（2.1%）：阿里云监控，正常

结论：没有异常进程，没有挖矿程序。

第八步：深入排查内存飙升原因

命令 10：查看 OOM Killer 记录

journalctl -k --since '2026-07-01 08:00:00' --until '2026-07-01 20:00:00' | grep -i 'oom\|out of memory\|killed'

命令解释：

journalctl：查看 systemd 日志
-k：只看内核日志
--since/--until：时间范围过滤
grep -i：不区分大小写搜索
oom\|out of memory\|killed：搜索 OOM 相关关键词

什么是 OOM Killer？

OOM = Out Of Memory（内存不足）
当内存耗尽时，Linux 内核会杀死占用内存最多的进程
这是系统的自我保护机制

执行结果：

-- No entries --

结论：没有发生 OOM，系统没有因为内存不足杀死进程。

命令 11：检查可疑进程

ps aux | grep -E 'miner|xmrig|kdevtmpfsi|kinsing' | grep -v grep

命令解释：

grep -E：扩展正则表达式
miner|xmrig|kdevtmpfsi|kinsing：常见挖矿程序名称
grep -v grep：排除 grep 进程本身

常见挖矿程序：

xmrig：门罗币挖矿
kdevtmpfsi：Kinsing 恶意软件
kinsing：Kinsing 恶意软件

执行结果：无输出

结论：没有挖矿进程。

命令 12：检查定时任务（实际上没有搞过定时任务，但是不知道有没有别的定时项目被错误部署到了这个服务器，所以保险起见也查一下）

crontab -l
ls -la /etc/cron.d/

命令解释：

crontab -l：列出当前用户的定时任务
ls -la /etc/cron.d/：查看系统定时任务目录

执行结果：

no crontab for root

/etc/cron.d/:
certbot
e2scrub_all
.placeholder
sysstat

结果分析：

root 用户没有自定义定时任务
/etc/cron.d/ 只有系统默认任务（certbot 证书更新、sysstat 统计等）

结论：没有恶意定时任务。

命令 13：检查内存占用超过 100MB 的进程

for pid in $(ls /proc/ | grep -E '^[0-9]+$'); do
  if [ -f /proc/$pid/status ]; then
    name=$(grep '^Name:' /proc/$pid/status | awk '{print $2}')
    rss=$(grep '^VmRSS:' /proc/$pid/status | awk '{print $2}')
    if [ ! -z "$rss" ] && [ "$rss" -gt 100000 ]; then
      echo "PID: $pid Name: $name RSS: ${rss}kB"
    fi
  fi
done | sort -t: -k3 -n -r | head -10

命令解释：

遍历 /proc/ 下所有进程目录
读取每个进程的 status 文件
提取 VmRSS（常驻内存）
筛选超过 100MB（100000 kB）的进程

执行结果：

PID: 779 Name: uvicorn RSS: 191416kB

结论：只有 uvicorn（191MB）超过 100MB，这是正常的。

命令 14：检查系统日志中的异常

journalctl --since '2026-07-01 08:00:00' --until '2026-07-01 20:00:00' -p err | head -30

命令解释：

-p err：只显示错误级别日志

执行结果：

-- No entries --

结论：没有错误日志。

命令 15：检查进程崩溃记录

dmesg | grep -i 'kill\|oom' | tail -20

命令解释：

dmesg：显示内核环形缓冲区消息
用于查看硬件和内核级别的错误

执行结果：

[    1.520823] systemd[1]: /etc/systemd/system/cloudmonitor.service:8: Unit uses KillMode=none.

结果分析：

cloudmonitor.service 使用了 KillMode=none
这是不安全的配置，可能导致进程无法正常回收
但这是阿里云监控服务，不影响主要功能

结论：没有进程崩溃记录。

第九步：SSH 服务恢复后继续排查

命令 16：启动 SSH 服务

systemctl start ssh

为什么需要这个命令？

服务器重启后，SSH 服务默认是禁用的（disabled）
需要手动启动才能远程连接

命令 17：SSH 连接测试

ssh -p 2894 -o ConnectTimeout=30 root@1.2.3.4 "systemctl status ssh"

执行结果：

● ssh.service - OpenBSD Secure Shell server
     Active: active (running) since Wed 2026-07-01 21:40:10 CST; 1min 23s ago

结论：SSH 服务正常，可以远程连接。

命令 18：检查 Nginx 访问日志

grep "01/Jul/2026:0[8-9]\|01/Jul/2026:1[0-9]\|01/Jul/2026:20" /var/log/nginx/access.log | wc -l

命令解释：

grep 搜索今天 8:00-20:00 的访问日志
wc -l 统计行数

执行结果：1410

结论：今天有 1410 个请求，访问量不大，不是流量攻击导致。

命令 19：检查服务器本地 HTTPS 响应

curl -I -k https://localhost

执行结果：

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
x-powered-by: Nuxt

结论：服务器本地 HTTPS 正常。

命令 20：获取公网 IP

curl ifconfig.me

执行结果：1.2.3.4

结论：公网 IP 正确。

第十步：最终验证

命令 21：从外部测试 HTTPS 访问

curl -I -k --connect-timeout 10 https://example.com/

执行结果：

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
x-powered-by: Nuxt

结论：网站完全恢复正常！

五、排查思路总结

本次故障排查遵循了由外到内、由简到繁的原则：

1. 确认问题 → 2. 测试网络 → 3. 检查端口 → 4. 排除GFW
       ↓
5. 尝试登录 → 6. 选择登录方式 → 7. 重启服务器 → 8. 检查服务
       ↓
9. 深入排查 → 10. 最终验证

每一层的逻辑：

网络层：Ping 是否通？
- 通 → 网络正常，继续
- 不通 → 检查 DNS、防火墙
端口层：关键端口（80/443/2894）是否开放？
- 开放 → 端口正常，继续
- 关闭 → 检查防火墙、安全组
服务层：服务是否响应？
- 响应 → 服务正常，继续
- 不响应 → 服务挂了，需要重启
系统层：内存、CPU、磁盘是否正常？
- 正常 → 继续排查应用
- 异常 → 找出异常进程
应用层：日志、配置是否正常？
- 正常 → 问题解决
- 异常 → 修复配置

六、经验总结

教训 1：内存监控缺失

没有设置内存告警
内存飙升 12 小时才发现
建议：设置 80% 内存告警

教训 2：没有 Swap 分区

2G 内存的服务器没有 Swap
内存不足时没有缓冲
建议：添加 2G Swap 分区

教训 3：SSH 服务未自启

重启后 SSH 服务是禁用的
需要手动启动
建议：systemctl enable ssh

教训 4：没有故障应急预案

第一次遇到故障，手忙脚乱
不知道 WorkBench、VNC 在哪里
建议：整理故障处理 SOP

七、后续安排

立即执行（今天）

启用 SSH 开机自启
```
systemctl enable ssh
```

添加 Swap 分区

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

设置内存监控告警
- 阿里云控制台 → 云监控 → 告警管理
- 创建告警规则：内存 > 80% 时短信通知

短期执行（本周）

配置 SSH Key 登录
- 避免密码泄露
- 提高登录安全性

设置自动重启

# 每周日凌晨 4 点自动重启
0 4 * * 0 /sbin/reboot

备份服务器配置

# 备份 Nginx 配置
tar -czf nginx_backup_$(date +%Y%m%d).tar.gz /etc/nginx/

# 备份应用配置
tar -czf app_backup_$(date +%Y%m%d).tar.gz /root/blog/ /root/proxy_control/

长期执行（本月）

学习阿里云控制台操作
- 熟悉 WorkBench、VNC 入口
- 了解安全组配置
- 学会查看监控数据
建立故障处理文档
- 整理本次故障处理过程
- 制作故障处理 SOP
- 记录常见问题解决方案
优化服务器配置
- 调整 Nginx 连接数限制
- 配置 Gzip 压缩
- 优化应用内存使用

八、相关知识点科普

1. GFW（防火长城）工作原理

GFW 是中国的网络审查系统，主要通过以下方式工作：

DNS 污染：篡改 DNS 解析结果
TCP RST 注入：发送重置包中断连接
深度包检测（DPI）：分析流量特征
IP/端口封锁：阻止特定 IP 或端口

GFW 无法做到：

监控 VPC 内网通信
封锁 ICMP（Ping）
封锁所有端口（成本太高）

2. 端口概念

端口是网络通信的"门牌号"：

80：HTTP 网站
443：HTTPS 加密网站
22：SSH 远程登录
2894：SSH 自定义端口

端口状态：

OPEN：端口开放，服务正在监听
CLOSED：端口关闭，没有服务监听
FILTERED：端口被防火墙过滤

3. 内存管理

Linux 内存使用：

used：进程实际占用
free：完全空闲
buff/cache：文件缓存（可释放）
available：真正可用内存

OOM Killer：

当内存耗尽时，内核会杀死占用最多的进程
这是系统的自我保护机制

4. Swap 分区

Swap 是用磁盘空间模拟的内存：

当物理内存不足时，系统会把部分数据移到 Swap
速度比物理内存慢，但能防止 OOM
建议大小：物理内存的 1-2 倍

5. systemd 服务管理

systemd 是 Linux 的服务管理器：

systemctl start nginx：启动服务
systemctl stop nginx：停止服务
systemctl restart nginx：重启服务
systemctl status nginx：查看状态
systemctl enable nginx：设置开机自启

九、应急预案（下次故障时参考）

快速判断流程

网站无法访问
    ↓
Ping IP 地址
    ↓
通 → 检查端口 → 端口通 → 检查服务 → 服务挂了 → 重启服务
    ↓                ↓                ↓
不通 → 检查 DNS    端口不通 → 检查防火墙   服务正常 → 检查日志

快速恢复步骤

尝试重启服务

systemctl restart nginx
systemctl restart ssh

如果服务重启失败，重启服务器
- 阿里云控制台 → 重启实例
如果无法登录控制台，使用 VNC/救援登录
- 阿里云控制台 → 远程连接 → 救援登录

检查日志定位问题

journalctl -xe
tail -f /var/log/nginx/error.log

十、附录

A. 本次故障使用的所有命令

命令	用途	执行位置
`ping -n 3 1.2.3.4`	测试网络连通性	本地电脑
`curl -I -k --connect-timeout 10 https://example.com/`	测试 HTTPS 访问	本地电脑
`timeout 5 bash -c 'echo > /dev/tcp/...'`	测试端口连通性	本地电脑
`python -c "..."`	批量测试端口	本地电脑
`ssh -p 2894 root@... "command"`	SSH 远程执行	本地电脑
`systemctl status nginx`	检查 Nginx 状态	服务器
`free -h`	查看内存使用	服务器
`ps aux --sort=-%mem \| head -10`	查看内存占用 Top 10	服务器
`journalctl -k \| grep oom`	查看 OOM 记录	服务器
`ps aux \| grep miner`	检查挖矿进程	服务器
`crontab -l`	查看定时任务	服务器
`dmesg \| grep kill`	查看内核日志	服务器
`curl ifconfig.me`	获取公网 IP	服务器
`curl -I -k https://localhost`	测试本地 HTTPS	服务器

B. 阿里云控制台操作指引

登录控制台：https://home.console.aliyun.com/
找到轻量服务器：产品与服务 → 轻量应用服务器
远程连接：点击实例 → 右上角「远程连接」
选择连接方式：
- WorkBench：依赖 SSH，适合正常情况
- VNC/救援登录：不依赖 SSH，适合故障情况

C. 参考资料

文档信息：

作者：leap
创建时间：2026-07-01
最后更新：2026-07-01
版本：v1.0

服务器故障排查记录

韩国服务器故障排查记录

一、故障概述

二、服务器基本信息

三、故障时间线

四、故障排查过程详解

第一步：确认问题存在

第二步：测试网络连通性

命令 1：ping 测试

命令 2：测试 HTTPS 访问

命令 3：测试 HTTP 访问

第三步：端口连通性检查

为什么要做端口检查？

命令 4：用 bash 测试单个端口

命令 5：用 Python 脚本批量测试端口

第四步：排除 GFW（防火长城）封锁

为什么怀疑是 GFW？

为什么排除了 GFW？

GFW 封锁的特征（科普）

第五步：尝试远程登录

命令 6：SSH 登录测试

第六步：尝试 WorkBench 登录

操作步骤：

看到三个选项：

为什么选择救援登录（vnc）？

救援登录成功后看到：

第七步：检查服务状态

命令 7：检查 Nginx 状态

命令 8：检查内存使用

命令 9：查看内存占用最高的进程

第八步：深入排查内存飙升原因

命令 10：查看 OOM Killer 记录

命令 11：检查可疑进程

命令 12：检查定时任务（实际上没有搞过定时任务，但是不知道有没有别的定时项目被错误部署到了这个服务器，所以保险起见也查一下）

命令 13：检查内存占用超过 100MB 的进程

命令 14：检查系统日志中的异常

命令 15：检查进程崩溃记录

第九步：SSH 服务恢复后继续排查

命令 16：启动 SSH 服务

命令 17：SSH 连接测试

命令 18：检查 Nginx 访问日志

命令 19：检查服务器本地 HTTPS 响应

命令 20：获取公网 IP

第十步：最终验证

命令 21：从外部测试 HTTPS 访问

五、排查思路总结

六、经验总结

教训 1：内存监控缺失

教训 2：没有 Swap 分区

教训 3：SSH 服务未自启

教训 4：没有故障应急预案

七、后续安排

立即执行（今天）

短期执行（本周）

长期执行（本月）

八、相关知识点科普

1. GFW（防火长城）工作原理

2. 端口概念

3. 内存管理

4. Swap 分区

5. systemd 服务管理

九、应急预案（下次故障时参考）

快速判断流程

快速恢复步骤

十、附录

A. 本次故障使用的所有命令

B. 阿里云控制台操作指引

C. 参考资料

评论