亚马逊云韩国账号 AWS亚马逊云轻量服务器故障排除

亚马逊aws / 2026-04-27 13:12:38

开场：轻量服务器故障也许没那么“轻”

“AWS 亚马逊云轻量服务器故障排除”这个话题听起来像是把云上问题拆开看——可现实往往是：你刚准备睡觉，监控开始红灯闪烁，客户在群里追问“怎么又不通了”，你打开控制台，看着那一堆指标像天气预报一样冷静但毫无安慰。

别慌。云服务器故障排查其实有规律可循：先判断是实例层、网络层、系统层还是应用层出了问题。只要你按顺序来，就能少走弯路。本文会用比较“人话”的方式，把常见故障从现象到定位再到修复讲清楚，并给出你在现场能直接用的思路和命令。

排查的核心原则：别急着动，先把线索收齐

任何故障排查都遵循三个原则：先观察、再验证、最后修复。你要把“盲目操作”的冲动按在地上摩擦一下。

先观察：故障发生时间、影响范围、表现形式（无法连接？接口超时？只对部分用户失败？）
再验证：用控制台、监控、日志、探测命令确认“是哪一层不对”
最后修复：按证据进行修改，改完验证，再决定是否回滚

亚马逊云韩国账号 还有一个小技巧：每次只改一件事。你今天改了安全组、明天又重启服务、后天又更新应用，最后修好了也没法知道是哪个动作救了你。云上最怕的不是故障，是“不知道为什么好转”。

第一步：确认实例到底“活没活”

很多“服务器挂了”的感觉，实际上是实例状态没问题，但网络、端口或服务层出事了。所以第一步不要跳过：先确认实例状态。

1.1 检查实例状态

在 AWS 控制台查看实例（轻量服务器）状态。常见状态包括运行中、停止中、重启中等。

如果状态是停止/已停止：先启动实例，再看服务
如果状态是重启中：耐心等一下，尤其是你刚做了配置变更
如果状态是运行中：继续看网络和系统层

此外，你还要注意是否发生了“资源不足”类事件。有些情况下实例看似运行，但系统服务因内存/磁盘问题频繁崩溃。

1.2 确认远程访问是否可能

如果你能拿到公网 IP 或域名，先在本地测试：

测试端口可达性：
例如在本机执行（替换 IP 和端口）：
nc -vz 你的IP 22
如果是 HTTP/HTTPS：
curl -I http://你的域名
curl -I https://你的域名

如果连接连不上，别急着看应用日志，先看网络层。

第二步：网络层故障排查（最常见的“看起来像挂了”）

网络层问题往往表现为：可以访问网站的一部分区域失败、或完全无法连接、或仅某些端口不可达。

2.1 安全组（或防火墙规则）与端口策略

虽然轻量服务器产品在控制台的配置入口可能略有差异，但核心仍是：允许哪些端口从哪里访问。你要重点检查这些：

是否开放了你需要的端口（22 用于 SSH，80/443 用于 Web，其他服务端口按需）
来源限制是否太严格（只允许某 IP 段导致其他用户访问失败）
是否启用了错误的协议（TCP/UDP 搞错很常见）

如果你在控制台里改了安全组规则，别忘了立刻验证：改完就测试，不要等“过一会”。

2.2 系统级防火墙（iptables/ufw/firewalld）

控制台放行了不代表系统也放行。服务器内部防火墙同样可能拦住流量。

登录服务器后检查（示例命令按实际系统选择）：

UFW：
sudo ufw status verbose
firewalld：
sudo firewall-cmd --state
sudo firewall-cmd --list-all
iptables（较老环境）：
sudo iptables -S

如果你发现端口没放行，先放行对应端口，再观察服务是否能正确响应。

2.3 路由、网卡与 DNS

如果出现“ping 不通但端口可连”或“域名解析异常”，要考虑 DNS 与网络配置。

检查网卡与 IP：
ip a
检查路由：
ip route
检查 DNS 配置：
cat /etc/resolv.conf
测试解析：
nslookup google.com
(或 dig google.com)

常见坑：你改过 DNS，导致服务器无法拉取镜像、无法访问外部依赖，于是应用“看似挂了”。这类故障不一定体现在端口被拒绝，而是应用请求超时。

第三步：系统层故障排查（CPU、内存、磁盘、服务）

网络都没问题的话，就进入系统层。系统层故障通常更“有迹可循”：日志里会有明显错误，或监控指标会突然飙升。

3.1 CPU/内存爆表：服务起得来，但响应慢或直接崩

先看资源使用：

