核心不是“没权限”，而是Nginx工作进程（如nginx或www-data）对缓存目录缺少可进入（x）+可写入（w）权限；需确认真实运行用户、逐级检查路径x权限、精准chown/chmod，并排查SELinux、open_basedir等静默拦截。
核心不是“没权限”，而是 Nginx 工作进程（非 root）对缓存目录缺少 可进入（x）+ 可写入（w） 的组合权限。这类问题常静默发生：不报错、不写日志、缓存不生效、proxy_temp 写失败、runtime 目录空转，甚至 Swoole 启动卡在生成缓存阶段。
确认真正干活的用户是谁
别只信 nginx.conf 里的 user 行——它可能被注释、被覆盖、或根本没生效：
- 查运行中的 worker 进程：
ps -eo pid,user,comm,args | grep nginx | grep -v master，看 USER 列（如nginx或www-data） - PHP 环境中，在 Web 请求里执行：
<?php echo posix_getpwuid(posix_geteuid())['name']; ?> - 若用 Hyperf/Swoole，运行：
ps aux | grep swoole，确认实际 UID/GID
检查缓存路径的逐级权限
从根到最深子目录，每层都必须满足“可进入（x）”；最终目标目录还需“可写入（w）”：
- 执行：
ls -ld /var/cache/nginx /var/cache/nginx/proxy_temp /var/cache/nginx/proxy_temp/0/01，观察每级的属主、属组和权限位 - 关键点：目录权限中必须含
x（比如drwxr-xr-x可以，drw-r--r--不行——连进去都做不到） - 常见陷阱：目录属主是
root，权限750，而 Nginx 用户既不是 owner 也不在 group 中 → 完全拒绝
精准修复归属与权限（不碰 777）
按最小权限原则操作，避免扩大攻击面：
- 改属主属组（以
nginx用户为例）：sudo chown -R nginx:nginx /var/cache/nginx/proxy_temp - 设权限（
X大写只给目录加 x，不影响文件）：sudo chmod -R u+rwX,g+rwX,o-rwx /var/cache/nginx/proxy_temp - 若缓存路径在用户家目录（如
/home/deploy/app/runtime），必须连同父级一起授权：chown deploy:deploy /home/deploy+chmod 755 /home/deploy，否则进不去
提防静默拦截机制
有些限制不会抛 Permission denied，但效果一样：
-
SELinux（CentOS/RHEL/Alpine）：运行
sudo sestatus -v，若为 enforcing，临时放开：sudo setsebool -P httpd_write_content 1（Nginx 也适用）；长期方案：给目录打上下文标签：sudo semanage fcontext -a -t httpd_cache_t "/var/cache/nginx(/.*)?"，再restorecon -Rv /var/cache/nginx -
open_basedir（PHP 场景）：检查
php.ini或站点配置中是否限制了缓存路径，例如open_basedir = /var/www/app:/tmp却没包含/var/cache/nginx→ 加上 -
Kubernetes 环境：initContainer 必须预创建并授权
/var/cache/nginx，且 Pod 的securityContext.runAsUser应设为 101（nginx 默认 UID）
