关键不是配置清理频率，而是通过系统监控+合理调优inactive、max_size、keys_zone三项参数实现可观测、可预期、可干预的缓存空间管理。
监控 Nginx 缓存目录的磁盘占用率和理解其文件清理频率，关键不是“配置清理频率”（因为 Nginx 不提供可调的清理节奏参数），而是通过系统级监控 + 合理配置缓存策略，实现对空间使用和自动回收行为的可观测、可预期、可干预。
监控磁盘占用率：用系统工具+定时检查
Nginx 本身不暴露缓存目录实时占用指标，需依赖操作系统命令与轻量脚本：
- 用 df -h /var/cache/nginx（路径按实际
proxy_cache_path调整）查看整个挂载点使用率；更精准可用 du -sh /var/cache/nginx 统计缓存目录实际大小 - 写一个简单 shell 脚本（如
/usr/local/bin/nginx-cache-disk.sh），定期执行并输出到日志或推送到监控平台：
#!/bin/bash
CACHE_DIR="/var/cache/nginx"
USED=$(du -sb "$CACHE_DIR" 2>/dev/null | awk '{print $1}')
TOTAL=$(df -B1 "$CACHE_DIR" 2>/dev/null | tail -1 | awk '{print $2}')
if [ "$TOTAL" -gt 0 ]; then
PERCENT=$((USED * 100 / TOTAL))
echo "$(date): ${PERCENT}% used ($USED/$TOTAL bytes)" >> /var/log/nginx/cache_usage.log
fi - 配合 cron 每 5 分钟运行一次（
*/5 * * * * /usr/local/bin/nginx-cache-disk.sh），再用 Prometheus + node_exporter 或 Zabbix 抓取日志/文件大小，就能绘出趋势图并设告警阈值（如 >85% 触发）
理解“清理频率”：它其实不可配，但可推断
Nginx 的 cache manager 每秒唤醒一次，每次最多扫描 100 个缓存子目录（非文件数），且只清理满足 inactive 条件、未被占用的条目。这个行为是硬编码的，没有 manager_files、manager_sleep 等配置项——任何试图在 nginx.conf 里写这类参数都会报错。
- 所谓“清理快慢”，实际取决于三个可配因素：inactive 时长（决定哪些文件可删）、max_size 是否逼近上限（触发主动空间回收）、keys_zone 内存是否充足（确保能准确记录最后访问时间）
- 例如：设
inactive=1h且max_size=5g，当缓存已占 4.9GB 时，cache manager 会在每次扫描中优先清理最久未访问的文件，直到低于阈值；而若仅占 1GB 且所有文件都不到 1 小时，则几乎不清理 - 可通过
ls -lt /var/cache/nginx/*/*/* | head -20查看最近修改的缓存文件时间戳，辅助判断清理是否按预期发生
让清理行为更可控：调优三项核心配置
与其盯着“频率”，不如聚焦如何让清理更及时、更稳定、不误伤：
- 设合理的 inactive 值：静态资源（JS/CSS/图片）建议 2h～6h，API 响应类设 30m～2h，归档文档类可放宽至 7d。避免设为 1m 或 5m，否则新缓存刚写入就可能被扫掉
-
配足 keys_zone 内存：每约 8000 个缓存键需 1MB 共享内存。若缓存 50 万个文件，建议
keys_zone=my_cache:64m，防止 key 被挤出导致 inactive 计时失效 -
启用 use_temp_path=off：强制临时文件也写入缓存目录，避免跨文件系统问题，同时让
max_size对所有缓存数据生效，空间控制更准确
补充：验证清理是否生效的实操方法
光看配置不够，要确认行为符合预期：
- 在 location 中加
add_header X-Cache-Status $upstream_cache_status;，用 curl 查看响应头，确认 HIT/MISS/EXPIRED 状态是否合理 - 手动触发几次请求后等待超过
inactive时间，再执行find /var/cache/nginx -type f -mmin +61 | wc -l（假设 inactive=60m），观察数量是否明显下降 - 查 Nginx error 日志：
grep "cache manager" /var/log/nginx/error.log，正常会看到类似cache manager started或周期性扫描记录
