Nginx中proxy_cache_valid按状态码精确控制缓存时长：200响应常用30m，301推荐7d，404仅限30s；需配合proxy_cache、可缓存响应及ignore_headers等指令生效，并用X-Cache-Status验证。
直接在 location 块里写多条 proxy_cache_valid，每条对应一组状态码，Nginx 会按匹配优先级精确生效。注意：它只管“缓存多久”，不决定“是否缓存”——前提得有 proxy_cache、缓存区已定义、响应本身可缓存（如非 private/no-cache）。
200 状态码：常规成功响应
内容稳定但可能随业务更新，不宜过长也不宜太短。常见配置：
-
proxy_cache_valid 200 30m;—— 大多数静态页、API 成功结果适用 - 若内容极少变动（如官网首页），可延长至
1h或2h - 若后端返回
Cache-Control: no-cache，需加proxy_ignore_headers Cache-Control;才能强制启用该规则
301 状态码：永久重定向
语义上代表路径已长期迁移，适合强缓存，减少重复判断压力：
-
proxy_cache_valid 301 7d;—— 推荐写法，单独成行，不和 200/302 混用 - 避免与
302合并在同一指令中，否则 301 会被覆盖或降级为短周期 - 浏览器和中间代理也倾向长期信任 301，Nginx 缓存与其对齐更合理
404 状态码：资源未找到
缓存目的主要是防恶意扫描或瞬时误请求，绝不能掩盖真实上线动作：
-
proxy_cache_valid 404 30s;—— 最常用，兼顾防护与及时性 - 最长不建议超过
1m；若后端常误返回 200 + “Not Found” 文案，需先修复状态码，否则这条无效 - 如需更高防刷能力，可搭配
proxy_cache_use_stale updating;和proxy_cache_lock on;
验证是否生效，加响应头 add_header X-Cache-Status $upstream_cache_status;，看返回 HIT / MISS / BYPASS。
