proxy_cache_valid 用于精确控制不同 http 状态码响应的缓存时长，决定“哪些响应能缓、缓多久”，影响缓存命中率、回源频率和内容新鲜度。
proxy_cache_valid 不是用来“优化缓存结构”的，而是用来精确控制不同 HTTP 状态码响应的缓存时长。它不改变目录层级、内存索引或文件组织方式（那是 proxy_cache_path 的职责），而是决定“哪些响应能缓、缓多久”，从而影响缓存命中率、回源频率和内容新鲜度。
明确状态码粒度，避免默认遗漏
Nginx 默认只对 200、301、302 响应缓存，且依赖后端响应头（如 Cache-Control）才真正写入。很多关键响应被默认忽略：
- 304 Not Modified：proxy_cache_valid 完全不处理它，必须靠
proxy_cache_revalidate on配合才能延长缓存寿命 - 404 页面：默认不缓存，但静态资源缺失常重复发生，加
proxy_cache_valid 404 5m可减少无效回源 - 301/302 重定向：若漏配，每次请求都回源，失去缓存意义；建议显式写出
proxy_cache_valid 301 302 1h - 206 Partial Content（视频切片等）：CDN 回源常见，需单独配置，如
proxy_cache_valid 206 24h
用多级规则覆盖业务场景
多个 proxy_cache_valid 指令按书写顺序匹配，**最先匹配的生效**，因此要把高优先级、短时效的规则放前面：
-
proxy_cache_valid 404 5m;—— 错误响应缓存时间短，避免长期返回旧 404 -
proxy_cache_valid 500 502 503 504 1m;—— 后端故障时快速兜底，但不过久 -
proxy_cache_valid 200 304 12h;—— 主体成功响应与协商验证结果统一管理 -
proxy_cache_valid any 1m;—— 仅作兜底，慎用，防止意外缓存 403、401 等敏感响应
配合后端响应头，别被覆盖
即使写了 proxy_cache_valid 200 1h，只要后端返回 Cache-Control: no-cache 或 max-age=0，Nginx 就不会缓存。这不是 bug，是设计逻辑：
- 检查后端是否输出
Cache-Control: public, max-age=3600或s-maxage - 对私有内容（如含用户信息的 API），后端应返回
private，此时 Nginx 即使配了proxy_cache_valid也不会缓存 - 需要强制覆盖时，可用
add_header Cache-Control "public, max-age=3600";或proxy_ignore_headers Cache-Control Expires;（但会削弱语义一致性）
验证是否真正生效
不能只看配置是否存在，要观察运行时行为：
- 日志中加入
$upstream_cache_status，看到REVALIDATED表示 304 协商成功并更新了缓存元数据 - 用
curl -I发两次请求：首次响应含ETag和Cache-Control；过期后再发，若返回304且无Content-Length和响应体，说明协商生效 - 注意区分：浏览器发的条件请求返回 304 是客户端行为；Nginx 收到 304 并更新自身缓存生命周期，才是
proxy_cache_revalidate起效
