nginx报“找不到目录”本质是权限或路径问题：需确认root/alias配置，手动拼出nginx实际查找的物理路径（如root /var/www/app + uri /admin/ → /var/www/app/admin/），逐级检查各目录是否存在、是否对nginx用户（如www-data）具备执行权限（x位），并排除selinux/apparmor干扰。
遇到 try_files 报“找不到目录”（实际是 403 或 404），本质不是 try_files 本身出错，而是 Nginx 在按它指定的路径查找文件时，被系统权限或路径配置拦住了。重点不是查 try_files 语法，而是顺着它拼出的物理路径，一层层验证是否“可进、可看、可读”。
确认 Nginx 实际查找的完整路径
try_files $uri $uri/ /index.html 中的 $uri/ 是指“把请求路径当目录查”，比如访问 /admin/，Nginx 就会去检查 /var/www/app/admin/ 这个目录是否存在。要定位问题，必须还原这个真实路径：
- 查生效的
root或alias：运行nginx -T | grep -A 5 "location /"，找到你配 try_files 的 location 块里实际生效的 root 值 - 手动拼接：例如 root 是
/var/www/myapp，请求 URI 是/assets/，那 Nginx 就去找/var/www/myapp/assets/ - 用
ls -ld /var/www/myapp/assets/看目录是否存在、权限是否显示drwxr-xr-x这类含x（执行）位
检查目录执行权限（关键但常被忽略）
Linux 中，“进入一个目录”需要该目录有执行权限（x）。即使文件可读，没有 x 权限也会报 403 Forbidden。
- 逐级检查父目录：
ls -ld /var /var/www /var/www/myapp /var/www/myapp/assets/—— 每一级都得有 x 权限给 Nginx 用户 - 修复命令（以 www-data 用户为例）：
sudo chmod 755 /var/www/myapp/assets/；若需递归设目录权限：sudo find /var/www/myapp -type d -exec chmod 755 {} \; - 注意：chmod 755 给目录，644 给文件；别对整个目录用 777，不安全
验证 Nginx 进程用户是否有访问权
Nginx 不是以你登录的用户运行的，而是配置中指定的用户（如 nginx 或 www-data）。它必须能“以该身份”访问路径。
- 查运行用户：
grep "user " /etc/nginx/nginx.conf，常见为user www-data;或user nginx; - 模拟访问：
sudo -u www-data ls -l /var/www/myapp/assets/—— 如果提示Permission denied，说明权限不足 - 修复属主：
sudo chown -R www-data:www-data /var/www/myapp，再配合上面的 chmod
排除 SELinux 或 AppArmor 干扰
在 CentOS/RHEL 或 Ubuntu 启用强制访问控制的系统上，即使权限全对，也可能因策略限制被拒。
- 查 SELinux 状态：
sestatus；若为 enforcing，临时测试：sudo setenforce 0，再试请求。若恢复访问，就是它导致的 - 永久放行：
sudo chcon -R -t httpd_sys_content_t /var/www/myapp - AppArmor（Ubuntu）：
sudo aa-status查是否启用，必要时调整 profile
