403 forbidden 根本原因是权限问题，需同步检查文件系统权限（目录x、文件r、用户组匹配）、web服务器访问策略（apache的require或nginx的root/alias配置）及selinux/apparmor等内核级控制。
403 forbidden 是权限问题，不是网络或代码错误
看到 403 forbidden，第一反应不该是查 nginx 日志或重写规则，而是立刻确认：web 服务器进程（如 www-data、nginx 或 apache）有没有读取目标目录和文件的权限？能不能执行目录（即是否有 x 权限）？
常见错误现象包括：首页能打开，但子目录报 403；静态资源（CSS/JS）返回 403；用 curl -I 能看到 HTTP/1.1 403 Forbidden 但无其他提示。
- Linux 下目录必须有
x权限才能被进入（即使只是列文件），chmod 755是安全起点，750或700往往导致 403 - 文件至少需要
r权限（如644），否则 Web 服务器无法读取内容 - 用户组别要对得上：确保运行 Web 服务的用户（如
www-data）在文件所属组里，或直接属主就是它 -
ls -ld /var/www/example.com和ls -l /var/www/example.com/index.html必须逐级检查
Apache 的 Require 指令常被忽略
Apache 2.4+ 默认启用基于 Require 的访问控制，Allow from all 这类旧语法已失效。如果配置里没显式放行，即使文件权限全对，照样 403。
使用场景：虚拟主机配置、.htaccess、或 <directory></directory> 块内。
- 目录允许访问的最小有效配置是：
Require all granted - 若用了
Require local，外部请求必然 403 -
.htaccess生效需对应目录的AllowOverride All，否则Require不解析 - 注意作用域嵌套：外层
<directory></directory>拒绝了，内层<directory></directory>即使放行也无效
Nginx 的 root 和 alias 配置错位引发 403
Nginx 不检查目录是否“可列”，但它严格校验路径拼接后的真实文件是否存在、且可访问。用错 root 或 alias 会导致最终路径指向不存在或权限不足的位置，直接返回 403。
参数差异关键点：
-
root /var/www;+location /static/ { }→ 实际找/var/www/static/ -
alias /var/www/static/;+location /static/ { }→ 实际找/var/www/static/（注意末尾斜杠） - 漏掉
alias末尾斜杠（如写成alias /var/www/static）会拼出错误路径，常表现为 403 而非 404 - 确保
user指令指定的用户（如user www-data;）对root或alias所指路径有读+执行权限
SELinux 或 AppArmor 启用时的隐藏拦截
CentOS/RHEL 默认开启 SELinux，Ubuntu/Debian 可能启用 AppArmor —— 它们会在内核层拦截 Web 服务对文件的访问，即便传统 Linux 权限全开，也会静默返回 403。
判断方法：查 dmesg 或审计日志，看是否有 AVC denied 记录。
- SELinux 下临时放行：
setsebool -P httpd_read_user_content 1（针对用户目录）或chcon -R -t httpd_sys_content_t /var/www/example.com - AppArmor 下检查：
aa-status，再查对应 profile 是否限制了/var/www/** r, - 不建议直接
setenforce 0测试，容易掩盖真实权限问题；应先ausearch -m avc -ts recent确认是否为 SELinux 拦截
真正麻烦的从来不是改哪一行配置，而是你得同时盯着三处：文件系统权限、Web 服务器访问策略、内核级强制访问控制。少看一眼，403 就卡在那儿不动。
