Proxy模块缓存过期由proxy_cache_valid、inactive和后端响应头协同决定：前者控制不同状态码的逻辑过期时长，inactive定义冷数据物理删除时限，后端Cache-Control/Expires可被尊重或覆盖，配合revalidate实现过期缓存后台刷新。
Proxy 模块的缓存过期策略不是靠单一指令实现的，而是由 proxy_cache_valid、inactive 和后端响应头三者协同决定。核心在于区分“逻辑过期”和“物理删除”——前者控制 Nginx 是否返回缓存内容，后者决定缓存文件是否从磁盘清除。
用 proxy_cache_valid 控制不同状态码的缓存时长
该指令定义哪些 HTTP 状态码能被缓存、缓存多久，是过期策略的第一层控制：
- 只对显式列出的状态码生效，例如
proxy_cache_valid 200 301 302 10m;表示这三类响应缓存 10 分钟 - 建议为常见错误码单独设短时间，如
proxy_cache_valid 404 1m;避免反复穿透后端 - 用
any作为兜底：proxy_cache_valid any 1m;，防止未声明状态码被意外长期缓存 - 它不作用于浏览器，仅影响 Nginx 本地代理缓存行为；若后端已返回
Cache-Control: no-cache，需配合proxy_ignore_headers Cache-Control才能覆盖
靠 inactive 参数自动清理冷缓存
这是真正意义上的“全局过期清理”机制，由 Nginx 内置 cache manager 异步执行：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 在
proxy_cache_path中设置，例如inactive=24h - 含义：某个缓存文件如果连续 24 小时没有任何请求命中，就会被物理删除
- 注意：它不看缓存是否“逻辑过期”，只看访问热度；即使
proxy_cache_valid设了 7 天，只要 24 小时没被访问，照样删 - 推荐值：静态资源可设为
7d，API 类建议1h～24h，平衡空间与实效性
结合后端响应头做动态过期判断
当后端返回的 Cache-Control 或 Expires 本身就有差异时，应优先尊重其语义：
- Nginx 默认会遵循后端响应头（如
Cache-Control: max-age=300），除非你显式禁用：proxy_ignore_headers Cache-Control Expires; - 更稳妥的做法是用
map指令提取真实响应类型，再动态赋值：map $sent_http_content_type $cache_ttl { ~*^text/ "1h"; ~*^image/ "1y"; default "0s"; }，然后在 location 中写proxy_cache_valid 200 $cache_ttl; - 这样能避免仅靠文件后缀（如
.js）误判，尤其适合后端动态生成 JS/CSS 的场景
让过期缓存仍可用并后台刷新
提升用户体验的关键：缓存过期后不立即失效，而是边返回旧内容边校验更新：
- 启用
proxy_cache_revalidate on;，要求后端支持ETag或Last-Modified - 搭配
proxy_cache_use_stale error timeout http_500;，确保后端异常时仍可返回过期缓存 - 此时响应头中可能出现
X-Cache-Status: STALE，表示正在后台刷新，用户无感知 - 注意：首次请求不会触发 revalidate，必须已有缓存且已过期才会生效
