proxy_store_access的核心作用是设定Nginx使用proxy_store缓存静态资源时生成文件的系统级权限，控制用户、组及其他人在操作系统层面的读写权限，不涉及HTTP层访问控制。

proxy_store_access 的核心作用是设定 Nginx 在使用 proxy_store 缓存静态资源（如图片、JS、CSS）到本地磁盘时，生成文件的系统级文件权限。它不控制 HTTP 层访问（比如谁能看到 URL），而是决定这些缓存文件在操作系统层面能否被读取或修改——这对多用户环境、共享服务器或安全合规场景尤为关键。

理解 proxy_store_access 的权限语法

该指令格式为：proxy_store_access : [:] [:];

其中：

• user 指运行 Nginx worker 进程的系统用户（如 nginx、www-data）
• group 指该用户的主组或指定组
• all 指其他所有用户（即 Linux 中的 “others”）
• perms 仅支持 r（读）、w（写），不支持执行（x）——因为缓存文件无需执行权限

例如：proxy_store_access user:rw group:r all:r; 表示：Nginx 自身可读写，同组用户只读，其他用户也只读。

Web Accessibility (WCAG 2 AA))

将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。

下载

避免常见权限风险的配置建议

直接设为 all:rw 是高危操作，可能让任意本地账户篡改或删除缓存文件。应按最小权限原则配置：

• 生产环境强烈推荐：proxy_store_access user:rw group:r all:r; —— 确保只有 Nginx 进程能写，其他用户（包括 web shell）只能读
• 若服务器有多个可信服务共用同一组（如监控脚本需统计缓存命中率），可用：proxy_store_access user:rw group:rw all:r;，并确保该组无非授权成员
• 绝对不要用 all:rw 或 all:w，否则攻击者一旦获得低权限 shell，就可覆盖缓存内容实施投毒
• 配合 chown -R nginx:nginx /path/to/cache 和 chmod 755 /path/to/cache 目录权限，形成双重防护

与 proxy_temp_path 和 root 路径协同校验

proxy_store_access 生效的前提是路径真实存在且 Nginx 有写入权。务必确认三者一致：

• root /var/www/mirror; —— 定义请求 URI 映射到的根目录（也是 $request_filename 的解析基准）
• proxy_temp_path /var/www/mirror; —— 必须与 root 路径相同（或其子目录），否则缓存文件可能写入错误位置
• proxy_store on; + if (!-e $request_filename) { proxy_pass ... } —— 触发缓存逻辑

若出现 open() "/var/www/mirror/xxx.jpg" failed (13: Permission denied) 错误，优先检查：
① 目录属主是否为 nginx 用户；
② 目录是否具备执行（x）权限（Linux 目录需 x 才能 cd 和访问内部文件）；
③ proxy_store_access 是否允许 user:w。

进阶：结合系统机制强化隔离

单靠 proxy_store_access 不足以应对高级威胁，建议组合以下措施：

• 将缓存目录挂载为 noexec,nosuid,nodev 的独立分区（如 /var/cache/nginx-mirror），从内核层禁用非法执行
• 使用 SELinux 或 AppArmor 限制 Nginx 进程只能写入指定路径，即使权限配置失误也不越界
• 定期审计缓存目录：find /var/www/mirror -type f ! -user nginx -ls，及时发现异常属主文件
• 对敏感资源（如用户头像、PDF 报告），不依赖 proxy_store，改用后端动态鉴权 + X-Accel-Redirect 返回本地文件，完全绕过公开可写的缓存路径