Nginx 如何排查使用 Alias 指令时目标目录缺少读权限引发的 403 故障

Nginx 403错误首要排查alias路径权限与拼接：确认worker进程用户对alias每级目录有x权限、文件有r权限，末尾斜杠缺失会导致路径粘连而静默返回403，同时需检查SELinux/AppArmor拦截及location内allow/deny规则。

看到 403，先别急着改配置或查日志，直接确认 Nginx 进程有没有权限进入 alias 指向的物理目录——这是最常被跳过的一步。

确认 Nginx 工作用户与目录属主匹配

Nginx 必须能“进入” alias 后路径的每一级目录（即有执行 x 权限），同时能“读取”目标文件（即有读 r 权限）。关键不是你能不能 ls，而是 nginx 用户能不能。

1. 查当前工作用户：ps aux | grep "nginx: worker" | head -1 | awk '{print $1}'
2. 查 alias 实际指向路径：比如 location /static/ { alias /data/www/assets/; }，目标就是 /data/www/assets/
3. 逐级检查权限：ls -ld /data /data/www /data/www/assets，确保每层都有 x（对 nginx 用户或所属组）
4. 若属主不匹配，可改目录归属：sudo chown -R nginx:nginx /data/www/assets，或加 nginx 到对应用户组

验证 alias 路径拼接是否准确

alias 不是重写，是替换。末尾少一个 / 就会让路径粘连，最终访问到错误位置，而该位置往往不存在或无权限，Nginx 静默返回 403（不是 404）。

1. 错误示例：alias /data/www/assets;（缺末尾斜杠）→ 请求 /static/js/app.js 会找 /data/www/assetsjs/app.js
2. 正确写法：alias /data/www/assets/;（末尾必须带 /）→ 拼出 /data/www/assets/js/app.js
3. 用 echo 快速模拟：echo "/data/www/assets" + "js/app.js" 看是否粘连；补斜杠再试

检查 SELinux 或 AppArmor 是否拦截

即使传统权限全开，SELinux（CentOS/RHEL）或 AppArmor（Ubuntu/Debian）也可能在内核层拒绝访问，不报错、不写日志，只返回 403。

1. 临时关闭 SELinux 测试：sudo setenforce 0，若 403 消失，说明是它在拦截
2. 恢复后打标签：sudo semanage fcontext -a -t httpd_sys_content_t "/data/www/assets(/.*)?"，再 restorecon -Rv /data/www/assets
3. AppArmor 可查日志：sudo dmesg | grep -i avc，看是否有 denied 记录

排除 location 内部访问控制干扰

Nginx 的 allow/deny 或 satisfy 规则可能覆盖默认行为，尤其在内部系统中容易误配。

1. 确认 location 块里没写 deny all; 或未明确放行
2. 简单测试可临时加：allow all; 和 satisfy any;（注意顺序，satisfy 需配合 allow/deny）
3. 若用了认证模块（如 auth_basic），未通过也会返回 403，需单独验证