proxy_cache_valid需按状态码分层设置、绑定启用位置、配合cache_key与bypass，并协同inactive参数——如200/301/302设7d，404设1m，304设24h，且必须置于启用proxy_cache的location块内。
直接用 proxy_cache_valid 控制静态响应缓存时长，关键不是设一个“长数字”，而是按状态码分层、按资源稳定性分级、按业务容忍度设定——同一类资源，200 和 404 的缓存时间理应不同，且必须配合缓存启用逻辑才能生效。
按 HTTP 状态码精准设置有效期
静态资源常见响应状态需区别对待：
-
成功响应（200/301/302）：通常可长期缓存，例如
proxy_cache_valid 200 301 302 7d;—— JS/CSS/图片这类不变动的文件，7 天很稳妥 -
客户端错误（404）：建议短周期缓存（如
proxy_cache_valid 404 1m;），避免把临时缺失误判为永久失效，又不至于反复回源刷错 -
重定向（304）：表示资源未变，适合复用原缓存，可设为
proxy_cache_valid 304 24h;，减少条件请求开销 -
其他状态（any）：兜底规则慎用，例如
proxy_cache_valid any 10s;可防异常响应长期滞留，但不应替代明确分类
与缓存启用位置强绑定，脱离 context 无效
proxy_cache_valid 必须写在启用了 proxy_cache 的 location 块内，且仅对该 location 生效。它不继承、不全局作用：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 只匹配静态后缀的 location 才配它，例如：
location ~* \.(js|css|png|woff2)$ { proxy_cache static_cache; proxy_cache_valid 200 302 1y; } - 若在 server 块或未启用 proxy_cache 的 location 中写，该指令会被忽略
- 多个 location 可设不同规则，比如 API 接口 location 不配此指令，而 /static/ 下的则严格分级
配合 cache_key 与 bypass，避免“缓存了却不用”
即使设置了 7d，如果 proxy_cache_key 包含了变动参数（如 $args 或 $http_user_agent），或客户端带 Cache-Control: no-cache，实际仍会 BYPASS 或 MISS：
- 推荐精简 key：
proxy_cache_key "$scheme$request_method$host$uri";（去掉$args，除非参数语义关键） - 允许跳过缓存：
proxy_cache_bypass $http_cache_control $arg_nocache;，让开发调试可控 - 验证是否真起作用：加
add_header X-Cache-Status $upstream_cache_status;，看到HIT才算落地
注意 inactive 与 valid 的协同关系
proxy_cache_valid 决定“能存多久”，inactive（在 proxy_cache_path 中定义）决定“多久不访问就删”。两者共同影响实际驻留时间：
- 若
proxy_cache_valid 200 1h;但inactive=30m;，则哪怕内容还新鲜，30 分钟没被访问也会被清理 - 建议
inactive≥ 最长proxy_cache_valid，例如设inactive=7d;对应200 7d;，避免缓存提前蒸发 - 磁盘空间紧张时，
inactive是更主动的清理机制，比等max_size触发淘汰更可靠
