Nginx 为什么 root 指令指定的路径在软链接下会失效如何解决

root指令不解析软链接，仅拼接路径后由系统自动跟随，若Nginx用户无权访问软链接真实目标路径（缺x/r权限或SELinux拦截），则触发403/404；推荐改用alias指定真实绝对路径，或确保软链接各级父目录对Nginx用户有执行权、目标文件可读且SELinux策略允许。

因为 root 指令本身不解析软链接，只是把路径和 URI 拼接后交由系统处理；而系统自动跟随软链接后，实际访问的是目标路径——如果 Nginx 进程无权读取那个真实位置，就会 403 或 404。

root + 软链接为什么会出错

root 不是“跳转到该路径”，而是做字符串拼接。比如：

1. 配置 root /var/www/site;，请求 /index.html → 实际查找 /var/www/site/index.html
2. 若 /var/www/site 是指向 /home/user/app 的软链接，系统最终访问的就是 /home/user/app/index.html
3. 但 Nginx worker 通常以 www-data 或 nginx 用户运行，它很可能没权限进入 /home/user/ 目录（缺少执行权限 x），更别说读文件了

最稳妥的解法：改用 alias

alias 直接指定真实路径，绕过软链接解析逻辑，部署时只需更新软链接目标，Nginx reload 即可生效：

1. 确保 alias 值是软链接的**真实目标路径**，且为绝对路径
2. alias 结尾必须带 /（如 alias /home/user/app/static/;）
3. location 前缀会被完全替换，/static/logo.png 就对应 /home/user/app/static/logo.png

坚持用 root 的前提条件

如果必须保留 root + 软链接结构，需同时满足：

1. 软链接指向的真实目录及其所有父级目录（如 /home、/home/user）都对 Nginx 用户有执行权限（x）
2. 真实目录及其中文件对 Nginx 用户可读（r），可用 sudo -u www-data ls -l /path/to/target 验证
3. SELinux 或 AppArmor 策略允许访问该路径（常见于 CentOS/RHEL，可用 setsebool -P httpd_read_user_content 1 临时放开）

快速定位问题的方法

别猜，直接看日志和权限：

1. 查 /var/log/nginx/error.log，找类似 open() "/home/user/app/index.html" failed (13: Permission denied) 的报错
2. 用 ls -l /var/www/site 确认软链接指向是否正确
3. 逐级检查目标路径的父目录权限：ls -ld /home /home/user /home/user/app，每层都要有 x
4. 模拟 Nginx 用户操作：sudo -u www-data cat /home/user/app/index.html