proxy_cache_revalidate 是 Nginx 在缓存过期后发起轻量级条件请求以静默更新缓存的机制，需配合 proxy_cache、proxy_cache_valid 等指令启用，支持 304 响应复用旧内容并刷新 TTL，依赖后端提供 Last-Modified 或 ETag 头。
proxy_cache_revalidate 是 Nginx 提供的一个关键缓存优化指令，它让缓存资源在过期后能“安静地”向后端发起条件请求（如 If-Modified-Since 或 If-None-Match），而不是直接丢弃缓存并阻塞用户等待完整响应。启用后，Nginx 在缓存条目过期时不会立即回源拉取完整内容，而是先发一个轻量级的验证请求；如果后端返回 304 Not Modified，就原地刷新缓存 TTL 并继续服务旧内容；若返回新内容（200），则更新缓存并返回给客户端。
开启 revalidate 的前提配置
该功能不是独立开关，需配合基础缓存模块协同工作：
- 必须启用
proxy_cache并指定有效的缓存区（如proxy_cache my_cache） - 需设置
proxy_cache_valid明确定义不同状态码的缓存时间（例如proxy_cache_valid 200 302 10m;） - 推荐开启
proxy_cache_lock（避免重复回源）和proxy_cache_use_stale（提升容错性，比如updating状态下可直接用旧缓存） - 确保后端响应中包含标准缓存校验头（
Last-Modified或ETag），否则 Nginx 无法构造有效的条件请求
如何启用并控制重验证行为
只需在 location 块中添加：
proxy_cache_revalidate on;
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
它默认在缓存过期后自动触发验证。你还可以结合以下配置精细控制：
-
proxy_cache_lock on;：防止多个并发请求同时触发回源验证，只让第一个请求去校验，其余等待结果 -
proxy_cache_use_stale updating;：当缓存正在被 revalidate 时，仍可用旧缓存响应用户，实现“无感更新” -
proxy_cache_background_update on;：让验证请求在后台异步执行，不阻塞当前响应（需搭配use_stale updating才生效）
验证是否生效的小技巧
可通过 Nginx 日志或响应头观察行为：
- 开启
log_format记录$upstream_http_x_cache（需后端配合输出）或自定义变量如$upstream_cache_status，常见值：HIT、MISS、STALE、REVALIDATED - 用 curl 查看响应头：
curl -I http://your-site/path，若看到X-Cache: REVALIDATED或响应中含Age重置、Cache-Control更新，说明 revalidate 已触发 - 检查后端 access log：revalidate 请求的 User-Agent 通常为
nginx-revalidate（可识别区分）
常见误区与注意事项
这个功能容易被误解或配置失效：
- 它只对已缓存且已过期的资源生效；未缓存或根本没命中缓存的请求不会触发 revalidate
- 如果后端不返回
Last-Modified或ETag，Nginx 无法生成条件请求，会直接走普通回源（即降级为普通MISS） -
proxy_cache_revalidate不影响缓存未过期时的行为——此时仍是标准 HIT，完全不接触后端 - 注意与
proxy_cache_valid中的updating参数区分：updating控制的是“缓存即将过期时是否允许用旧内容”，而revalidate控制的是“过期后如何安全更新”
