直接查看 /var/log/nginx/access.log 中状态码为404的日志行，可快速定位问题url、客户端ip及发生时间；结合 error.log 分析缺失原因，并通过 nginx -t 和 ls -l 验证文件路径与权限。
直接看 /var/log/nginx/access.log 里带 404 的那几行，就能快速锁定是哪个 URL、哪个客户端、什么时间出的问题。
从 access.log 快速定位 404 请求
每条日志包含客户端 IP、请求时间、HTTP 方法、URI、状态码等关键字段。404 错误一定出现在状态码字段为 404 的记录中。
- 实时监控：运行
tail -f /var/log/nginx/access.log | grep " 404 "（注意前后空格，避免匹配到 4040 或 2404） - 查最近一批：用
grep " 404 " /var/log/nginx/access.log | tail -20 - 按时间筛选：比如查今天上午的 404，可加
awk：awk '$4 ~ /\[25\/Sep\/2026:0[8-11]/ && $9 == "404"' /var/log/nginx/access.log
结合 error.log 看更深层原因
access.log 只告诉你“谁访问了什么并返回了 404”，但不解释“为什么找不到”。这时候要查 /var/log/nginx/error.log：
- 常见提示如：
open() "/var/www/html/xxx.js" failed (2: No such file or directory)—— 文件确实不存在 - 或：
directory index of "/var/www/html/" is forbidden—— 目录没配index，且没开启autoindex - 还有权限相关：
Permission denied，说明路径存在但 Nginx 进程读不了
反向验证：把日志里的 URI 拼成真实路径
拿到一条 404 日志，例如：
192.168.1.100 - - [25/Sep/2026:08:42:11 +0000] "GET /css/main.css HTTP/1.1" 404 153 "-" "Mozilla/5.0"你需要做三件事：
- 查生效的
root：运行nginx -T | grep -A 2 "location /css"，确认该 location 实际使用的 root 路径（比如/usr/share/nginx/html） - 手动拼路径：root + URI =
/usr/share/nginx/html/css/main.css - 执行
ls -l /usr/share/nginx/html/css/main.css，看文件是否存在、大小写是否一致、权限是否可读
别漏掉重定向和前端路由干扰
某些 404 其实是假象：
- SPA 应用（如 Vue/React History 模式）未配置
try_files，导致刷新子路由时 Nginx 直接找文件，自然 404 - CDN 或浏览器缓存了旧 URL（比如大小写变化、多一个斜杠），实际请求已不是你预期的路径
- 前端发的是 OPTIONS 预检请求，后端没响应，浏览器就报 404 —— 这类请求在 access.log 中也可见，但需结合 CORS 配置判断
