必须分开配置301和302缓存时长：proxy_cache_valid 301 7d; proxy_cache_valid 302 2m;200响应需按内容稳定性分级设置，且缓存生效须满足启用缓存区、合理cache_key、忽略禁用头等前提。
proxy_cache_valid 200 302 1h 这种写法虽语法合法，但不符合重定向缓存的规范化标准，尤其在生产环境会引发语义混淆、SEO风险和状态误判。真正规范的做法是：必须按 HTTP 状态码语义独立配置，不能混写，更不能依赖 any 或通配组合覆盖 302。
必须分开配置 301 和 302，不能合并在一条指令里
Nginx 的 proxy_cache_valid 对状态码是“精确匹配 + 后定义优先”逻辑，但 301 和 302 的业务含义截然不同：
- 301 是永久重定向，代表资源已迁移，需长期稳定缓存（如 7d），保障搜索引擎权重平滑传递
- 302 是临时重定向，常用于灰度、A/B 测试或动态跳转，缓存过久会导致用户持续跳转旧目标，掩盖真实服务变更
若写成 proxy_cache_valid 200 302 1h：
- 302 被设为 1 小时，远超安全阈值（推荐 2m～5m），易造成跳转滞留
- 301 完全未显式声明，将落入 Nginx 默认行为（通常不缓存或仅缓存 1 分钟），破坏 SEO 连续性
✅ 正确写法应为两行独立声明：
proxy_cache_valid 301 7d; proxy_cache_valid 302 2m;
200 响应的缓存周期需与业务更新节奏匹配
200 是常规成功响应，其缓存时长不应机械套用 1h，而应依据内容稳定性分级设定：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 静态页面、CSS/JS 等不变资源：可设
1d或7d - 动态聚合页（如首页推荐）：建议
5m～30m - 实时数据接口（如行情、订单状态）：应禁用缓存或设极短时间（如
10s），并配合proxy_cache_bypass控制
⚠️ 注意：proxy_cache_valid 200 1h 仅对带可缓存头（如 Cache-Control: public, max-age=3600）的响应生效；若上游返回 no-cache，需加 proxy_ignore_headers Cache-Control 才能强制启用该规则。
缓存生效的前提条件缺一不可
即使 proxy_cache_valid 写得再规范，以下三点未满足，缓存仍不会命中：
- 已启用缓存区：
proxy_cache my_cache_zone;且对应proxy_cache_path已在http块中正确定义 - 缓存键合理：若重定向依赖查询参数（如
/old?ref=abc→/new），需确认proxy_cache_key包含$args，否则不同参数会共用同一缓存项 - 响应头兼容：上游返回的 302 若含
Cache-Control: no-store，必须显式添加proxy_ignore_headers Cache-Control;，否则 Nginx 会直接放弃缓存
调试时建议开启标识头：
add_header X-Cache-Status $upstream_cache_status;
用 curl -I 访问重定向 URL，连续两次请求，观察 X-Cache-Status 是否由 MISS 变为 HIT。
不复杂但容易忽略
