排查 try_files 404 需确认实际检查路径、root/alias 配置正确性、文件存在与权限，开启 info 级 error_log 查看匹配过程，注意 fallback URI 触发新 location 匹配及 rewrite 干扰。
排查 try_files 导致的 404，关键不是看返回结果，而是确认 Nginx 实际尝试了哪些路径、是否真的没找到、以及有没有被其他配置干扰。
确认 try_files 的实际匹配顺序和路径拼接
Nginx 按照 try_files 后列出的项**从左到右依次检查**，每个路径都是相对于 root 或 alias 指令指定的根目录。注意：它不会自动补全扩展名或做重写，只做“是否存在文件/目录”的物理判断。
- 检查
root（或alias）是否配置正确，路径末尾不加斜杠（root /var/www/html✅，不是/var/www/html/❌） - 用绝对路径验证文件是否存在：
ls -l /var/www/html/index.php，确保权限可读（Nginx 工作进程用户如www-data或nginx能读取） - 如果用了
alias，注意它会**完全替换 location 匹配部分**，容易导致路径错位，建议优先用root
开启 error_log 查看 try_files 的内部决策过程
Nginx 默认不会记录 try_files 的逐项检查过程，但把日志级别调到 info 就能看到：
- 在
http、server或location块中添加：
error_log /var/log/nginx/debug.log info; - 重启 Nginx，触发一次 404 请求，然后查看日志：
tail -f /var/log/nginx/debug.log | grep -i "try_files\|open\|stat" - 你会看到类似：
... *1 open() "/var/www/html/test" failed (2: No such file or directory)... *1 try_files: "/test" -> "/test.html" -> "/test/index.html" -> "/index.php"
排除 rewrite、internal、fastcgi_pass 等干扰行为
try_files 最后一个参数如果是 URI（以 / 开头），Nginx 会**内部重定向**到该 URI，不再走当前 location，而是重新匹配 location —— 这常被忽略：
- 例如：
try_files $uri $uri/ /index.php?$args;，最后的/index.php会触发新 location 匹配，如果没配location ~ \.php$或 fastcgi 相关指令，就会直接 404（而不是进 PHP） - 检查该 fallback URI 是否有对应 location 块，且该 location 中有正确的
fastcgi_pass和fastcgi_param - 确认没有其他
rewrite规则提前终止或覆盖了 try_files 的流程（last会跳出，break会停止 rewrite 但继续后续处理）
用 curl + -v 配合 echo 测试最小化复现
绕过浏览器缓存和前端路由干扰，直击 Nginx 行为：
- 构造请求：
curl -v http://your-site/test，观察响应头中的Server和X-Accel-Redirect等字段 - 临时在对应 location 中加一行测试：
add_header X-Try-Files-Debug "$uri → $request_filename";
再请求就能从响应头看到 Nginx 解析出的真实文件路径 - 配合
echo $request_filename;（需加载 echo 模块）或用log_format自定义日志记录$request_filename，确认最终拼出的磁盘路径是否合理
