proxy_cache_revalidate on的作用是缓存过期后自动发if-modified-since/if-none-match条件请求校验，命中304则复用旧缓存并更新有效期，否则回源获取新响应；需配合proxy_cache_valid、proxy_cache_lock、后端规范支持etag/last-modified及304响应方可生效。

proxy_cache_revalidate on 的作用，是在 Nginx 本地缓存已过期但尚未被清除时，不直接丢弃旧内容，而是自动向后端发起条件请求（如 If-Modified-Since 或 If-None-Match），验证是否还能复用——校验通过（返回 304 Not Modified）就刷新缓存有效期并返回旧内容；否则获取新响应并更新缓存。

它不是“使用旧缓存前必校验”，而是仅在缓存过期后、且有请求命中该过期缓存时才触发。新鲜缓存（未过期）直接返回，完全不走校验流程。

要让它真正生效，必须满足几个硬性前提，缺一不可：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

必须配置基础缓存体系

• 定义缓存存储路径：

  proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m max_size=1g;

• 在 location 中启用缓存区域：

  proxy_cache my_cache;

• 明确设置缓存有效期（否则无“过期”概念，无法触发 revalidate）：

  proxy_cache_valid 200 302 5m;  # 例如 5 分钟

必须开启 revalidate 并配好协同机制

• 启用校验开关：

  proxy_cache_revalidate on;

• 开启缓存锁，防止并发请求同时触发多次回源：

  proxy_cache_lock on;
  proxy_cache_lock_timeout 200ms;  # 避免锁等待太久

• 允许在后台校验期间继续返回旧缓存（提升用户体验）：

  proxy_cache_use_stale updating;

后端必须支持标准协商缓存

Nginx 不会凭空生成 ETag 或 Last-Modified，它只依赖后端响应头：

• ✅ 后端需返回规范的 ETag: "abc123"（带英文双引号）或 Last-Modified: Wed, 21 Oct 2026 07:28:00 GMT
• ✅ 收到 If-None-Match 或 If-Modified-Since 时，必须严格比对并返回干净的 304 Not Modified（空响应体、无 Content-Length、无 Transfer-Encoding）
• ❌ 返回 200 + 完整内容、或 304 但附带响应体/错误头，都会导致校验失败或缓存异常

如何确认它真的在工作

• 查看响应头中的 X-Cache-Status（需配置 add_header X-Cache-Status $upstream_cache_status;）：
  • REVALIDATED：缓存过期后成功收到 304，复用了旧内容
  • STALE+updating：正在后台校验，前台返回旧缓存
• 用 curl -I 观察两次请求：
  第一次（缓存未建或过期）→ 返回 200，含 ETag 和 Cache-Control
  等过期后再请求 → 若返回 304 且无 Content-Length，说明校验链路通了
• 检查 Nginx access log，筛选出状态码为 304 且 upstream 响应字节数极小（通常为 0 或几百字节）的记录

不复杂但容易忽略。