403错误主因是Web服务进程无目录读取权限：确认Nginx/Apache以www用户运行，根目录属主设为www:www且权限755（不递归），.user.ini须644且属www，上层路径每级均需x权限。
宝塔面板网站 403 错误：确认 Nginx/Apache 是否以 www 用户身份运行
403 不是文件权限没设对，而是 Web 服务进程压根没权限读取目录或执行索引文件。宝塔默认用 www 用户跑 Nginx 或 Apache，如果站点根目录所有者不是 www，哪怕权限是 755，照样 403。
验证方式：执行 ps aux | grep nginx（或 ps aux | grep httpd），看主进程的 USER 列是不是 www；再查配置文件：/www/server/nginx/conf/nginx.conf 中的 user 指令是否为 www www（Apache 同理查 /www/server/apache/conf/httpd.conf 的 User 和 Group）。
- 若实际运行用户不是
www，统一改回www www并重启服务 - 别用
root启动 Web 服务——宝塔禁止且极不安全 - 某些手动编译或迁移旧环境可能残留自定义用户，必须核对
修复目录所有者与权限：只改根目录，别递归暴力 chmod -R
很多人习惯 chmod -R 755 /www/wwwroot/your-site，这反而会把 .user.ini、.htaccess 等隐藏文件也设成可执行，触发宝塔防篡改机制或 PHP 安全限制，导致更隐蔽的 403。
正确做法是分层处理：
- 站点根目录（如
/www/wwwroot/example.com）执行：chown -R www:www /www/wwwroot/example.com - 仅对该目录设权限：
chmod 755 /www/wwwroot/example.com（注意：不加-R） - 子目录中需写入的（如
uploads、runtime、cache）单独设chmod 755或775，并确保属组为www -
index.php等脚本文件无需执行权限，644 即可；Nginx 只需要读+执行目录，不需要文件可执行
检查 .user.ini 是否被宝塔自动锁定
宝塔开启“防跨站攻击”后，会在每个站点根目录生成 .user.ini，内容类似 open_basedir=/www/wwwroot/example.com:/tmp/:/proc/。如果该文件属主不是 www，或权限不是 644，Nginx 会拒绝加载，直接返回 403，且错误日志里往往只写 “directory index of … is forbidden”，不提 .user.ini。
- 执行
ls -l /www/wwwroot/example.com/.user.ini，确认 owner/group 是www www，权限是-rw-r--r--（即 644） - 若被误设为
root所有或600，运行：chown www:www /www/wwwroot/example.com/.user.ini && chmod 644 /www/wwwroot/example.com/.user.ini - 修改后需重载 Nginx：
bt reload或/etc/init.d/nginx reload
查看真实错误日志定位根本原因
面板上看到的 403 往往是表象。真正原因藏在 Nginx 错误日志里，路径通常是：/www/wwwlogs/example.com.error.log。常见有效线索包括：
-
Directory index forbidden by rule→ 目录无索引文件且未开启autoindex（正常，不是问题） -
Permission denied→ 真实权限问题，重点查上层路径（如/www、/www/wwwroot）是否对www用户可执行（x权限） -
open() "/www/wwwroot/example.com/.user.ini" failed (13: Permission denied)→ 上面提到的.user.ini权限问题 -
connect() to unix:/tmp/php-cgi-xxx.sock failed→ 这是 502，但常被误判为 403，需另查 PHP-FPM 状态
上层目录（尤其是 /www 和 /www/wwwroot）缺少执行权限是最容易被忽略的一环——www 用户必须对完整路径每级都有 x 权限才能进入子目录，光根目录 755 不够。
