Nginx 403错误首要排查alias路径权限与拼接：确认worker进程用户对alias每级目录有x权限、文件有r权限，末尾斜杠缺失会导致路径粘连而静默返回403，同时需检查SELinux/AppArmor拦截及location内allow/deny规则。
看到 403，先别急着改配置或查日志，直接确认 Nginx 进程有没有权限进入 alias 指向的物理目录——这是最常被跳过的一步。
确认 Nginx 工作用户与目录属主匹配
Nginx 必须能“进入” alias 后路径的每一级目录（即有执行 x 权限），同时能“读取”目标文件（即有读 r 权限）。关键不是你能不能 ls，而是 nginx 用户能不能。
- 查当前工作用户：
ps aux | grep "nginx: worker" | head -1 | awk '{print $1}' - 查 alias 实际指向路径：比如
location /static/ { alias /data/www/assets/; }，目标就是/data/www/assets/ - 逐级检查权限：
ls -ld /data /data/www /data/www/assets，确保每层都有x（对 nginx 用户或所属组） - 若属主不匹配，可改目录归属：
sudo chown -R nginx:nginx /data/www/assets，或加 nginx 到对应用户组
验证 alias 路径拼接是否准确
alias 不是重写，是替换。末尾少一个 / 就会让路径粘连，最终访问到错误位置，而该位置往往不存在或无权限，Nginx 静默返回 403（不是 404）。
- 错误示例：
alias /data/www/assets;（缺末尾斜杠）→ 请求/static/js/app.js会找/data/www/assetsjs/app.js - 正确写法：
alias /data/www/assets/;（末尾必须带/）→ 拼出/data/www/assets/js/app.js - 用 echo 快速模拟：
echo "/data/www/assets" + "js/app.js"看是否粘连；补斜杠再试
检查 SELinux 或 AppArmor 是否拦截
即使传统权限全开，SELinux（CentOS/RHEL）或 AppArmor（Ubuntu/Debian）也可能在内核层拒绝访问，不报错、不写日志，只返回 403。
- 临时关闭 SELinux 测试：
sudo setenforce 0，若 403 消失，说明是它在拦截 - 恢复后打标签：
sudo semanage fcontext -a -t httpd_sys_content_t "/data/www/assets(/.*)?"，再restorecon -Rv /data/www/assets - AppArmor 可查日志：
sudo dmesg | grep -i avc，看是否有 denied 记录
排除 location 内部访问控制干扰
Nginx 的 allow/deny 或 satisfy 规则可能覆盖默认行为，尤其在内部系统中容易误配。
- 确认 location 块里没写
deny all;或未明确放行 - 简单测试可临时加：
allow all;和satisfy any;（注意顺序，satisfy需配合allow/deny） - 若用了认证模块（如 auth_basic），未通过也会返回 403，需单独验证
