缓存目录空间突增通常由配置异常或文件句柄未释放导致，需通过du -sh和find命令精准统计真实占用及文件数量，避免误判df -h整体分区使用率。

缓存目录空间突增不是偶然现象，背后通常有明确诱因。排查要从“系统表现—配置逻辑—异常信号”三层切入，重点盯住磁盘行为是否符合预期。

看真实占用，别信挂载点整体使用率

df -h 显示 /var/cache/nginx 所在分区用了 85%，但实际缓存可能只占 2GB——其余是日志、临时文件或已删除但句柄未释放的文件。必须直接统计缓存路径本身：

• du -sh /var/cache/nginx：获取当前缓存真实体积（注意路径需与 proxy_cache_path 一致）
• find /var/cache/nginx -type f | wc -l：检查文件总数，若超百万且平均体积很小（
• ls -lt /var/cache/nginx/*/*/* | head -10：观察最近修改时间。如果设了 inactive=1h，但列表里全是 3 小时前的文件，说明清理没触发——大概率 keys_zone 内存不足或 max_size 远未触及

查配置是否自相矛盾

很多突增源于参数组合失当，让 Nginx “想清却清不动”或“不该存却一直存”：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• keys_zone 太小：比如设为 my_cache:10m，但每天缓存 50 万 key，内存区很快溢出，Nginx 就无法准确记录访问时间，inactive 彻底失效
• proxy_temp_path 和 proxy_cache_path 不在同一文件系统：临时文件写入失败后，Nginx 可能反复重试或降级写入缓存目录，导致 .temp 文件混入并长期滞留
• proxy_cache_valid 范围太宽：如对所有 2xx 状态统一设 7d，但实际业务中大量接口返回的是动态 JSON（含时间戳），缓存后反而造成内容陈旧+空间浪费

抓进程和句柄，确认是否有“看不见”的文件

用 du 看到的大小远小于 df 显示的已用空间？大概率存在已被 rm 删除但仍在被 nginx worker 持有的文件：

• lsof + grep deleted：运行 lsof -nP | grep '/var/cache/nginx.*deleted'，列出所有已删但未释放的缓存文件
• 检查 nginx 日志：搜索 open() .* failed (24: Too many open files) 或 writev() failed (28: No space left on device)，这类报错常伴随句柄泄漏或磁盘满假象
• 对比重启前后：平滑 reload 不会释放已打开的 deleted 文件，只有完整 stop + start 才能清空。若重启后 du 立即回落，就坐实了句柄未释放问题

验证 cache manager 是否正常工作

Nginx 没有“清理频率”配置项，但它的 cache manager 是每秒唤醒一次的守护进程。可通过间接方式判断它是否在线：

• 持续运行 watch -n 1 'du -sh /var/cache/nginx'，同时用 ab 或 wrk 对缓存路径发起高频请求（如 100 QPS），观察体积是否缓慢下降——下降说明 manager 在扫描并清理；完全不动说明它被阻塞或失效
• 检查 error_log 级别是否为 warn 或 info，低级别日志可能隐藏 cache manager started 或 cache loader started 的启动信息
• 若启用了多个 keys_zone，确认没有同名冲突——重复定义会导致 manager 初始化失败，整个缓存区进入“只写不删”状态