很多 VPS 问题其实日志里早就写清楚了，只是没人看。
我见过一个朋友，Node 服务一直启动失败，他反复执行：
systemctl restart app
重启了十几次还是不行。最后看了一眼日志，里面明明写着 EADDRINUSE: address already in use，端口被旧进程占着。问题不是服务器不稳定，也不是代码玄学，就是没看日志。
所以这篇不讲复杂监控，只讲最实用的一件事：VPS 出问题时，先去哪看日志、怎么看、看到什么关键词该往哪个方向查。
服务出问题，第一条命令通常是：
systemctl status 服务名
比如：
systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status app
重点看这几行：
Active:是 running、failed 还是 activatingMain PID:有没有进程- 最近几行日志有没有报错
code=exited后面的退出码是什么- 有没有
permission denied、address already in use、cannot bind之类提示
systemctl status 适合快速判断服务当前状态，但它只显示一小段日志。要看完整日志，要用 journalctl。
如果服务是 systemd 管理的，最常用命令是：
journalctl -u 服务名 -n 100 --no-pager
比如：
journalctl -u nginx -n 100 --no-pager
journalctl -u docker -n 100 --no-pager
journalctl -u app -n 100 --no-pager
想实时看日志：
journalctl -u 服务名 -f
想看某个时间之后的日志：
journalctl -u 服务名 --since "1 hour ago"
journalctl -u 服务名 --since "2026-05-13 10:00:00"
如果服务刚刚重启失败，我一般这样看：
systemctl restart app
journalctl -u app -n 100 --no-pager
不要只看最后一行。很多真正原因在倒数第十几行，比如配置文件读取失败、环境变量缺失、端口占用。
有些问题不是单个服务的问题，而是开机、磁盘、内存、网络或内核层面的问题。
看本次启动后的日志：
journalctl -b -n 200 --no-pager
看上一次启动的日志：
journalctl -b -1 -n 200 --no-pager
如果 VPS 无故重启、服务突然挂掉，可以查：
last reboot
journalctl -b -1 -p warning --no-pager
常见关键词：
Out of memory：内存不够，被 OOM killKilled process：某个进程被系统杀掉segfault：程序崩溃I/O error：磁盘或文件系统问题No space left on device：磁盘满了permission denied：权限问题
这些比“感觉服务器不稳定”有用得多。
Nginx 最常看的两个日志：
/var/log/nginx/access.log
/var/log/nginx/error.log
实时看错误：
tail -f /var/log/nginx/error.log
看最近访问：
tail -n 100 /var/log/nginx/access.log
如果浏览器访问 502，先看 error log。常见原因：
- upstream 端口错了
- 后端应用没启动
- Nginx 没权限访问 socket
- PHP-FPM 挂了
- 反向代理连接超时
如果访问 404，看 access log 和 server block。可能是：
- 域名进了错误的 server_name
- root 路径写错
- rewrite 规则不对
- 静态文件不存在
如果是 403，常见是权限或目录索引问题。
Nginx 配置改完后先跑：
nginx -t
systemctl reload nginx
不要直接重启。nginx -t 能提前告诉你配置有没有语法错误。
Docker 容器挂了，很多人只看：
docker ps
但真正原因通常在日志里：
docker logs 容器名 --tail 100
docker logs -f 容器名
如果是 docker compose：
docker compose ps
docker compose logs --tail 100 服务名
docker compose logs -f 服务名
常见关键词：
permission denied：挂载目录权限不对connection refused：依赖服务没起来或地址错了no such file or directory：配置文件路径错address already in use：端口冲突exit code 137：常见是内存不够被杀
容器反复重启时，不要只改 restart: always。它只能让容器不停重启，不能解决根因。
不同应用日志位置不一样。
常见位置：
/var/log/应用名/
/opt/应用名/logs/
/home/用户名/app/logs/
pm2 logs
如果是 Node + PM2：
pm2 status
pm2 logs --lines 100
如果是 Python / Gunicorn：
journalctl -u gunicorn -n 100 --no-pager
如果是 PHP-FPM：
journalctl -u php8.2-fpm -n 100 --no-pager
找不到日志时，先看服务文件：
systemctl cat 服务名
里面通常能看到启动命令、工作目录、环境变量文件。很多“程序启动不了”的原因，其实是工作目录错了、环境变量没加载、配置文件路径错了。
给一张速查表：
| 日志关键词 | 常见方向 |
|---|---|
address already in use | 端口被占用 |
permission denied | 文件权限、目录权限、端口权限 |
connection refused | 依赖服务没启动、端口不通 |
no such file or directory | 路径写错、文件不存在 |
No space left on device | 磁盘满了、inode 满了 |
Out of memory / Killed process | 内存不足、OOM kill |
bad gateway / upstream | Nginx 到后端不通 |
certificate / SSL | 证书、域名、HTTPS 配置问题 |
authentication failed | 密码、权限、数据库用户问题 |
timeout | 网络慢、依赖卡住、防火墙拦截 |
看到关键词后，不要急着复制整段报错去搜索。先结合场景判断：这是启动阶段、访问阶段、连接数据库阶段，还是反向代理阶段。
如果你要开工单或找人帮忙，日志要贴得刚好。
建议提供：
systemctl status 服务名
journalctl -u 服务名 -n 80 --no-pager
nginx -t
ss -lntp
如果是网站问题，再加：
tail -n 80 /var/log/nginx/error.log
tail -n 50 /var/log/nginx/access.log
不要直接贴几千行日志。别人看不完，也容易漏重点。
更重要的是，贴日志前先打码：
- 服务器 IP
- 数据库密码
- API Key
- Token
- Cookie
- 用户邮箱
- 后台路径
日志里经常会带敏感信息，尤其是应用错误栈和请求头。公开发到论坛、群聊前一定要检查。
如果一台 VPS 上服务出问题，我一般按这个顺序：
systemctl status 服务名journalctl -u 服务名 -n 100 --no-pagerss -lntp看端口df -h看磁盘free -m看内存- Nginx error log / access log
- 应用自己的 logs
- Docker / PM2 / PHP-FPM 日志
- 最近一次改动了什么配置
- 再决定重启、回滚还是改配置
这比“重启一下试试”靠谱很多。重启有时能暂时恢复，但也会把现场冲掉。特别是偶发问题，日志就是证据。
遇到问题时先问自己：
- 服务状态是 running 还是 failed
-
journalctl -u里最近 100 行有没有明显错误 - 有没有端口占用、权限、路径、磁盘、内存错误
- Nginx error log 是否有 upstream / 502 / 403 / 404 信息
- Docker 或 PM2 是否有独立日志
- 最近是否改过配置、证书、环境变量、依赖版本
- 是否打码后再把日志发给别人
VPS 排障最怕靠感觉。日志不一定能直接告诉你答案，但它会告诉你下一步该查哪里。先看日志，再动手改，能少走很多弯路。