proxy_cache_revalidate 的作用是让 nginx 在缓存过期后发起条件请求验证有效性：若后端返回304则刷新缓存，否则更新缓存；需配合 proxy_cache_valid 和后端支持 etag/last-modified 才生效，并与 proxy_cache_use_stale 协同实现异步重验证。

proxy_cache_revalidate 的作用是让 Nginx 在缓存项过期后，不直接丢弃它，而是先向后端发起一次条件请求（如带 If-Modified-Since 或 If-None-Match 头），验证缓存是否仍有效。如果后端返回 304 Not Modified，Nginx 就继续使用本地缓存并刷新其有效期；否则，就用新的响应替换缓存。

启用 revalidate 的基本写法

该指令本身是布尔开关，只需设为 on 即可生效：

• proxy_cache_revalidate on;

它必须配合 proxy_cache_valid 和后端支持条件请求（ETag / Last-Modified）才能起效。若后端不返回这些头部，Nginx 无法构造条件请求，revalidate 实际不会触发。

FastAPI Flask Proxy

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

下载

revalidate 和 use_stale 的协同关系

revalidate 本身不解决“缓存过期但后端不可用”时的可用性问题。这时候需要 proxy_cache_use_stale 配合：

• proxy_cache_use_stale error timeout http_500;：允许在后端出错、超时或返回 500 时，返回已过期的缓存内容
• 当 use_stale 触发时，Nginx 会一边返回旧缓存，一边在后台悄悄执行 revalidate —— 这叫“异步重验证”，用户无感知

实际生效的关键前提

以下三点缺一不可，否则 revalidate 不会真正工作：

• 后端响应必须包含 ETag 或 Last-Modified 头部
• Nginx 缓存中必须已存有该资源（首次请求不会触发 revalidate）
• 缓存已过期（由 proxy_cache_valid 或 inactive 决定），且客户端请求未携带 Cache-Control: no-cache 等强制绕过缓存的头

如何确认它在运行

通过响应头中的 X-Cache-Status 或自定义头观察行为：

• add_header X-Cache-Status $upstream_cache_status;
• 看到 REVALIDATED 表示成功完成条件请求并刷新了缓存
• 看到 STALE 说明用了过期缓存，同时后台正在 revalidate