root指令不解析软链接，仅拼接路径后由系统自动跟随，若nginx用户无权访问软链接真实目标路径（缺x/r权限或selinux拦截），则触发403/404；推荐改用alias指定真实绝对路径，或确保软链接各级父目录对nginx用户有执行权、目标文件可读且selinux策略允许。
因为 root 指令本身不解析软链接，只是把路径和 URI 拼接后交由系统处理；而系统自动跟随软链接后，实际访问的是目标路径——如果 Nginx 进程无权读取那个真实位置，就会 403 或 404。
root + 软链接为什么会出错
root 不是“跳转到该路径”，而是做字符串拼接。比如：
- 配置 root /var/www/site;，请求 /index.html → 实际查找 /var/www/site/index.html
- 若 /var/www/site 是指向 /home/user/app 的软链接，系统最终访问的就是 /home/user/app/index.html
- 但 Nginx worker 通常以 www-data 或 nginx 用户运行，它很可能没权限进入 /home/user/ 目录（缺少执行权限 x），更别说读文件了
最稳妥的解法：改用 alias
alias 直接指定真实路径，绕过软链接解析逻辑，部署时只需更新软链接目标，Nginx reload 即可生效：
- 确保 alias 值是软链接的**真实目标路径**，且为绝对路径
- alias 结尾必须带 /（如 alias /home/user/app/static/;）
- location 前缀会被完全替换，/static/logo.png 就对应 /home/user/app/static/logo.png
坚持用 root 的前提条件
如果必须保留 root + 软链接结构，需同时满足：
- 软链接指向的真实目录及其所有父级目录（如 /home、/home/user）都对 Nginx 用户有执行权限（x）
- 真实目录及其中文件对 Nginx 用户可读（r），可用 sudo -u www-data ls -l /path/to/target 验证
- SELinux 或 AppArmor 策略允许访问该路径（常见于 CentOS/RHEL，可用 setsebool -P httpd_read_user_content 1 临时放开）
快速定位问题的方法
别猜，直接看日志和权限：
- 查 /var/log/nginx/error.log，找类似 open() "/home/user/app/index.html" failed (13: Permission denied) 的报错
- 用 ls -l /var/www/site 确认软链接指向是否正确
- 逐级检查目标路径的父目录权限：ls -ld /home /home/user /home/user/app，每层都要有 x
- 模拟 Nginx 用户操作：sudo -u www-data cat /home/user/app/index.html
