页面资源加载失败、JS 请求返回 404，很多时候不是应用本身先出问题，而是静态资源路径、反向代理或部署目录没对上。要在 Linux 服务器上尽快把问题定位出来，最直接的方法就是先确认 Web 服务器日志文件位置，再用 grep 把 404 记录筛出来，必要时结合实时追踪和最近日志截取来判断问题是持续存在，还是刚刚发生。

下面按 Apache 和 Nginx 两类常见环境，整理一套可以直接上手的排查方法。你可以用这些命令快速确认 404 来自哪类请求、日志里是否正在持续出现，以及应该看“最早几条”还是“最新几条”记录。

先确认 404 日志在哪个文件

排查 404 的第一步，不是急着搜索关键字，而是先确定当前服务器用的是哪种 Web 服务器，以及对应日志文件路径。

Apache 的常见日志位置

• 访问日志：/var/log/apache2/access.log
• 错误日志：/var/log/apache2/error.log

Nginx 的常见日志位置

• 访问日志：/var/log/nginx/access.log
• 错误日志：/var/log/nginx/error.log

如果你面对的是前端 JS、图片、接口地址等资源访问失败，通常先从对应服务器的日志入手，能最快看到请求是否确实返回了 404。

用 grep 直接筛出 404 记录

确认路径之后，就可以直接用 grep 搜索 404。这里保留空格是为了尽量避免误匹配到其他数字组合。

Apache 环境命令

grep ' 404 ' /var/log/apache2/error.log

Nginx 环境命令

grep ' 404 ' /var/log/nginx/error.log

执行后，终端会列出所有包含 404 的日志行。对于已经出现过的报错，这通常是最快的一步：先看请求路径，再判断是文件不存在、路由没配好，还是代理转发到了错误位置。

问题正在发生时，用 tail -f 实时盯日志

如果你正在复现问题，比如浏览器里一刷新页面就会报某个 JS 文件 404，那么只查历史日志还不够，更适合直接实时跟踪新写入的记录。

Apache 实时查看

tail -f /var/log/apache2/error.log | grep ' 404 '

Nginx 实时查看

tail -f /var/log/nginx/error.log | grep ' 404 '

这样做的好处是，新的 404 一出现就会立刻显示出来，特别适合排查“刚发布后某个资源路径不对”“某个接口被错误重写”这类在线问题。

只看部分结果时，分清 head 和 tail 的区别

有时候日志太多，你只想先抽几条看。这时可以在 grep 后面接 head 或 tail，但两者含义不同，不能混着用。

查看前 10 条匹配记录

grep ' 404 ' /var/log/apache2/error.log | head -n 10

这条命令会返回匹配结果里的前 10 条。由于日志文件通常按时间顺序追加，head 看到的往往是更早的一批记录。

什么时候该用 tail

如果你的目标是看最新发生的 404，而不是最早的那几条，那么一般要把 head 换成 tail。这在排查刚上线后新增的问题时尤其重要，因为你通常更关心最近一次请求到底打到了哪里。

排查 404 时的实用判断思路

把命令跑通之后，接下来就不是“会不会查”，而是“怎么判断结果有用”。实际处理中，可以按下面这个顺序看：

• 先确认服务器类型，避免在错误的日志路径里浪费时间。
• 先跑一次 grep 看历史记录，判断 404 是偶发还是大量存在。
• 如果问题正在复现，用 tail -f 盯住新日志，确认浏览器操作是否立刻触发 404。
• 如果输出太多，再用 head 或 tail 截取一部分，分别查看较早记录或最新记录。

对前端场景来说，JS 日志里看到 404 往往只是表象，真正的定位仍要回到 Linux 服务器日志。只要路径找对，命令本身并不复杂，关键是根据场景选对“历史筛选”“实时跟踪”还是“最新几条记录”。