关键是umask 0002、sgid目录和组继承协同控制Nginx缓存权限，而非chmod 777；需配置systemd UMask=0002、缓存目录chown root:webgroup并chmod g+s，再验证实际生成文件权限是否为664/775。
关键不是给目录“加权限”，而是让 Nginx 进程能进得去、写得进、留得住——靠 umask + 组继承 + sgid 目录 三者协同，而不是 chmod 777 或 chown root。
设 systemd 的 UMask=0002（必须）
现代 Linux（CentOS 7+/Ubuntu 16.04+）用 systemd 管理 Nginx，不显式配置 umask 就会继承系统默认的 0022，导致缓存文件是 644、目录是 755，后端或同组进程读不了。
- 运行 sudo systemctl edit nginx 创建覆盖片段
- 在
[Service]段下添加：UMask=0002（注意是四位八进制） - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart nginx
效果：新建文件默认 664（rw-rw-r--），新建目录默认 775（rwxrwxr-x）——所有者和同组用户都可读写，其他人只读。
确保缓存根目录启用 sgid 并属正确组
光有 umask 不行。如果缓存目录本身不属于 Nginx 进程所在组，或没开 sgid，子目录不会自动继承组名，权限就断了。
- 确认 Nginx 运行用户组（如
nginx或www-data），建议统一用专用共享组（如webgroup） - 设置缓存根目录归属与 sgid：
sudo chown root:webgroup /var/cache/nginxsudo chmod g+s /var/cache/nginx - 这样 Nginx 新建的
proxy_temp、fastcgi_temp等子目录，自动属组webgroup，配合 umask 0002，天然获得 775 权限
验证真实生成的缓存文件权限
别信配置写了没，要看 Nginx 实际创建的文件是否符合预期：
- 清空测试缓存：
sudo rm -rf /var/cache/nginx/proxy/* - 触发一次代理请求（比如访问一个
proxy_pass到后端的接口） - 立即检查：
ls -l /var/cache/nginx/proxy/ | tail -n 3 - 应看到类似：
-rw-rw-r-- 1 nginx webgroup ... 0000000001
——第二列含rw-，属组名和后端（如 PHP-FPM）所在组一致
排查常见静默失败点
没报错但缓存不写？很可能是这些“看不见”的限制在起作用：
-
SELinux：RHEL/CentOS 默认开启，运行
sudo sestatus -v查状态；临时放开：sudo setsebool -P httpd_write_content 1；长期方案：sudo semanage fcontext -a -t httpd_cache_t "/var/cache/nginx(/.*)?" && sudo restorecon -Rv /var/cache/nginx -
逐级目录 x 权限缺失：从
/开始，/var、/var/cache、/var/cache/nginx每一级都必须对 Nginx 用户有执行（x）权限，否则连目录都进不去 -
open_basedir（PHP 场景）：若后端是 PHP，检查 php.ini 中是否限制了缓存路径，例如没包含
/var/cache/nginx就会导致读取失败
