proxy_cache_revalidate 是 nginx 的缓存再验证机制，仅对已过期缓存触发条件请求（if-modified-since/if-none-match），后端返回304则复用并刷新缓存，需配合 proxy_cache_valid 和 proxy_cache_lock 使用。

proxy_cache_revalidate 是 Nginx 实现“缓存再验证”的核心机制，它不直接延长缓存时间，而是在缓存已过期但内容很可能未变时，主动向后端发起条件请求，避免传输完整响应体——本质是用一次轻量级 HTTP 请求（304）换回带宽与延迟的节省。

触发前提：只对已缓存且过期的响应生效

该指令不会影响未缓存（MISS）或仍处于有效期内（HIT）的请求。只有当缓存项满足两个条件时才会触发：

• 缓存已写入磁盘/内存，且其有效期（由 proxy_cache_valid 定义）已结束
• 客户端请求命中该过期缓存项（例如用户刷新页面、或缓存自然到期后首次访问）

校验方式：自动添加 If-Modified-Since 或 If-None-Match

Nginx 会根据原始响应头自动选择校验头：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 若后端返回了 Last-Modified，Nginx 发起请求时带上 If-Modified-Since
• 若后端返回了 ETag（尤其强 ETag），Nginx 使用 If-None-Match
• 若两者都存在，优先使用 ETag —— 更精确，不受服务器时钟误差影响

后端响应决定是否复用旧缓存

再验证成败完全取决于后端行为：

• 后端比对成功 → 返回 304 Not Modified，无响应体，Nginx 复用本地缓存并重置其过期时间（依据 proxy_cache_valid）
• 后端比对失败 → 返回 200 OK + 新响应体，Nginx 更新缓存并返回新内容
• 后端忽略条件头、一律返回 200 或带 Cache-Control: no-cache → 再验证失效，每次均回源传输全量数据

必须配合的关键配置

单独开启 proxy_cache_revalidate on 不足以保障效果：

• proxy_cache_valid 必须显式设置（如 200 10m），否则缓存无初始有效期，无法进入“过期→再验证”流程
• proxy_cache_lock on 推荐启用，防止多个并发请求同时触发再验证，造成重复回源
• 后端需稳定输出 Last-Modified 或 ETag，且对条件请求严格返回 304（空体+正确头）