遇到 Nginx 异常时，先看错误日志通常比盲目改配置更有效。但不少人在排查一开始就会卡住：日志文件到底放在哪、该用什么命令看、看到空日志又该怎么判断。下面按“先确认位置，再快速查看，最后处理常见异常”的顺序梳理一遍，方便你在实际故障中直接照着操作。

确认 Nginx 错误日志位置

Nginx 错误日志在 Linux 上的默认路径通常是 /var/log/nginx/error.log，但实际环境里，这个位置经常会被配置文件改掉。因此在动手查看之前，最好先确认 error_log 指令到底写在哪里，避免对着错误路径排查。

可以先在 Nginx 配置目录里搜索 error_log：

# 搜索主配置文件中的error_log指令（主配置文件一般位于/etc/nginx/nginx.conf）
sudo grep -r "error_log" /etc/nginx/
# 或检查虚拟主机配置（如sites-a vailable/default）
sudo grep -r "error_log" /etc/nginx/sites-a vailable/

如果没有搜到自定义配置，一般就可以按默认路径 /var/log/nginx/error.log 处理。对多站点或多配置环境来说，这一步尤其重要，因为不同虚拟主机也可能写入不同日志文件。

用命令行查看错误日志

实时跟踪最新错误

如果你刚修改过配置、重载过服务，或者正在复现某个访问错误，最实用的方式就是实时盯日志输出。tail -f 会持续显示日志新增内容，适合边操作边观察。

sudo tail -f /var/log/nginx/error.log

执行后，新的报错会直接刷出来。查看结束时按 Ctrl+C 即可退出。

查看完整历史日志

如果你要回看之前的报错，而不是只看最新几行，可以按日志文件大小选择不同工具：

• cat：一次性输出全部内容，适合文件不大、想快速通读时使用。

  sudo cat /var/log/nginx/error.log

• less：适合较大的日志文件，支持逐页浏览和关键字搜索，查看时更省力，按 q 退出。

  sudo less /var/log/nginx/error.log

简单说，日志小用 cat，日志大优先用 less，避免终端被整份文件直接刷满。

按关键字过滤错误信息

当日志内容很多时，直接肉眼翻找效率很低。这时候可以用 grep 先把目标信息筛出来，再决定是否继续深挖。

• 查找所有包含“error”的行，忽略大小写：

  sudo grep -i "error" /var/log/nginx/error.log

• 查找特定报错，比如 “Connection refused”：

  sudo grep "Connection refused" /var/log/nginx/error.log

• 统计某类错误出现次数，比如 “404” 出现了多少次：

  sudo grep -c "404" /var/log/nginx/error.log

这种过滤方式的价值在于，先缩小范围，再定位上下文。尤其在访问量较高、错误信息密集的服务器上，关键字筛选往往比逐行翻日志更高效。

查看日志时的常见问题

权限不足，提示 Permission denied

如果命令执行时报 Permission denied，通常不是日志有问题，而是当前用户没有读取权限。最直接的做法就是在命令前加 sudo。

原文里也给出了切换到 root 用户的方式：

sudo su -tail -f /var/log/nginx/error.log

不过从实际使用习惯看，单条命令前加 sudo 往往更稳妥，既能完成查看，也不容易把操作范围放大。

提示文件不存在，日志路径不符

如果你照着默认路径去看，却收到文件不存在的提示，优先考虑的不是服务坏了，而是日志路径被改过。最常见的原因，就是配置文件里自定义了 error_log 位置。

这时回到前面的搜索步骤，重新检查 error_log 指令即可。确认真实路径后，再用 tail、less 或 grep 继续分析。

日志文件存在，但内容为空

日志为空不一定表示异常。有时候只是 Nginx 最近没有产生错误，或者服务本身并没有运行。遇到这种情况，可以先确认服务状态：

sudo systemctl status nginx

如果服务没有启动，就先启动再观察：

sudo systemctl start nginx

如果 Nginx 正常运行，而日志仍然为空，那么反而说明当前时间段内没有产生新的错误信息。这种情况下，重点就该转向是否能稳定复现问题，而不是单纯盯着空日志反复猜测。

更省时间的排查顺序

真正排查 Nginx 故障时，建议按照这个顺序来：

1. 先确认 error_log 的实际路径；
2. 用 sudo tail -f 实时观察最新报错；
3. 需要翻历史时，用 less 或 cat；
4. 日志太多时，再用 grep 按关键字过滤；
5. 如果看不到内容，再检查权限、路径和服务状态。

这样处理的好处是，先拿到最新线索，再决定是否扩大范围，不容易一上来就陷进大文件或错误目录里。对大多数“配置改完后站点打不开”“反向代理报错”“启动失败”这类问题，这套顺序基本都适用。