Nginx 403错误本质是系统级访问控制拒绝，需依次排查：Nginx进程用户与文件属主/权限匹配、所有父目录具备执行（x）权限、SELinux/AppArmor策略限制、配置中root路径真实存在且拼写正确。
出现 Nginx 403 Forbidden 错误，核心原因不是配置写错了，而是请求的文件或目录在操作系统层面无法被 Nginx 工作进程读取——权限、路径、上下文三者任一不满足，就会触发拒绝访问。
确认 Nginx 进程运行用户与文件属主是否匹配
Nginx 默认以 www-data（Debian/Ubuntu）或 nginx（CentOS/RHEL）用户身份运行。若网站文件属主是 root 或普通用户（如 deploy），且未开放组/其他用户读取权限，Nginx 就无法打开文件。
- 查 Nginx 用户：
ps -aux | grep nginx | grep -v grep，看 WORKER 进程的 USER 列 - 查文件属主和权限：
ls -l /var/www/html/index.html，关注第一列（权限）、第三列（属主）、第四列（属组） - 安全做法：将文件属组设为 Nginx 用户所在组（如
chgrp www-data /var/www/html），并赋予组读/执行权限（目录需 +x）
检查目录执行权限（最容易忽略的关键点）
Linux 中，要进入一个目录并读取其下文件，用户不仅需要目录的 r（读）权限，还必须有 x（执行）权限。缺少 x，即使文件本身可读，Nginx 也会返回 403。
- 验证：
namei -l /var/www/html/index.html会逐级显示路径中每级目录的权限和属主 - 常见问题路径：
/var、/var/www、/var/www/html中任意一级缺少 x 权限（尤其当这些目录由 root 创建且未改权限时） - 修复示例：
chmod 755 /var/www /var/www/html（确保所有父目录都有 r-x 给 group/other）
排查 SELinux 或 AppArmor 强制访问控制（仅限启用场景）
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使传统权限正确，安全模块仍可能拦截 Nginx 的文件访问。
- SELinux 检查：
sestatus确认状态；ausearch -m avc -ts recent | grep nginx查拦截日志 - 临时放行测试：
setsebool -P httpd_read_user_content 1或chcon -R -t httpd_sys_content_t /var/www/html - AppArmor 检查：
aa-status | grep nginx；日志通常在/var/log/audit/audit.log或/var/log/syslog
验证 Nginx 配置中的 root 路径是否真实存在且拼写准确
看似是权限问题，实则是路径错误：Nginx 配置里写的 root /data/web;，但实际目录是 /data/webapp，或末尾多了一个斜杠导致路径解析异常。
- 用绝对路径测试：
sudo -u www-data ls -l /your/configured/root/path/index.html，模拟 Nginx 用户视角 - 注意 alias 和 root 指令差异：alias 会替换 location 匹配部分，root 是拼接路径，混淆易导致 404/403
- 检查符号链接目标权限：若 root 指向软链，需确保链接本身有 r-x，且目标路径也满足权限和 SELinux 上下文
403 错误本质是系统级访问控制的反馈，不是 Nginx 主动拒绝，而是内核或安全模块说“不”。从进程用户、目录执行权、安全模块、路径真实性四个维度逐层验证，比反复 reload 配置更有效。
