Linux 服务异常时，先检查这五件事

> 日期说明：归档日期为历史整理日期，不代表原始首发时间；本文于 2026-11-02 核对并修订。命令示例需按实际环境替换占位符。


服务突然访问不了时，最容易走的弯路是直接重装。更有效的方法是从外到内缩小范围：机器是否在线、资源是否充足、进程是否运行、端口是否监听，最后才是应用配置。

## 先记录现象

记下失败的地址、发生时间和报错。连接超时、连接被拒绝、HTTP 502 是不同的问题：超时可能涉及网络或防火墙；拒绝连接通常表示目标可达，但端口没有服务；502 则要继续检查反向代理与上游。

<!-- more -->

## 检查资源

用 `uptime` 看负载，用 `free -h` 看内存，用 `df -h` 看磁盘。负载高不一定代表 CPU 忙，也可能是在等待磁盘。磁盘满会使数据库写入、日志和证书续期同时失败。

## 查看服务和日志

systemd 服务可用 `systemctl status 服务名` 查看状态，再用 `journalctl -u 服务名 --since "30 min ago"` 查看近期日志。容器则检查 `docker ps -a` 和 `docker logs --tail 100 容器名`。重点找第一次失败，而不是反复出现的后续错误。

## 确认监听地址

`ss -lntp` 能看到 TCP 监听端口。监听在 127.0.0.1 的服务通常只能从本机连接；监听在 0.0.0.0 代表全部 IPv4 接口，但是否公网可达还受云安全组和系统防火墙影响。

## 分别测试上游与入口

先在机器上请求应用端口，再请求域名入口。如果应用返回正常而域名返回 502，排查代理配置；如果上游本身失败，先修应用。一次只修改一个变量，才能知道哪个动作真正解决了问题。

重启可以缓解部分故障，但保存日志、找到原因并补上监控，才是下一次少走弯路的方法。


## 操作参考与适用边界

### 把结果放回同一时间窗口

```sh
uptime
free -h
df -h
ss -lnt
```

这些命令来自常见 Linux 工具集。排查时先收集只读结果，必要时提高权限查看完整信息；不要把负载数字直接等同于 CPU 百分比。

### 如何判断结果

操作后应将实际结果与文中目标对照；命令成功退出只能证明该步骤完成，不能替代业务层验证。记录异常信息时，保留时间、软件版本与相关上下文，方便后续复查。

## 参考资料

- [官方文档与规范](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html)（本次整理参考，页面内容可能随版本更新）
- [继续阅读本站归档](/archives/)