不能单靠max_size实现严格防爆满，需配合inactive设置、路径隔离、临时文件控制和运维监控；max_size仅在后台扫描时清理超inactive时间的冷数据，应按业务特征设inactive（静态资源1h–24h、API缓存5m–30m），max_size预留10%–15%空间；须关闭use_temp_path或隔离temp与cache路径；需实时监控磁盘用量并设告警阈值；还需剥离无意义URL参数、限制回源频率以防范恶意填充。
不能单靠 max_size 实现“严格防爆满”，它本质是软性上限，依赖后台周期性 LRU 清理，必须配合 inactive 设置、路径隔离、临时文件控制和运维监控才能真正起效。
合理设置 max_size 与 inactive 的组合
max_size 只在后台扫描时触发清理（默认每 0.5 秒一次），且只删“冷数据”——即超过 inactive 时间未被访问的缓存项。如果 inactive 设得过大（如 7d）或没设，即使磁盘已超限，活跃缓存仍会滞留，空间无法释放。
- 建议按业务冷热特征设定：静态资源（JS/CSS/图片）设
inactive=1h–24h；API 缓存可设inactive=5m–30m -
max_size应预留 10%–15% 空间给文件系统元数据和突发写入，例如挂载了 200GB 专用盘，max_size=180g更稳妥 - 避免设
inactive=0或不设——这会让 Nginx 完全不主动淘汰，max_size形同虚设
关闭临时中转路径，防止双写失控
Nginx 默认先将代理响应写入 proxy_temp_path，再搬入缓存目录。这个过程会产生临时文件，既占用额外空间，又绕过 max_size 管控，还可能因清理延迟导致磁盘悄悄涨满。
- 启用
use_temp_path=off（Nginx ≥ 1.7.12），让响应直写缓存目录，跳过临时中转 - 确保
proxy_temp_path和proxy_cache_path不在同一个磁盘分区，尤其要避开根分区 - 若必须用临时路径，需单独挂载并配 quota 或 sizeLimit，不能依赖 Nginx 自身管理
绑定真实磁盘用量做主动监控与干预
max_size 是策略，不是保险丝。实际占用必须持续采集，不能只看配置值。
- 用
du -sh /var/cache/nginx或 Prometheus + nginx-exporter 每分钟采集真实大小 - 告警阈值设为
max_size × 0.8，而非 100%，留出响应窗口 - 当使用率持续 >90% 或淘汰速率突增 3 倍以上，自动触发限流（如封禁高频回源 IP）或清理脚本
堵住恶意填充等绕过缓存键的漏洞
攻击者可通过带随机参数的 URL（如 /img.jpg?t=123456）制造海量唯一 key，让缓存无法去重，快速耗尽磁盘。此时 max_size 是最后一道防线，但前置防护更重要：
- 在
location中用map或正则剥离无意义参数，统一缓存 key - 对非标准路径或高频异常 UA，直接
proxy_cache_bypass跳过缓存 - 搭配
limit_req限制单 IP 回源频率，从源头抑制无效请求
