worker_rlimit_nofile本身不缓存描述符，而是限制单个worker进程可打开的文件描述符总数，包括缓存文件读写；其生效需同步调优系统limits.conf、systemd limitnofile及内核fs.file-max，并确保nginx用户对缓存目录具备rwx权限。
Nginx 本身不直接“缓存描述符”（file descriptor），但常被误解的其实是它对文件描述符资源的使用方式——尤其是与缓存（如 proxy_cache、fastcgi_cache）相关的后端文件读取行为，以及这些操作如何受操作系统级文件系统权限约束。关键点在于：Nginx 进程能否打开缓存文件、读取元数据、写入新缓存项，完全取决于其工作进程（通常是 www-data 或 nginx 用户）对缓存目录及其中文件的 文件系统权限，而非某个独立的“缓存描述符设置”。
缓存文件访问依赖进程用户权限
Nginx 缓存内容最终以普通文件形式落盘（例如 /var/cache/nginx/proxy/ 下的哈希子目录结构）。当 worker 进程需要读取已有缓存或写入新缓存时，会调用 open()、read()、write() 等系统调用——这都需要对应用户对目标路径具备：
-
执行（x）权限：对缓存根目录及其所有父目录（逐级）必须有
x，否则无法进入目录遍历路径 - 读（r）权限：读取缓存文件内容或 stat 元数据（如过期时间）时必需
- 写（w）权限：创建新缓存文件、更新缓存头、清理过期项时必需
若权限不足，Nginx 日志中会出现类似 open() "/var/cache/nginx/proxy/xxx" failed (13: Permission denied) 的错误，且缓存将退化为每次回源，失去加速效果。
worker_rlimit_nofile 影响并发缓存文件操作能力
虽然不叫“缓存描述符设置”，但 worker_rlimit_nofile 直接限制单个 worker 进程能同时打开的文件描述符总数——包括监听套接字、客户端连接、日志文件，也包括正在读写的缓存文件。当高并发命中缓存时，大量缓存文件被同时打开（尤其启用 proxy_cache_use_stale 或频繁验证时），可能快速耗尽描述符限额。
- 默认值通常偏低（如 1024），在缓存密集型场景下易触发
Too many open files - 需同步调整系统级限制：
/etc/security/limits.conf中为 nginx 用户设置nofile，并确保 systemd service 中未覆盖（检查LimitNOFILE） - 建议值参考：峰值并发 ×（平均每个请求涉及的缓存文件数 + 基础连接开销），通常设为 65536 或更高
缓存路径所有权必须匹配 worker 进程用户
即使权限位正确（如 drwxr-xr-x），若缓存目录归属用户/组与 Nginx worker 不一致，仍会失败。常见错误：
- 手动
mkdir /var/cache/nginx后未chown nginx:nginx，导致 root 创建的目录 owner 是 root - 使用包管理器安装后首次启动前未初始化缓存目录（部分发行版需运行
nginx -t && nginx -s reload或手动创建） - SELinux/AppArmor 启用时，额外需要策略允许 nginx_t 域访问 cache_file_t 类型路径
验证方法：ps -o user,group -p $(cat /var/run/nginx.pid) 查看 worker 实际运行用户，再 ls -ld /var/cache/nginx 核对归属与权限位。
proxy_cache_path 的 use_temp_path 与权限安全边界
proxy_cache_path 指令中的 use_temp_path=on|off 控制缓存写入流程：
-
on（默认）：先写临时文件（如/var/cache/nginx/tmp/xxx.tmp），再原子 rename 到目标缓存路径。此时tmp子目录也需同用户、同权限可写 -
off：直接写入最终路径，减少一次磁盘 IO，但要求目标路径所在文件系统支持原子创建（ext4/xfs 满足），且 worker 必须对缓存目录有写+执行权限
若临时路径权限错误，会导致 open() "/var/cache/nginx/tmp/..." failed (13: Permission denied)，表现为缓存写入失败但读取正常（旧缓存仍可用）。
