max_size 是软性上限而非硬隔离，依赖后台每0.5秒扫描+LRU清理过期缓存；需配合 inactive、use_temp_path=off、独立挂载三项配置及监控、限响应体、手动清理等运维动作才能有效防爆满。
max_size 不能“严格限制”磁盘占用总量，它本质是软性上限 + 后台主动清理机制，不是实时拦截或硬隔离。想靠它防爆满，必须理解它的运行逻辑，并组合关键配置与运维动作。
max_size 的真实工作方式
它不会在每次写缓存时检查磁盘用量并拒绝新内容。Nginx 后台每 0.5 秒扫描一次缓存目录，发现总大小超过 max_size 后，才按 LRU（最近最少使用）原则删除「已过 inactive 时间」的缓存文件。
- 只有 inactive 时限已过的缓存才进入淘汰队列；活跃缓存即使超限也保留
- 如果所有缓存都在高频访问，实际占用可能长期高于 max_size
- 不设 inactive 或设得过大（如 7d），会导致空间无法及时回收
让 max_size 发挥实效的三项硬性配置
单设 max_size=1g 没用，必须同步落实：
- 显式设置合理的 inactive：例如 inactive=1h 或 inactive=6h，确保旧缓存能被识别为“可删”。业务冷热明显时，可按访问周期设为 2× 最长空闲间隔
- 关闭临时中转路径：use_temp_path=off。避免响应先写入 proxy_temp_path 再搬入缓存目录，减少双写、权限错乱和清理盲区
- 缓存路径独立挂载：把 /var/cache/nginx 或 /usr/local/var/cache/nginx 单独挂载到专用磁盘或逻辑卷（如 lv_cache），既方便监控，也防止拖垮根分区
不可或缺的配套运维动作
max_size 是策略，不是保险丝。人工补位不可少：
- 定期监控实际占用：用 du -sh /var/cache/nginx 或 Prometheus + nginx-exporter，报警阈值建议设为 max_size × 0.8
- 限制单个响应体大小：搭配 proxy_max_temp_file_size 10m，防止大响应绕过缓存直接堆积在 proxy_temp_path
- 应急手动清理：rm -rf /var/cache/nginx/* && mkdir -p /var/cache/nginx（注意重置属主：chown _www:_www /var/cache/nginx）
更严格的兜底方案（强要求场景）
若业务不允许任何爆满风险，仅靠 Nginx 配置不够，需叠加系统级控制：
- 对 Nginx 运行用户（如 _www）启用磁盘配额（quota）
- 容器环境用 emptyDir.sizeLimit 或 initContainer 限容
- 用 systemd-tmpfiles 或 cron 脚本定时检测 + 报警 + 自动清理