亚马逊云韩国账号 CPU、负载：
uptime
top
内存：
free -h
查看是否 OOM（内存溢出）：
dmesg | tail -n 200
或查看 /var/log/syslog（视系统而定）

如果你看到 OOM killer 把进程干掉了，那基本就可以定性：应用因为内存不足不断被重启。接下来就是加内存/优化程序/限制并发。

3.2 磁盘空间不足：经典中的经典

很多线上故障其实就是磁盘满了，然后日志继续写、应用继续报错、数据库开始各种失败。你会看到非常“戏剧化”的报错：数据库写不了、队列无法入库、甚至 SSH 都可能受影响。

检查磁盘：

df -h
查看占用最大的目录：
du -sh /* 2>/dev/null
定位日志爆炸：
du -sh /var/log/* 2>/dev/null

如果是日志占满，先做止血：

清理旧日志（谨慎）：
sudo find /var/log -type f -name '*.log' -mtime +7 -delete
查看是否有服务疯狂刷日志：用 journalctl 或应用日志确认

止血后再解决根因，比如日志轮转策略（logrotate）是否配置正确。

3.3 磁盘 IO/挂载错误：文件系统也会“翻车”

如果磁盘空间没满但服务卡死或读写异常，检查挂载与文件系统：

查看挂载：
mount | head
查看是否只读：
dmesg | grep -i -E 'error|ext4|readonly' | tail -n 50
检查磁盘错误（需要谨慎）：
如果是 ext4，一般要在合适条件下进行 fsck（这一步别在忙碌生产系统上随意动，最好在窗口期）

这类故障处理往往要看具体磁盘类型与错误信息，建议结合监控和事件时间点。

3.4 服务没起：看看进程、端口与状态

系统层最常见的“服务不工作”不是系统坏了，而是你的应用服务没起、起了但挂了、或绑定端口失败。

亚马逊云韩国账号 你可以按这个顺序查：

看服务状态（systemd）：
sudo systemctl status nginx
sudo systemctl status your-app
看是否监听端口：
sudo ss -lntp
或 sudo netstat -lntp
看进程是否存在：
ps aux | grep -i your-app

如果端口没监听，先看服务日志；如果端口监听但连接失败，可能是应用内部错误或反向代理配置问题。

第四步：应用层故障排查（让日志说话）

当你确认网络通、服务进程也在，但用户仍然报错，那就是应用层。

4.1 先对照“错误类型”：超时、拒绝、502、500

不同错误对应不同问题。

连接超时：可能服务没响应、应用卡死、依赖不可达
连接被拒绝：可能端口没监听或监听失败
502/503（网关错误）：常见于 Nginx/网关转发到后端失败
500（服务器内部错误）：应用代码异常或依赖失败

你可以用 curl 把响应头和状态码抓出来，从而判断是网关层还是应用层。

4.2 查看应用日志与最近变更

日志是你最好的朋友，尤其当它在拼命向你求救。

常见查法：

systemd 日志：
sudo journalctl -u nginx --since '1 hour ago' --no-pager
应用日志（示例路径）：
tail -n 200 /var/log/your-app/your-app.log
实时跟踪：
tail -f /var/log/your-app/your-app.log

同时要回忆最近有没有变更：更新依赖、改环境变量、切换数据库、调整反向代理、升级运行时等。应用层故障通常跟“变更”强相关。

4.3 数据库与缓存依赖：能连通不代表能用

很多 Web 服务看起来端口开放，但真实请求仍失败，因为数据库或缓存不可用。

你可以检查：

应用到数据库的连通性（从应用主机视角）
数据库是否报错（连接数、慢查询、锁、磁盘满等）
缓存是否超时（Redis 连接超时、集群故障）

例如应用使用 Redis，通常日志会出现连接超时或认证失败。你要核对：

Redis 地址与端口是否正确
密码/ACL 是否变化
安全组是否允许从应用服务器到 Redis 的端口

如果你曾经“为了安全把安全组收紧”，那就很可能是那个动作导致依赖断了。

第五步：针对常见故障场景给你“对号入座”的排查清单

下面列几个线上最常见的场景。你遇到类似情况，可以直接按这个顺序跳。

5.1 SSH 能连但网站不通

先看网站端口是否监听：
sudo ss -lntp
检查 Nginx/Apache 状态：
sudo systemctl status nginx
检查 Nginx 配置：确认 server_name、root、proxy_pass 指向是否正确
检查应用后端服务是否可达：端口是否在、服务是否在跑
检查系统防火墙是否只开放了 22 没开放 80/443

5.2 网站间歇性超时，偶尔能打开

看 CPU/内存是否波动：频繁高负载可能导致超时
看磁盘 IO 是否异常：磁盘慢会拖垮应用
检查连接池/线程池是否耗尽
看数据库是否有锁等待或连接数耗尽
确认是否有频繁重启或崩溃日志

这种故障最烦，但也最容易通过“时间线”找到原因：看日志里是否有错误集中出现、看监控指标是否同步飙升。

5.3 502/504：网关能到但后端不行

Nginx 错误日志：
tail -n 200 /var/log/nginx/error.log
检查 proxy_pass 后端地址与端口是否正确
检查后端服务是否超时（比如应用处理请求慢）
检查后端是否被系统资源杀掉（OOM、重启）

502 往往是后端返回错误或不可达；504 往往是后端处理超时。

5.4 完全无法连接：连 SSH 都不行

先看控制台安全组/网络策略是否误改
检查是否被系统防火墙拦截（但你都进不去就只能猜了）
检查实例是否运行正常、是否发生网络中断
如果你有带外控制能力（依产品支持），用那个先止血

在这种情况下，通常优先从控制台层面排查：因为你连服务器都登不上，系统内部检查就变成“盲人摸象”。

5.5 服务启动失败：systemctl status 直接报错

看具体报错信息：
sudo systemctl status your-app --no-pager
看日志：
journalctl -u your-app -n 200 --no-pager
检查依赖文件是否存在（配置文件、证书、环境变量）
检查端口是否被占用：
sudo ss -lntp | grep 端口

服务启动失败经常不是“应用坏了”，而是环境变了：比如证书路径不对、配置写错、数据库地址配置错。

第六步：如何“止血”同时不破坏线索

故障处理中你会忍不住做两件事：重启服务器、重启服务。它们有时候是救命稻草，但也可能把线索“洗没”。

6.1 先止血后定位：重启要谨慎

建议做法：

如果服务明显崩溃或卡死：先尝试重启应用服务（比如 systemctl restart your-app）
亚马逊云韩国账号 如果系统资源耗尽：先清理磁盘/释放资源，再决定重启
如果你需要判断“为什么会崩”：重启前先抓日志片段（tail 200 行也行）

你不需要每次都“先抓全量证据”，但至少要在关键节点保留一段错误信息。

6.2 记录你的操作：未来你会感谢现在的你

建议写一张小的故障记录（哪怕在备忘录里）：

故障开始时间
现象（端口、错误码、影响范围）
排查顺序（你查到了什么、不确定什么）
最终修复动作（做了什么改动）
修复后验证结果

当同类问题再次出现，你会发现速度提升非常明显。

第七步：用监控与告警把故障变得“可预知”

排除故障当然重要，但更重要的是让故障不那么突然。AWS 的监控告警（具体以你使用的监控体系为准）可以在资源即将耗尽时提前通知你。

建议你重点监控以下指标：

CPU 使用率与负载
内存使用与 OOM 告警
磁盘使用（尤其是根分区/日志分区）
网络流量与错误率（如果有）
应用健康检查（HTTP 状态码、延迟、错误率）

告警别配太激进，不然你会被告警轰炸到怀疑人生。但也别配太宽松，等你发现时已经“用户替你体验”。

第八步：给你一份“快速排查路线图”（按顺序走）

为了让你在真实现场少思考、多落地，这里给出一个简化路线图。你可以把它当作“故障时的导航仪”。

确认实例状态：运行中？是否停止/重启中？
确认端口连通性：22/80/443 是否可达？
检查安全组与系统防火墙：放行是否齐全？
亚马逊云韩国账号 检查网络基础：IP、路由、DNS（尤其是依赖超时）
检查系统资源：CPU、内存、磁盘空间与日志大小
检查服务状态：systemctl status、端口监听、进程存在
检查应用日志：错误类型（502/500/超时）、最近变更
验证修复效果：从外部探测 + 从内部确认依赖

如果你按这个顺序走，一般不会从“应用代码”直接跳到“重装系统”，那种操作不但累，还会把你原本能抓到的线索弄没。

结尾：云上故障不是玄学，是工程

“AWS 亚马逊云轻量服务器故障排除”听起来像一场和云对话的谈判，但本质上是一套工程化排查流程。网络、系统、应用各司其职。你要做的是：用证据把范围缩小，让每一步都能回答一个问题——“到底是哪层出错”。

最后再送你一句“现场生存法则”：当你觉得自己快要瞎忙的时候，停一下，回到第一步，从现象确认开始；当你做完修复又觉得心里没底的时候，再做一次验证。故障排查不是跑马拉松，是要把路线跑对。

愿你下次遇到告警，不是“连夜修复”，而是“按流程冷静验证”。毕竟，云再大，也大不过一个清晰的排查顺序。