启用 proxy_cache_revalidate 后，Nginx 在缓存过期时自动发条件请求（If-Modified-Since/If-None-Match），后端返回304则复用旧缓存并更新过期时间，显著降低回源带宽；需后端正确支持Last-Modified/ETag及304响应，配合proxy_cache_valid、proxy_cache_lock等配置，并通过X-Cache头、日志和流量对比验证效果。
通过 proxy_cache_revalidate 指令启用缓存再验证机制，Nginx 可在本地缓存过期但内容可能未变时，自动向后端发送带 If-Modified-Since（或 If-None-Match）头的条件请求。若后端返回 304 Not Modified，Nginx 复用旧缓存并更新过期时间，避免传输响应体——这能显著降低回源带宽，尤其适用于静态资源、API 响应等变化不频繁的场景。
确保后端正确支持条件请求
再验证生效的前提是后端能识别并响应 If-Modified-Since 和 If-None-Match。需确认：
- 后端为每个资源返回准确的
Last-Modified（基于文件修改时间或内容生成时间）或ETag（强校验值） - 收到条件请求时，后端严格比对时间戳或 ETag，命中则返回
304且响应体为空 - 避免后端忽略条件头、一律返回
200或返回带Cache-Control: no-cache的响应，这会使再验证失效
启用 proxy\_cache\_revalidate 并配置合理缓存策略
该指令默认关闭，需显式开启，并配合缓存有效期设置：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 在
proxy_cache_path或proxy_cache块中添加proxy_cache_revalidate on; - 使用
proxy_cache_valid 200 302 10m;设置初始缓存时间（如 10 分钟） - 搭配
proxy_cache_lock on;防止缓存失效瞬间多个并发请求同时回源 - 可选：
proxy_cache_lock_timeout 5s;避免锁等待过久影响性能
观察与验证是否真正生效
仅靠配置无法保证效果，需实际验证：
- 用
curl -I查看缓存响应头：首次访问应有X-Cache: MISS和Last-Modified；再次访问（在缓存过期后）若看到X-Cache: REVALIDATED且响应为304，说明成功复用 - 检查 Nginx 日志：开启
log_format包含$upstream_http_x_cache和$status，筛选出304回源记录 - 对比开启前后回源流量（如通过后端 access log 的字节数或监控系统），典型优化幅度可达 40%–80%，取决于资源更新频率
注意边界情况与常见陷阱
再验证不是万能的，需规避以下问题：
-
proxy_cache_revalidate仅对已缓存且过期的响应触发，对未缓存或缓存未过期的请求不生效 - 若后端返回
Cache-Control: max-age=0, must-revalidate，Nginx 会立即尝试再验证；但若返回no-store或private，则完全不缓存，再验证无从谈起 - 客户端主动刷新（F5）通常带
Cache-Control: max-age=0，此时 Nginx 默认会跳过本地缓存直接回源——可通过proxy_cache_bypass $http_cache_control;自定义绕过逻辑 - 动态内容（如含用户身份信息的 HTML）若错误地设置了
Last-Modified，可能导致不同用户看到过期内容，慎用
