nginx 403错误中“13: permission denied”表明是selinux或apparmor等内核级安全模块拦截，而非普通权限问题；需通过sestatus/aa-status、ausearch/dmesg查拦截日志，临时切换模式验证，并用semanage/restorecon或apparmor策略修复上下文。
当 Nginx 返回 403 Forbidden，但文件权限、路径配置、用户属主都检查无误时，很可能是系统级安全策略在拦截——不是 Nginx 拒绝你，而是内核或安全模块“替你拦下了”。这类拦截隐蔽性强，日志里往往只写 Permission denied，不提 SELinux 或 AppArmor，容易绕进死胡同。
看错误日志里有没有“13: Permission denied”
打开 Nginx 错误日志：sudo tail -n 30 /var/log/nginx/error.log
重点找类似这样的行：open() "/var/www/html/index.html" failed (13: Permission denied)
数字 13 是关键线索：它对应 Linux 系统调用错误码 EACCES，表示访问被拒绝——这通常不是普通权限问题（那种会报 20 或 2），而是安全模块干预的典型信号。
确认 SELinux 是否启用并拦截
适用于 CentOS/RHEL/AlmaLinux 等发行版：
- 查状态：sestatus（若输出 enabled 且 enforcing，就需深入）
- 查拦截记录：sudo ausearch -m avc -ts recent | grep nginx
如果返回结果含 avc: denied 和 httpd_t、var_t 等上下文字段，说明 SELinux 明确阻止了访问。
临时验证（仅测试用）：sudo setenforce 0（切换为 permissive 模式）
再刷新网页，403 消失 → 基本锁定是 SELinux 导致。
恢复防护：sudo setenforce 1
检查 AppArmor 是否限制 Nginx
适用于 Ubuntu/Debian 默认安装场景：
- 查是否加载策略：aa-status | grep nginx
- 若有输出（如 /usr/sbin/nginx 在 enforce 模式下），再查日志：sudo dmesg | grep -i "apparmor.*denied" | grep nginx
或翻 /var/log/syslog 中含 apparmor="DENIED" 的条目。
临时放行测试：sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
然后 sudo systemctl reload apparmor，再试请求。
修复而非绕过：给内容打上正确安全上下文
不要长期禁用 SELinux/AppArmor。应修正策略，让合法访问被允许：
-
SELinux（推荐）：把网站目录标记为可被 Web 服务读取
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"sudo restorecon -Rv /var/www/html -
AppArmor（Ubuntu）：编辑
/etc/apparmor.d/usr.sbin.nginx，在/var/www/** r,行下方添加：/var/www/html/** r,
然后执行：sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
改完后务必用 sudo -u nginx cat /var/www/html/index.html 手动验证能否读取，这是最直接的确认方式。
