Nginx代理临时文件写入失败的典型日志是“open() … failed (13: Permission denied)”，本质是worker进程用户缺乏路径遍历（x）和写入（w）权限，需确认运行用户、逐级检查目录x权限、修正属主属组，并排查SELinux等安全模块拦截。
遇到 Nginx 代理临时文件写入失败，最典型的日志表现是：[crit] open() "/path/to/proxy_temp/xx/xx/xxxx" failed (13: Permission denied)。这不是配置写错了，而是系统在底层拒绝了 Nginx worker 进程对磁盘路径的访问——关键在于“能不能走进去”和“能不能写进去”，而不是“能不能创建文件”。
看 error.log 锁定具体路径和错误类型
先查真实报错点，别猜：
- 运行
sudo tail -n 50 /var/log/nginx/error.log（或你自定义的 error_log 路径） - 重点找含
(13: Permission denied)的行，例如：open() "/var/cache/nginx/proxy_temp/0000000001" failed (13: Permission denied)→ 说明 proxy_temp 不可写stat() "/var/cache/nginx" failed (13: Permission denied)→ 说明 proxy_cache_path 主目录连读/进入权限都没有 - 注意区分：proxy_temp 是反向代理响应体溢出写入的位置；client_body_temp 是客户端 POST 大请求体暂存位置；两者权限问题常同时出现
确认真正干活的 Nginx 用户是谁
nginx.conf 里的 user 指令可能失效，必须看运行时：
- 执行
ps -eo pid,user,comm,args | grep nginx | grep -v master，看 USER 列（常见为nginx、www-data或ucp） - 如果用 PHP 环境，可在网页中加一行验证：
<?php echo posix_getpwuid(posix_geteuid())['name']; ?> - 若该用户是
www-data，但/var/cache/nginx属主是root，那必然失败
逐级检查路径的 x 权限（最容易被忽略）
Linux 要求从 / 开始，每一级父目录都得有执行（x）权限，Nginx 才能“走进去”：
- 以路径
/var/cache/nginx/proxy_temp为例，需依次检查：/→/var→/var/cache→/var/cache/nginx→/var/cache/nginx/proxy_temp - 用
namei -l /var/cache/nginx/proxy_temp一键查看全路径各层权限和属主 - 典型陷阱：
drw-r--r--（没 x）、drwxr-x---（others 没 x），哪怕只是/var/cache这一级没 x，整个路径就走不通
精准修复权限并排查静默拦截
最小权限原则，不碰 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），必须同步授权父级：sudo chmod 755 /home/deploy，否则进不去 - 检查 SELinux：
sudo sestatus -v，若为 enforcing，临时放开：sudo setsebool -P httpd_write_content 1；长期方案打标签：sudo semanage fcontext -a -t httpd_cache_t "/var/cache/nginx(/.*)?" && sudo restorecon -Rv /var/cache/nginx
