应按资源类型和状态码差异配置proxy_cache_valid：静态资源设长TTL（如200 1y）并配合URL版本化；动态页面设中短TTL（如200 302 5m）加updating机制；重定向与错误页按语义分级设置；兜底用any 5s，并忽略干扰响应头。
直接按资源类型对应的状态码和业务特性来设 proxy_cache_valid，而不是统一写个时间。它不决定“缓存不缓存”，只管“缓存多久”，真正生效还得靠配套指令和响应头配合。
静态资源：用长 TTL + URL 版本化驱动更新
JS、CSS、图片这类内容不变就不该变，关键在避免缓存污染和无效回源：
- 设极长有效期，例如
proxy_cache_valid 200 1y;（一年），让 Nginx 尽量不验证、不回源 - 必须配合 URL 版本控制（如
/app.js?v=20260629），否则改了文件用户看不到新内容 - 404 也要缓存，比如
proxy_cache_valid 404 30s;，防恶意探测或参数拼错刷空缓存 - 别把
$args加进proxy_cache_key，否则带随机参数（?t=123）会导致缓存分裂
动态页面与 API：中短 TTL + 后台静默刷新
首页、列表页、商品详情等有变化但不需实时，目标是“用户无感更新”：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 设合理 TTL，例如
proxy_cache_valid 200 302 5m;，兼顾新鲜度和后端压力 - 必须开启
proxy_cache_use_stale updating;，这是返回旧内容+后台更新的前提 - 搭配
proxy_cache_background_update on;和proxy_cache_lock on;，防止并发请求击穿缓存 - 加一句
proxy_cache_valid 304 1h;，把上游返回的 304 也缓存起来，减少重复校验
重定向与错误页：按语义差异化设置
不同状态码代表不同业务含义，混设会破坏行为预期：
-
proxy_cache_valid 301 7d;—— 永久重定向，语义承诺长期有效，可放心缓存 -
proxy_cache_valid 302 2m;—— 临时重定向，可能随时变更，设太长会跳转到已失效目标 -
proxy_cache_valid 404 1m;—— 缓存太长会掩盖真实上线延迟，1 分钟足够试探 -
proxy_cache_valid 500 502 503 504 30s;—— 错误页缓存缓解雪崩，但不宜过长以免掩盖恢复
兜底与兼容：any 规则和响应头处理
没显式配置的状态码默认不缓存，得靠 any 规则兜底，同时要应对上游响应头干扰：
- 加一句
proxy_cache_valid any 5s;，确保 403、429 等未明确定义的状态码也有默认缓存期 - 若上游返回
Cache-Control: no-cache或max-age=0，Nginx 默认忽略proxy_cache_valid，必须加proxy_ignore_headers Cache-Control; - 同理，如果响应带
Set-Cookie，也会被默认拒绝缓存，必要时一并忽略：proxy_ignore_headers Set-Cookie Cache-Control;
不复杂但容易忽略。
