排查Nginx因root下软链接失效致404，关键是确认软链接是否有效：用ls -lh查状态，sudo -u www-data ls -l验证目标路径可读，检查disable_symlinks配置及SELinux上下文，最终依据error.log中open()失败路径逐级定位断链点。
排查 Nginx 中因 root 路径下软链接失效引发的 404，关键不是“文件找不着”，而是“Nginx 找到了路径，但路径指向了空或断开的链接”。软链接本身存在，但目标丢失、权限受限或上下文异常时，Nginx 会静默返回 404（而非 403 或 500），极易误判为配置或文件缺失问题。
确认软链接是否真实有效
进入你 root 指向的目录（如 /var/www/html），用 ls -lh 查看软链接状态：
- 若显示
broken或目标路径为红色（终端提示），说明软链接已断——目标文件/目录被删除、重命名或移动 - 若显示正常路径但
ls -l 目标路径报No such file or directory，确认目标是否存在且路径拼写完全一致（注意大小写） - 软链接嵌套过深（如 A→B→C→D）时，Nginx 默认只解析一级；需确保
nginx.conf中启用了disable_symlinks off;（仅限较新版本），否则中间任一环节断开即失败
验证 Nginx 是否能穿越软链接读取目标
Nginx worker 进程必须对软链接**本身**和**最终目标路径**都具有读（r）和执行（x）权限：
- 运行
ps aux | grep nginx查看 worker 用户（如www-data） - 切换用户测试：
sudo -u www-data ls -l /var/www/html/static（假设 softlink 名为 static） - 若报
Permission denied，检查软链接文件权限（chmod 755 /var/www/html/static）及目标目录权限（父目录需有 x 权限才能进入） - SELinux 启用时，还需确认软链接和目标目录的上下文均为
httpd_sys_content_t：ls -Z /var/www/html/static；不匹配则用chcon -h -t httpd_sys_content_t /var/www/html/static（-h表示作用于链接本身）
检查 Nginx 配置是否隐式禁用软链接
某些安全加固配置会主动拦截符号链接行为：
- 搜索配置中是否有
disable_symlinks on;或disable_symlinks if_not_owner;—— 若存在且未配合from=...白名单，则所有软链接均被拒绝 - 检查
location块内是否误加了satisfy any;或 IP 限制，导致请求未走到文件读取阶段就中断 - 确认没有在
server或http块中全局设置alias或rewrite规则，意外覆盖或改写了原始 URI
快速定位：从 error.log 抓真实路径
Nginx 的 error.log 是最直接证据源：
- 触发一次 404 请求后，立即查看日志：
tail -f /var/log/nginx/error.log | grep "No such file" - 日志中会明确写出 Nginx 尝试打开的**最终物理路径**，例如：
open() "/var/www/html/static/css/app.css" failed (2: No such file or directory) - 顺着这个路径，逐级执行
ls -l，直到发现哪一级是软链接、哪一级开始“消失”——这一步能精准定位是链接断开，还是目标不可达
