根本原因是apache默认拒绝一切访问，必须显式授权；需确保directory路径与documentroot完全一致、块内含require all granted、selinux上下文合规、options配置匹配实际需求，并检查allowoverride是否启用.htaccess。
Apache 使用 DocumentRoot 配置静态资源时权限正确却仍报 403，根本原因不是文件权限本身错了，而是 Apache 的访问控制机制未放行——它默认“拒绝一切”，必须显式授权才能访问。
Directory 指令没同步更新
改了 DocumentRoot "/var/www/my-site"，但没改对应 <directory></directory> 块，Apache 仍按旧路径（比如 /var/www/html）或根目录 <directory></directory> 的规则执行。而后者常含 Deny from all 或 Require all denied，直接拦截所有请求。
- 必须确保
<directory></directory>路径与DocumentRoot完全一致（字符、斜杠、大小写都不能差） - 检查该
<directory></directory>块内是否包含Require all granted（Apache 2.4+）或Allow from all（2.2 及更早） - 注意嵌套关系：外层
<directory></directory>拒绝了，内层再怎么放行也无效
AllowOverride 设置阻止 .htaccess 生效
如果依赖 .htaccess 控制访问（比如加密码、重定向），但对应 <directory></directory> 中设了 AllowOverride None，Apache 就会忽略 .htaccess 里的 Require 等指令，导致本该放行的规则不生效，最终返回 403。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 调试时可临时设为
AllowOverride All，确认是否是此问题 - 生产环境建议明确列出所需覆盖项，如
AllowOverride AuthConfig FileInfo
SELinux 或 AppArmor 强制拦截
即使 Linux 文件权限（755/644）和 Apache 配置都正确，SELinux（RHEL/CentOS/Fedora）或 AppArmor（Ubuntu/Debian）仍可能阻止 httpd 进程读取目标路径。
- 运行
sudo sestatus查看 SELinux 是否启用；若为enabled，执行sudo setsebool -P httpd_read_user_content 1允许读取用户目录 - 检查上下文：
ls -Z /var/www/my-site，确保目录标签类似httpd_sys_content_t；否则用sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/my-site(/.*)?"+sudo restorecon -Rv /var/www/my-site - AppArmor 用户可查
sudo aa-status，并确认 profile 是否允许访问该路径
Options 指令限制目录行为
Options 决定 Apache 对目录能做什么。若没启用 FollowSymLinks 却用了软链接，或没开 Indexes 又访问无索引页的空目录，也会触发 403。
- 常见安全组合：
Options FollowSymLinks（允许跟随符号链接） - 若需列目录内容（不推荐生产环境），加
Indexes；否则确保目录下有index.html等默认文件 - 避免使用
None，除非明确知道每个子功能都被单独启用
