nginx缓存失效基于响应头、proxy_cache_valid和inactive三规则被动判定，由cache manager异步批量清理；通过stale机制兜底、url版本化、purge或脚本实现可控刷新。
Nginx 的后端响应缓存失效不是靠定时任务“主动刷新”，而是基于访问行为和预设规则被动回收。它不支持时钟驱动的批量刷新，但可通过组合配置实现可控、平滑、低感知的缓存更新。
缓存失效的核心依据是三类信号
- 响应头中的
Cache-Control（如max-age=300）或Expires； - Nginx 配置的
proxy_cache_valid（覆盖响应头，强制设定有效期）； -
inactive时间（如inactive=60m），即缓存项在指定时间内未被任何请求命中，就会被标记为可清理。
这三者共同决定一个缓存条目是否“过期”或“闲置”，但真正删除动作由 cache manager 进程异步扫描执行——它不按秒级调度，只在系统空闲或磁盘 I/O 允许时批量回收，无法精确控制何时删。
让缓存“失效后仍可用”的关键：stale 机制
用户不该因缓存过期就卡住或看到错误页。正确做法是用过期内容兜底，后台悄悄拉新：
-
proxy_cache_use_stale updating：允许返回正在后台更新的旧缓存； -
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504：后端出问题时也返回旧缓存； - 必须搭配
proxy_cache_lock on和proxy_cache_background_update on，否则并发请求会全部阻塞或各自回源。
真正“刷新”缓存的实用方式只有三种
-
URL 版本化：把构建哈希或时间戳嵌入路径（如
/app.js?v=20260706），配合稳定proxy_cache_key "$scheme$host$request_uri"，让新 URL 触发全新缓存条目； -
主动 purge：启用
ngx_http_proxy_cache_purge模块，通过内部接口发送PURGE请求精准清除某条缓存； -
脚本清理：用 cron 定期
rm -f /var/cache/nginx/*/*/<key-hash></key-hash>，再调用nginx -s reload或proxy_cache_path对应的cache manager重载索引（注意：仅删文件不重载会导致内存索引不一致）。
容易被忽略的细节
-
timer_resolution不影响缓存，它只优化日志时间戳和连接超时精度； -
if块里写proxy_cache_valid是无效的，必须放在location或server级别； -
proxy_cache_key若包含$args但没过滤无关参数（如跟踪用的utm_source），会导致缓存碎片化、命中率暴跌。
不复杂但容易忽略。
