核心是为systemd管理的Nginx服务设UMask=0002，使缓存文件默认664、目录775，并确保Nginx与后端同属一个启用sgid的共享组（如webgroup），从而实现权限匹配与自动继承。
要在 Nginx 服务中正确配置 umask，确保它生成的缓存文件（如 proxy_temp、fastcgi_temp、scgi_temp、uwsgi_temp 目录下的临时文件或缓存内容）能被后端应用（如 PHP-FPM、Java 服务、Python WSGI 进程）正常读取，核心不是“让 Nginx 改权限”，而是让 Nginx 创建的文件/目录权限与后端进程所属用户和组匹配——关键靠 umask + 用户组协同，而非事后 chmod。
在 systemd 管理的 Nginx 服务中设 umask
现代 Linux 发行版（CentOS 7+/Ubuntu 16.04+）默认用 systemd 启动 Nginx。必须在服务单元文件中显式设置，否则继承系统默认 umask（通常是 022），导致缓存文件权限为 644 或目录为 755，后端若非 root 或同组用户就可能无权读取。
- 编辑服务文件：
/etc/systemd/system/nginx.service或运行systemctl edit nginx创建覆盖片段 - 在
[Service]段添加一行：UMask=0002（注意是四位八进制） - 为什么是 0002？
– 目录默认 777 & ~0002 = 775 →rwxrwxr-x（所有者+组可读写执行，others 只读执行）
– 文件默认 666 & ~0002 = 664 →rw-rw-r--（所有者+组可读写，others 只读）
这样后端只要和 Nginx 同属一个组（如www-data或nginx），就能直接读写缓存文件 - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart nginx
配套：确保 Nginx 与后端同组且缓存路径归属正确
仅设 umask 不够。如果 Nginx 进程用户（如 nginx）和后端用户（如 php-fpm）不在同一组，或缓存目录本身不属于该组，umask 生效也无意义。
- 创建共享组（如
webgroup）：sudo groupadd webgroup - 将 Nginx 用户加入：
sudo usermod -aG webgroup nginx - 将后端用户加入：
sudo usermod -aG webgroup www-data（PHP-FPM 默认用户）或appuser - 设置缓存根目录属组并启用 sgid：
sudo chown root:webgroup /var/cache/nginxsudo chmod g+s /var/cache/nginx
这样 Nginx 新建的子目录自动继承webgroup，配合 umask 0002，自然获得 775/664 权限
验证缓存文件权限是否真正生效
别只看配置写了没，要实测 Nginx 实际创建的文件权限：
- 清空或重命名现有缓存：
sudo rm -rf /var/cache/nginx/proxy/* - 触发一次代理请求（如访问一个被 proxy_pass 到后端的接口），让 Nginx 写入新缓存
- 立即检查最新生成的缓存文件：
ls -l /var/cache/nginx/proxy/ | tail -n 3 - 应看到类似：
-rw-rw-r-- 1 nginx webgroup 12345 Jun 20 10:22 0000000001
重点：第二组（group）权限含rw-，且属组名与后端用户所在组一致
不推荐的做法（常见误区）
这些方式无法保证缓存文件权限持续合规：
- 在
/etc/nginx/nginx.conf里写 shell 命令或调用 umask —— Nginx 配置文件不执行 shell，无效 - 只改
~/.bashrc或/etc/profile—— systemd 服务不加载交互式 shell 配置 - 依赖 logrotate 的
create指令 —— 它只管日志，不管 proxy 缓存文件 - 用 cron 每分钟 chmod 一遍 —— 治标不治本，且存在时间窗口期（刚创建未 chmod 时后端已尝试读取）
