404 错误由 Web 服务器（Apache/Nginx）在请求路由阶段返回，PHP 未参与处理，故不出现在 php-fpm.log 或 error_log 中；应查 access.log，结合 curl -I 验证状态码，并检查重写规则、文件权限与大小写。
PHP 错误日志本身通常不记录 404，因为 404 是 HTTP 状态码，由 Web 服务器（Apache/Nginx）在路由阶段决定，而非 PHP 解析或执行阶段触发。直接翻 php-fpm.log 或 error_log 却找不到 404 相关线索，不是日志丢了，而是你查错了地方。
先确认 404 是谁返回的
404 发生在请求抵达 PHP 之前——只要文件不存在、路径没匹配上、重写规则拦住了，Web 服务器就直接返回 404，根本不会把请求交给 PHP-FPM。所以 PHP 日志里自然“沉默”。
- 用
grep " 404 " /var/log/apache2/access.log或grep " 404 " /var/log/nginx/access.log查访问日志，这才是 404 的主战场 - 如果连访问日志里都看不到该请求，说明请求可能被防火墙拦截、DNS 解析失败，或浏览器根本没发出去（比如前端 JS 拼错 URL）
- 用
curl -I http://localhost/missing.php看响应头，确认状态码确实是404 Not Found，排除 301/302 重定向干扰
快速定位高频 404 资源路径
别人工扫日志。用一行命令揪出最常出问题的 URI，能立刻判断是死链、迁移遗漏，还是前端硬编码错误：
grep " 404 " /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -10
输出类似：
立即学习“PHP免费学习笔记（深入）”；
42 /wp-content/themes/twentytwentyone/style.css
18 /api/v1/users
9 /js/main.min.js
-
/wp-content/...→ 可能是 WordPress 主题升级后路径变更，或 CDN 缓存了旧资源 -
/api/v1/...→ 前端调用的接口地址写死，但后端已废弃或改版 - 全是静态资源 → 检查构建产物是否漏传，或
public/目录结构与代码引用不一致
检查重写规则是否“误杀”真实 PHP 文件
常见陷阱：项目用了单页应用（SPA）或 MVC 路由，.htaccess 或 Nginx 配置里写了兜底规则，却忘了放行真实存在的 .php 文件。
- 临时重命名
.htaccess为.htaccess.bak，刷新页面看是否恢复 → 若恢复，就是重写规则问题 - Apache 下典型“误杀”规则：
RewriteRule ^(.*)$ index.php [QSA,L]，它会把所有请求（包括about.php）都转给index.php，除非前面有RewriteCond %{REQUEST_FILENAME} -f显式放行 - Nginx 中警惕
try_files $uri $uri/ /index.html;被错误放在location ~ \.php$块里，这会导致 PHP 请求先被/index.html吞掉
验证 PHP 是否真的被调用过
如果某个 PHP 文件明明存在却始终 404，而其他 PHP 文件正常，说明问题不在日志，而在服务器是否把它当“PHP 脚本”处理：
- 创建一个极简
test.php，内容只有，放在同一目录下访问 → 若仍 404，说明 Web 服务器未启用 PHP 解析（如 Nginx 缺少location ~ \.php$块，或 Apache 未加载mod_php） - 若
test.php能返回alive，但目标文件仍是 404 → 检查文件权限：ls -l about.php，确保不是root:root且权限为600（Web 进程无法读取） - Linux 下注意大小写：
About.php和about.php是两个文件；Windows 不敏感，Linux 敏感 —— 开发环境和生产环境不一致时极易踩坑
真正卡住人的，往往不是“找不到日志”，而是默认去 PHP 日志里找一个 Web 服务器才该负责的状态码。盯住 access.log，配合 curl -I 和临时禁用重写，三招下来，95% 的 404 就能定位到具体哪一行配置、哪一个拼写、哪一次部署遗漏。
