selinux极可能在静默拦截，需先运行getenforce确认是否为enforcing模式；若是，执行sudo setenforce 0临时验证，再通过ausearch筛选nginx相关avc拒绝日志定位具体策略限制，推荐用semanage fcontext+restorecon赋予正确上下文，或修改/etc/selinux/config并重启禁用selinux。
看到 Nginx 错误日志里出现 (13: Permission denied)，而文件权限、用户归属都检查无误，那 SELinux 很可能正在静默拦截访问。它不报错，只拒绝——所以必须主动查它的“证词”。
确认 SELinux 是否处于强制模式
先看它有没有在起作用：
- 运行
getenforce，输出 Enforcing 就说明策略正在生效 - 或执行
sestatus，重点看 Current mode: 是否为 enforcing - 如果显示 disabled 或 permissive，那问题与 SELinux 无关，可跳过后续步骤
从审计日志里找被拒记录
SELinux 的拒绝行为会记在系统审计日志中，不是 Nginx 自己的日志：
- 用
sudo ausearch -m avc -ts recent | grep nginx查最近的拒绝事件 - 若想聚焦路径相关操作，可加关键词：
sudo ausearch -m avc -ts recent | grep -i 'read\|write\|index\|html' - 若
auditd没运行，试试dmesg | grep -i avc，也能看到内核级的拒绝提示
看上下文是否匹配
关键线索藏在 scontext（进程上下文）和 tcontext（目标文件上下文）里：
- Nginx 进程默认是
httpd_t域，只能安全读写特定类型的目标，比如网页内容应为httpd_sys_content_t，日志应为httpd_log_t - 运行
ls -Z /path/to/your/root，比如ls -Z /var/www/html - 如果返回的是
default_t、home_root_t或var_log_t等非标准 Web 类型，就是上下文不匹配的铁证
修复上下文并验证
别关 SELinux，给路径打上正确标签才是稳妥做法：
- 对网站根目录（如
/data/www）批量设置类型：sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?" - 立即应用变更：
sudo restorecon -Rv /data/www - 再运行
ls -Z /data/www确认已变成httpd_sys_content_t - 重启 Nginx：
sudo systemctl restart nginx，然后刷新页面测试
