符号链接配置错误导致404的主因是链接不可达、nginx未启用follow_symlinks或selinux/nfs限制；需逐级验证链接有效性，配置disable_symlinks off，修复上下文权限，并用$request_filename与readlink定位真实路径。
符号链接（symlink）配置错误在 Nginx 中常表现为 404，但实际文件存在、权限正常、路径拼写也无误——问题就藏在链接本身是否有效、是否可穿透、是否被 Nginx 允许访问。
确认符号链接是否真实可达
进入 Nginx 配置中 root 或 alias 指向的目录，用 ls -l 查看目标路径是否为符号链接，并检查其指向是否真实存在：
- 运行
ls -l /var/www/html，若输出类似html -> /opt/myapp/dist，说明是软链 - 再执行
ls -l /opt/myapp/dist，确认该路径存在且非空；若提示No such file or directory，说明目标已丢失或路径写错 - 注意：符号链接可以嵌套多层，需逐级
ls -l追踪到底，直到看到真实目录或文件
检查 Nginx 是否允许跟随符号链接
Nginx 默认禁止解析符号链接，必须显式启用 follow_symlinks（在 location 或 server 块中）：
- 在对应 location 块内添加：
disable_symlinks off;（Nginx ≥ 1.17.2）或旧版用disable_symlinks on; from=/;（不推荐） - 更稳妥的做法是直接在 location 中加：
disable_symlinks off;，并确保它位于 root/alias 指令之后 - 若使用
alias，注意 disable_symlinks 对 alias 的支持较弱，建议优先改用root+ 调整路径结构
验证 SELinux 或文件系统限制
即使链接可达、Nginx 允许跟随，SELinux 或挂载选项也可能拦截访问：
- 运行
ls -lZ /opt/myapp/dist，检查上下文是否为httpd_sys_content_t；若为unconfined_u等，需修复：chcon -Rt httpd_sys_content_t /opt/myapp/dist - 若目标路径挂载自 NFS 或 bind mount，确认挂载时启用了
follow_symlinks（如 NFSv4 默认禁用） - 检查
/proc/mounts或findmnt输出，留意是否有nosymfollow或类似标志
快速定位是否 symlink 导致 404
别猜，用 Nginx 自身能力验证真实访问路径：
- 在出问题的 location 块里临时加入：
return 200 "real: $request_filename\nlink: $(readlink -f $request_filename 2>/dev/null || echo 'none')"; - 重启后
curl http://your.site/static/test.js，响应会显示 Nginx 解析出的真实路径和符号链接展开结果 - 对比输出中的路径与磁盘实际结构，一眼识别断链、循环链或越权跳转
