Nginx alias映射返回403或404的主因是权限配置不当：目录需有x权限供Nginx用户逐级进入，文件需r权限，且整个路径链属主/组须匹配worker进程用户（如www-data或nginx），SELinux或Docker UID/GID不匹配也会导致失败。
Nginx 使用 alias 映射路径时，返回 403 Forbidden 或 404（实际文件存在）往往不是配置写错了，而是权限没配对。核心就三点：目录要有执行权、文件要有读取权、Nginx worker 进程用户得能进得去、看得见。
目录必须有 x（执行）权限
Linux 下，“进入目录”本质是执行该目录——哪怕只是 ls，也需要 x 权限。如果 /app/assets/ 目录权限是 750 但属组不是 Nginx 工作用户所属组，或权限是 744（无组/其他 x），Nginx 就卡在门口。
- ✅ 正确示例：
chmod 755 /app/assets或更安全的chmod 750 /app/assets+ 确保 Nginx 用户在对应组里 - ❌ 常见错误：
chmod 644 /app/assets（目录不能只有读权限）、chmod 700 /app/assets（其他用户/组完全不可访问，包括 nginx）
Nginx worker 用户需对整个路径链有权限
不只是 alias 指向的最终目录，从根目录开始每一级父目录（如 /app、/app/assets）都得让 Nginx 用户有 x 权限才能逐层进入。
- 检查命令：
namei -l /app/assets/js/app.js（显示每级目录的权限和属主） - 若某一级是
drw-r--r--（无 x），即使最终文件可读，也会 403
确认 Nginx worker 进程运行身份
默认可能是 www-data（Debian/Ubuntu）、nginx（CentOS/RHEL）或 nobody。Docker 中常被覆盖为 nginx 或自定义用户。
- 查看方式：
ps aux | grep nginx | grep -v grep→ 找worker process行的用户名 - 配置中可显式指定（推荐）：
user nginx;
- Docker 场景下，若用 volume 挂载宿主机目录，注意挂载后容器内路径的属主是否匹配该用户（例如
docker run -u 1001:1001 -v ./dist:/app/dist ...）
SELinux 或 AppArmor 可能拦截（仅限特定系统）
CentOS/RHEL 默认启用 SELinux，即使文件权限全开，也可能因上下文限制拒绝访问。
- 临时验证：
setenforce 0（不推荐生产），若 403 消失，说明是 SELinux 问题 - 永久修复：
chcon -R -t httpd_sys_content_t /app/assets/或用semanage fcontext规则持久化
Docker 容器内权限特别注意点
- 挂载的宿主机目录，其 UID/GID 在容器内未必对应
nginx用户（尤其 Mac/Windows 主机） - 构建镜像时
COPY的文件，默认属主是 root；若user nginx;启动，需提前chown -R nginx:nginx /app/assets/ - Alpine 镜像中
nginx用户 UID 常为 101，而宿主机挂载目录属主 UID 是 1000，就会权限不匹配
快速自查清单
-
ls -ld /app /app/assets→ 每级都有x吗？ -
ls -l /app/assets/→ 文件是否可读？属主/组是否匹配 Nginx 用户？ -
id -u nginx和stat -c "%U %G" /app/assets→ UID/GID 是否一致？ -
curl -I http://localhost/static/js/app.js→ 返回 403 还是 404？403 就是权限问题，404 才回头查路径映射
不复杂但容易忽略 —— alias 映射再准，路径权限断一环，Nginx 就只能干瞪眼。
