Nginx 不支持 proxy_cache_revalidate 指令，所谓效果实为内置 HTTP 协商缓存行为：后端返回 ETag/Last-Modified → Nginx 过期后发条件请求 → 收到 304 复用缓存体。

Nginx 并没有 `proxy_cache_revalidate` 这个配置指令——它不是官方支持的语法，所有稳定版 Nginx 的文档、源码和发行包中均未定义该指令。你看到的所谓“启用后减少重复文件网络开销”的效果，实际来自 Nginx 内置的标准 HTTP 协商缓存行为，而非某个开关式配置。 真正起作用的是：后端返回规范的 `ETag` 或 `Last-Modified` 响应头 → Nginx 在缓存过期时自动发出 `If-None-Match` 或 `If-Modified-Since` 条件请求 → 后端干净返回 `304 Not Modified` → Nginx 复用本地缓存体，只传输响应头（约 200–500 字节），从而节省响应体带宽。

让静态文件复用 304 的关键前提

要让 JS/CSS/图片等静态资源在缓存过期后仍能走 304，必须满足：

• 源站（如 Nginx 自身或上游 Web 服务器）为这些文件返回合法 ETag（带英文双引号，如 ETag: "a1b2c3"）或 Last-Modified（格式为 RFC 1123 时间）
• 静态文件服务未显式关闭协商缓存（例如 Apache 的 FileETag None 或 Nginx 的 etag off; 需禁用）
• 响应头中包含可缓存声明，例如 Cache-Control: public, max-age=3600；若使用 s-maxage，优先级更高

Nginx 端必须启用的基础缓存配置

没有虚构指令，靠真实参数构建可靠缓存链路：

FastAPI Flask Proxy

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

下载

• 定义缓存区：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m inactive=1h max_size=1g;
• 在 location 中启用并设有效期：proxy_cache static_cache; proxy_cache_valid 200 302 1h;
• 防并发击穿：proxy_cache_lock on; proxy_cache_lock_timeout 200ms;
• 提升用户体验：proxy_cache_use_stale updating; proxy_cache_background_update on;

验证是否真走了 304 复用

不能只看配置，要看运行时行为：

• 日志中加入 $upstream_cache_status，出现 revalidated 表示缓存已过期且成功收到 304
• 用 curl -I 观察：首次响应含 ETag 和 Cache-Control；缓存过期后再请求，若返回 304 Not Modified 且无 Content-Length，说明协商生效
• 注意区分：浏览器主动刷新（F5）也会发条件请求并返回 304，但此时 $upstream_cache_status 是 HIT 或 MISS，不是 revalidated

比 revalidate 更有效的带宽节省手段

对静态文件而言，依赖“过期后验证”是兜底策略；真正大幅降开销靠的是避免过期：

• 版本化 URL：如 /js/app.a1b2c3.js，后端返回 Cache-Control: public, immutable, max-age=31536000，Nginx 几乎永不回源
• 分离缓存层级：浏览器用短 max-age（如 60s），Nginx 用长 s-maxage（如 3600s），兼顾更新及时性与带宽效率
• 统一缓存键：消除大小写、空格、参数顺序差异导致的重复缓存，提升命中率