页面 404 但文件明明在

文件用 ls 看得到，浏览器访问却 404，说明请求路径和文件实际位置没对上。嫌疑通常就四个，按命中概率排序。 嫌疑一：大小写 Linux 文件系统区分大小写，Logo.PNG 和 logo.png 是两个文件。从 Windows 本地环境上传的文件，大小写对不上是 404 的头号来源。用 ls 逐字符核对目录里的文件名和 URL 是否一致。快速验证的办法：把 URL 路径改成全小写再访问一次，能打开就是大小写的锅。团队约定统一用小写加连字符命名文件，是最省心的根治办法，比写一堆兼容规则可靠。 嫌疑二：根目录指错 nginx 的 root 指令可以在 server 块和 location 里分别出现，location 里单独写 root 很容易指偏。要确认请求实际命中的 location 里 root 或 alias 拼出来的路径：root 不拼接 location 前缀，alias 会替换匹配前缀且结尾必须带斜杠，两者混用是经典错误。nginx -T | grep root 能列出当前生效配置里的全部 root，比逐个翻配置文件快。改完执行 nginx -t && nginx -s reload。 嫌疑三：伪静态规则改写了路径 rewrite 和 try_files 会把用户请求的 URL 映射到别的文件，规则写错就映射到不存在的位置。常见的 try_files $uri $uri/ /index.php?$query_string; 含义是先找同名文件、再找同名目录、都找不到就交给入口脚本处理，如果入口脚本的路由解析有误，用户看到的就是 404。各类框架和建站程序的入口路由都靠这条规则兜底，动它之前先确认站点依赖。把相关规则临时注释再测一次，恢复正常即可定罪。error.log 里的 open() ... failed (2: No such file or directory) 会直接写出服务器实际在找哪个路径，对照修改。 嫌疑四：缓存了旧的 404 文件刚补上去还是 404，可能是缓存把上次的 404 结果存住了。强刷（Ctrl+F5）验证自己的浏览器；站点前面有 CDN 的话，浏览器强刷不够，要去 CDN 平台把对应路径的缓存刷新掉。还有一类 404 是应用自己返回的：路由表里没有这条路径，框架直接吐 404，和 Web 服务器无关，看应用日志确认。 四个嫌疑都排除仍无头绪，就在服务器本地直接 curl -I http://127.0.0.1/路径，把浏览器、CDN 这些外部变量全部摘掉，剩下的就是服务器自己的问题。