max_size 是软性上限而非硬隔离，依赖后台LRU清理和inactive参数判定可删缓存，需配合inactive设置、use_temp_path=off、独立挂载及运维监控才能有效防爆满。
不能靠 max_size 实现“严格限制”，它本质是软性上限 + 主动清理策略，不是硬隔离或实时截断机制。但配合合理配置和运维习惯，能有效防止分区爆满。
max_size 的真实作用机制
max_size 不会在缓存写入时实时检查磁盘用量并拒绝新缓存；而是在后台周期性扫描（默认每 0.5 秒一次），当发现当前缓存总大小超过设定值时，按 LRU（最近最少使用）原则删除最久未被访问的缓存文件。
- 它依赖
inactive参数判断“是否可删”——只有超过inactive时间未被访问的缓存才进入淘汰队列 - 即使超出
max_size，已活跃的缓存仍会保留，直到它们变“冷” - 极端情况下（如所有缓存都在高频访问），实际占用可能长期高于
max_size
让 max_size 更可靠的关键配置
单设 max_size=1g 远不够。必须组合以下三项：
-
显式设置
inactive：例如inactive=1h，确保旧缓存能及时释放；不设或设过大（如7d）会导致空间无法回收 -
关闭临时中转：
use_temp_path=off：避免响应先写入proxy_temp_path再搬入缓存目录，减少双倍磁盘占用和清理盲区 -
独立挂载缓存路径：把
/var/cache/nginx单独挂载到一块专用磁盘或逻辑卷（如/dev/vg_nginx/lv_cache），便于监控和限流，也避免影响系统根分区
必须做的配套运维动作
max_size 是自动策略，不是保险丝。需人工补位：
-
定期监控实际占用：用
du -sh /var/cache/nginx或 Prometheus + nginx-exporter 报警，阈值建议设为max_size × 0.8 -
手动触发清理（应急）：执行
nginx -s reload不清缓存；要用rm -rf /var/cache/nginx/* && mkdir -p /var/cache/nginx（注意权限重置） -
限制单个响应体大小：搭配
proxy_max_temp_file_size 10m，防止超大响应（如视频切片）绕过缓存直接堆积临时文件
替代思路：更严格的磁盘控制手段
如果业务对“绝对不爆满”有强要求，仅靠 Nginx 自身配置不够，可叠加系统级防护：
- 用
quota对 Nginx 缓存目录所属用户（如_www）设置磁盘配额 - 在容器或虚拟机环境，对挂载点设置
sizeLimit（如 Kubernetes 的emptyDir.sizeLimit） - 用
systemd-tmpfiles配置定时清理，或 cron 脚本检测并报警
