nginx报“(13: permission denied)”本质是worker进程用户在os层面被拒绝访问，需依次确认运行用户、路径r/x权限、selinux/apparmor策略、临时目录及socket文件权限。
“Permission denied”（错误码 13）在 Nginx 日志中反复出现，本质不是配置写错了，而是 Nginx 工作进程用户在操作系统层面被文件系统或安全机制明确拒绝访问——它是一场用户身份、路径权限、安全策略三方角力的结果。
确认 Nginx 实际运行用户
Nginx 启动后，master 进程常以 root 身份运行，但真正处理请求的是 worker 进程，它们按 nginx.conf 中 user 指令指定的用户降权运行（如 user nginx; 或 user www-data;）。这个用户才是权限检查的主体。
执行以下命令确认真实 worker 用户：
-
ps aux | grep "nginx: worker" | awk '{print $1}'—— 查看 worker 进程属主 -
grep "^user" /etc/nginx/nginx.conf—— 查看配置中声明的用户 -
sudo -u nginx ls -l /var/www/html/index.html—— 切换到该用户，模拟访问测试是否可行
检查路径链上的执行与读取权限
Linux 要打开一个文件，Nginx 用户必须对从根目录到目标文件的每一级父目录都有 x（执行）权限，对目标文件本身有 r（读）权限。缺一不可。
例如：访问 /data/app/static/logo.png，需确保：
-
/、/data、/data/app、/data/app/static都有 x 权限（常用755） -
logo.png有 r 权限（常用644） - 若使用
chown -R nginx:nginx /data/app，请确保不误改系统关键目录归属
排查 SELinux 或 AppArmor 的拦截
在 CentOS/RHEL（启用 SELinux）或 Ubuntu（启用 AppArmor）上，即使文件权限完全正确，安全模块仍可拦截操作：
- 查 SELinux 状态：
getenforce（返回Enforcing即生效） - 常见拦截场景：
– Nginx 代理上游服务（报connect() to ... failed (13: Permission denied)）→ 执行setsebool -P httpd_can_network_connect 1
– Nginx 读取非标准路径（如/home/user/site）→ 执行setsebool -P httpd_read_user_content 1 - AppArmor 用户可运行
aa-status查看是否限制了 nginx profile
验证临时目录与 socket 文件权限
除静态文件外，两类资源也高频触发 13 错误：
-
client_body_temp 等临时目录：用于缓存大 POST 请求体。需确保 Nginx 用户对其有
w+x权限（chmod 750+chown nginx:nginx），且不能递归修改整个 Nginx 安装目录 -
Unix socket 文件（如 .sock）：当 Nginx 代理 uWSGI/Gunicorn 时，若 socket 属主是 root，而 worker 是 nginx，就会拒绝连接。修复方式二选一：
– 改 socket 所属组并加 g+w 权限，再将 nginx 加入该组
– 或直接在应用侧启动时指定--uid nginx --gid nginx
