nginx 403 错误本质是 worker 进程无法遍历路径、读取文件或匹配索引，需逐级检查目录执行权限（x）、selinux/apparmor 拦截、root/alias 拼接逻辑及 index 文件大小写与存在性。
不是权限没设对，而是 Nginx worker 进程卡在“进不去”或“打不开”的某个环节——即使 chmod 755 看似正确，403 仍可能由路径遍历限制、SELinux 拦截、index 文件缺失或 root 指令拼接逻辑误判导致。
目录每一级都得有执行（x）权限
Nginx 不是只读目标文件，它要从根目录开始逐层进入：比如 root /var/www/webui;，那么 /、/var、/var/www、/var/www/webui 这四级目录，每级都必须对 worker 用户开放执行（x）权限，否则进程无法遍历到最终路径，直接返回 403。
-
ls -ld / /var /var/www /var/www/webui查各级权限，确认都有r-x（至少其他用户可执行） - 常见陷阱：
/root目录默认权限是dr-x------，nobody 或 nginx 用户根本进不去，哪怕子目录 chmod 755 也无效 - 推荐存放位置：
/var/www、/usr/share/nginx/html、/opt/webui—— 这些路径天然对服务用户友好
SELinux 或 AppArmor 在静默拦截
尤其在 CentOS/RHEL 或启用了安全模块的 Ubuntu 上，传统文件权限全对，照样 403。因为内核级策略额外限制了 Nginx 访问文件的能力。
- 运行
getenforce，若返回Enforcing，说明 SELinux 开启中 - 临时验证：
setenforce 0后刷新页面，403 消失即确认是它 - 生产环境修复：
semanage fcontext -a -t httpd_sys_content_t "/var/www/webui(/.*)?"，再restorecon -Rv /var/www/webui - Ubuntu 用户检查 AppArmor：
aa-status | grep nginx，必要时调整/etc/apparmor.d/usr.sbin.nginx
root 指令的路径拼接逻辑被误解
root 不是“把请求路径直接贴过去”，而是做字符串拼接。例如：
-
root /var/www;+location /static/css/→ 实际查找/var/www/static/css/ - 若你把 CSS 放在
/var/www/css/，但配置了location /static/，Nginx 就会去找/var/www/static/，该路径不存在 → 403 - 注意末尾斜杠：
location /api/和location /api行为不同；前者要求路径以/api/开头且含尾部斜杠，后者更宽松 - 别混淆
root和alias：alias会完全替换 location 路径，root是追加
index 文件不存在或命名不匹配
访问 / 时，Nginx 默认不会列目录，它只尝试找 index 指令里列出的文件。只要一个都找不到，就直接 403。
- 检查配置中
index index.html index.htm;对应的文件是否真实存在 - Linux 区分大小写：目录下是
Index.html或index.HTML，Nginx 就找不到 - 用
ls -l /var/www/webui/确认文件名完全一致 - 如果真不需要 index，又想允许目录浏览，需显式开启：
autoindex on;（仅调试用，生产慎开）
