proxy_cache_revalidate 不控制缓存有效期，仅在 proxy_cache_valid 或后端 s-maxage/expires 定义的过期后发起条件请求（304）；需配合 proxy_cache_lock、use_stale updating 等确保高效稳定。
缓存有效期本身不由 proxy_cache_revalidate 配置，它不控制“缓存多久有效”，而是决定“过期后怎么轻量验证”。真正设置有效期的是 proxy_cache_valid 和后端响应头中的 Cache-Control: s-maxage 或 Expires。只有先让缓存有明确、合理的有效期，proxy_cache_revalidate 才能在过期那一刻起作用——发一个只传头部的条件请求（304），避免传输大体积响应体。
必须配好 proxy_cache_valid 才能触发 revalidate
proxy_cache_revalidate on 只在缓存“已过期”时才介入。而“过期”这个时间点，完全由 proxy_cache_valid 定义：
- 例如：
proxy_cache_valid 200 302 10m;表示状态码为 200 或 302 的响应，本地缓存 10 分钟 - 10 分钟一到，该缓存条目就变成
EXPIRED状态，此时若再有请求命中它，proxy_cache_revalidate才会自动发起If-None-Match或If-Modified-Since请求 - 如果没写
proxy_cache_valid，Nginx 默认不缓存该响应，revalidate根本无从谈起
后端响应头要与 proxy_cache_valid 协同
Nginx 实际采用的过期时间，是 proxy_cache_valid 和后端 Cache-Control: s-maxage 两者中的较小值（优先用 s-maxage）：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 推荐后端返回：
Cache-Control: public, s-maxage=3600（缓存 1 小时） - 同时 Nginx 配置：
proxy_cache_valid 200 1h;—— 保持一致，避免歧义 - 若后端返回
Cache-Control: max-age=60，而你配了proxy_cache_valid 200 1h，最终仍按 60 秒过期
revalidate 节省带宽的关键：让过期时间“够长但不过长”
有效期太短（如 30 秒），会导致频繁进入 EXPIRED → REVALIDATED 流程，增加验证请求数，反而抬高延迟；太长（如 24 小时）则更新滞后，且单次验证失败代价大。平衡点看资源变化频率：
- 静态资源（JS/CSS/图片）：可设
proxy_cache_valid 200 1h;，配合版本化 URL，基本不靠 revalidate - 动态页面（列表页、API）：设
proxy_cache_valid 200 5m;或10m;，再开启proxy_cache_revalidate on;，让多数过期请求走 304 - 高频更新内容（如实时数据）：revalidate 效果有限，应缩短有效期或改用其他机制（如 ESI、CDN 边缘刷新）
配套配置不能少
单独开 proxy_cache_revalidate 不足以稳定节省带宽，还需：
-
proxy_cache_lock on;：防止多个并发请求同时触发验证，只让第一个去校验，其余直接复用结果 -
proxy_cache_use_stale updating;：验证进行中，用户仍能拿到旧缓存，体验无感知 -
proxy_cache_background_update on;：配合use_stale updating，让验证在后台异步跑
