nginx 本身不解析软链接（symbolic link）的 target 路径用于内部文件查找，它只按最终拼接出的物理路径做权限检查和读取。也就是说：软链接能否生效，取决于 nginx worker 进程是否有权访问链接指向的目标路径及其父目录，而不是链接本身的位置。
软链接在 root/alias 下的行为差异
当使用 root 指令时，nginx 将 location 匹配路径“追加”到 root 值之后，形成完整路径；若该路径中包含软链接，nginx 会先解析整个路径（包括软链接），再检查权限与存在性。
例如：
-
/var/www/html → /data/webroot（软链接） - 配置：
location /static/ { root /var/www/html; } - 请求
/static/js/app.js→ nginx 实际查找：/var/www/html/static/js/app.js→ 解析为/data/webroot/static/js/app.js
此时，nginx 需要同时具备对 /var/www/html（链接文件自身）、/data、/data/webroot 及其子路径的读取与执行（x）权限。缺任一环，就报 403 或 404。
而 alias 是直接替换，不拼接 location 路径。若 alias 指向一个软链接目录，nginx 同样会解析它，但只基于 alias 值本身做一次替换，逻辑更清晰，出错点更少。
硬链接无法跨文件系统，且对 nginx 几乎无实际价值
硬链接本质是同一 inode 的多个目录项，只能存在于同一文件系统内。nginx 在 open() 文件时操作的是 inode，因此只要路径最终能定位到目标 inode，硬链接与普通文件无异。
但硬链接有明显限制：
- 不能链接目录（仅超级用户可为目录创建硬链接，且极不安全，一般禁用）
- 无法跨分区或挂载点 —— 若静态资源分散在不同磁盘，硬链接不可行
- 更新源文件后，硬链接内容同步可见，但这不是 nginx 的特性，而是文件系统行为；nginx 不感知“是否硬链接”，只读 inode 内容
实践中，硬链接极少用于静态资源部署场景，既无必要，也易引发运维混淆。
常见陷阱与规避建议
以下问题高频出现，且常被误判为 nginx 配置错误：
-
软链接权限不足：nginx 用户（如 www-data）对软链接所在目录（如
/var/www）有 r-x，但对目标路径（如/data/webroot）无 x 权限 → 报 403。需确保每一级父目录都赋予 nginx 用户执行权限 -
相对路径软链接失效：如
/var/www/html → ../data/webroot，nginx 解析时以配置文件所在位置为基准？错。它始终以进程当前工作目录（通常是 nginx 安装根目录）为起点解析相对路径软链接 —— 极易出错。建议一律使用绝对路径创建软链接 -
SELinux/AppArmor 干预：即使权限全开，安全模块可能阻止进程穿越软链接。可通过
ausearch -m avc -ts recent或dmesg | grep avc查看拒绝日志 -
未启用 follow_symlinks：nginx 默认开启该选项（1.19.1+ 版本默认 on），但若手动设为 off，则所有软链接均被当作普通文件处理，导致 404。确认配置中未出现
disable_symlinks on;
替代方案比死磕软链接更可靠
若目标是灵活同步或切换静态资源版本，推荐以下更可控的方式：
-
alias + 版本化目录：将资源放在
/opt/static/v1.2.0/，用alias /static/ /opt/static/v1.2.0/;，升级时仅改 alias 指向 -
mount bind：用
mount --bind /data/webroot /var/www/html/static替代软链接，语义明确、权限模型一致、SELinux 友好 -
符号链接仅用于顶层入口：如
/var/www/current → /var/www/releases/20260507，再配合root /var/www/current;，减少嵌套层级，降低解析失败概率
本质上，软链接不是 nginx 的功能组件，而是文件系统层的机制。nginx 对它的支持是被动的、有限的。把路径治理重心放在目录结构设计和权限收敛上，比依赖链接跳转更稳健。
