最清晰可控的方式是为不同http状态码单独配置proxy_cache_valid；需按顺序显式声明，200/206/304缓存1h、301缓存7d、302缓存2m、404缓存30s、5xx缓存10s、any兜底5s，并确保proxy_cache_path、proxy_cache及响应可缓存三者同时满足。

直接在 location 或 server 块中写多条 proxy_cache_valid 指令，每条明确指定状态码和时间，是最清晰、最可控的方式。它不依赖后端响应头，由 Nginx 主动控制缓存生命周期。

按状态码语义分组设置合理时长

不同状态码代表不同业务含义，缓存时间应匹配其稳定性与敏感性：

• 200 / 206 / 304：正常响应或协商成功，内容通常稳定 → 可设 proxy_cache_valid 200 206 304 1h;
• 301：永久重定向，适合长期缓存 → 单独写 proxy_cache_valid 301 7d;
• 302：临时重定向，必须设短，避免用户错过变更 → 推荐 proxy_cache_valid 302 2m;
• 404：资源不存在，缓存过长会掩盖新上线内容 → 建议 proxy_cache_valid 404 30s;（最长不超过 1 分钟）
• 500 / 502 / 503 / 504：后端故障类错误，短时缓存可缓解雪崩 → 推荐 proxy_cache_valid 500 502 503 504 10s;
• any：兜底规则，覆盖所有未显式声明的状态码 → 如 proxy_cache_valid any 5s;（注意：它不会覆盖已定义的状态码）

确保缓存真正生效的三个硬性前提

proxy_cache_valid 只管“缓存多久”，不管“是否缓存”。以下三项必须同时满足，否则所有规则都无效：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 在 http 块中定义缓存区：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;
• 在当前 location 中启用该缓存区：proxy_cache my_cache;
• 上游响应本身要“可缓存”：默认不缓存含 Cache-Control: no-cache、private 或 Set-Cookie 的响应；必要时加 proxy_ignore_headers Cache-Control Set-Cookie; 强制忽略

利用作用域层级实现精细覆盖

Nginx 支持在不同配置块中重复使用 proxy_cache_valid，以**最近的作用域为准**：

• 全局策略（http 块）：proxy_cache_valid 200 5m; any 1m;
• 接口路径覆盖（location /api/）：proxy_cache_valid 200 30s; 500 5s;
• 结果是：该路径下 200 缓存 30 秒、500 缓存 5 秒；其余状态码仍走 any 1m

验证是否按预期工作

调试阶段建议添加标识头，直观判断缓存行为：

• 在 location 中加入：add_header X-Cache-Status $upstream_cache_status;
• 用 curl -I http://host/path 多次请求，观察响应头中是否从 MISS 变为 HIT，以及响应时间是否明显下降
• 检查 Nginx error log（需开启 debug 级别）中是否有 using cached response 或 cached response expired 等记录