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 自己的日志：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• 用 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，然后刷新页面测试