直接在location或server块中按状态码分组设置proxy_cache_valid指令可精准控制缓存时长，需同时满足缓存区定义、作用域启用缓存、上游响应允许缓存三前提，且配置顺序影响覆盖逻辑。
直接在 location 或 server 块里为不同状态码写多行 proxy_cache_valid 指令，就能精准控制缓存时长。它不是开关，只管“缓存多久”，真正起效还得配齐三样东西：缓存区定义、当前作用域启用缓存、上游响应本身允许被缓存。
按状态码语义分组设置时间
不同状态码代表不同业务含义，缓存时间要匹配其稳定性：
-
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：兜底规则，覆盖未显式声明的状态码（如 403、410、429），但不覆盖已定义的 → 可加
proxy_cache_valid any 5s;
注意配置顺序和覆盖逻辑
proxy_cache_valid 按照书写顺序从上到下匹配，更具体的规则优先；同状态码后写的会覆盖前写的。所以建议把高优先级、需严格控制的规则（比如 301、302、404）放在前面。
- 例如：
proxy_cache_valid 302 2m;写在proxy_cache_valid 301 302 10m;后面，那所有302都走2m，不受后面那条影响 - 又如：
proxy_cache_valid 200 10m;和proxy_cache_valid 200 301 302 5m;共存时，由于200单独定义在前，就以10m为准
确保缓存真正生效的三个前提
缺一不可，否则所有 proxy_cache_valid 都不工作：
- 在
http块中定义缓存区：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g; - 在当前
location中启用该区：proxy_cache my_cache; - 上游响应默认不缓存含
Set-Cookie、Cache-Control: private/no-cache的响应；必要时加proxy_ignore_headers Set-Cookie Cache-Control;强制忽略
用作用域实现精细覆盖
可以在不同层级重复使用 proxy_cache_valid，以最近的作用域为准：
- 全局策略（
http块）：proxy_cache_valid 200 5m; any 1m; - 接口路径覆盖（
location /api/）：proxy_cache_valid 200 30s; 500 5s; - 结果：
/api/下的200缓存 30 秒、500缓存 5 秒，其余未覆盖状态码仍走any 1m
调试时加一句 add_header X-Cache-Status $upstream_cache_status;，用 curl -I 看响应头是否出现 X-Cache-Status: HIT，就能确认是否命中缓存。
