Nginx 不存在 manager_files 配置参数，proxy_cache_path 中使用会导致启动失败；调优需聚焦三点：降低单目录文件密度（如 levels=1:2）、配足 keys_zone 内存（30 万缓存建议 32m）、合理设置 inactive（API 响应 20m/图片 4h/归档页 7d）。
nginx 并不存在 manager_files 这个配置参数，它不是官方支持的指令，所有在 proxy_cache_path 中写 manager_files=xxx 的用法都会导致 nginx 启动失败或配置被忽略。这是长期存在的常见误传，根源在于混淆了 Nginx 缓存管理器（cache manager）的内部行为与可配置项。
真正影响扫描 CPU 开销的三个可控因素
海量缓存（如数十万小文件）下 cache manager 扫描引发的 CPU 波动，本质是目录遍历 + 文件 stat + 元信息比对带来的开销。调优应聚焦以下三点：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
降低单目录文件密度：用好
levels
默认levels=1会把全部缓存塞进最多 16 个一级目录，单目录超 5 万文件时，每次扫描一个目录就要遍历海量 inode，CPU 和磁盘 seek 压力陡增。推荐levels=1:2（4096 目录）或levels=1:2:2（超百万目录），让单目录平均保持在 50–100 文件以内。 -
避免元信息失准：配足
keys_zone内存
keys_zone 不仅存 key，还记录每个缓存项的最后访问时间（用于 inactive 判定）。若内存不足，旧 key 被挤出，对应缓存就“丢失计时”，cache manager 只能靠全盘扫描补救，显著抬高 CPU。估算公式：每 1000 个活跃缓存条目 ≈ 128 KB 共享内存。例如支撑 30 万缓存，建议keys_zone=mycache:32m。 -
匹配业务冷热节奏：合理设置
inactive
过短（如inactive=1m）会导致 cache manager 频繁触发、反复检查刚缓存的内容，徒增 CPU；过长（如inactive=30d）则积压大量冷数据，最终清理时集中爆发 I/O 和 CPU。按访问特征分档更稳：
• API 响应类：inactive=20m
• 图片/CSS/JS：inactive=4h
• 归档页/PDF：inactive=7d
不可调但需理解的底层机制
cache manager 每秒运行一次，每次最多扫描 100 个缓存子目录（非文件数），该行为由源码硬编码（NGX_HTTP_CACHE_MANAGER_FILES 宏，默认值 100），无法通过任何配置修改。它不提供“每次处理多少文件”的开关，也不支持调整唤醒间隔或休眠时长。
辅助降载的有效实践
除了核心参数，这些操作能进一步缓解 CPU 压力：
-
关闭临时路径：
use_temp_path=off
启用时（默认 on），缓存先写入临时目录再 rename，cache manager 需额外处理残留临时文件；设为 off 后文件直落目标位置，减少状态判断分支和系统调用次数。 -
限制总缓存规模：
max_size必须设置
没有max_size，cache manager 不会主动做空间回收，只依赖inactive清理。一旦磁盘写满，Nginx 会拒绝新缓存并报错 500，同时触发紧急全量扫描，CPU 瞬间飙高。建议设为磁盘分区可用空间的 70%～80%。 -
避免滥用 purger（非必需场景）
purger=on会额外启动一个清理协程，虽能加速冷数据释放，但也增加调度和扫描并发度。仅当inactive明显滞后（如日均新增 10 万+ 缓存且冷数据占比超 60%）时才考虑启用，并配合purger_files=5和purger_sleep=100控制节奏。
