最有效、最可控的方式是直接在location或server块中按状态码语义分组写多条proxy_cache_valid指令，如200/206/304缓存1h、301缓存7d、302缓存2m、404缓存30s、5xx缓存10s、any兜底5s，并确保proxy_cache_path、proxy_cache及响应可缓存三者同时满足。
直接在 location 或 server 块中写多条 proxy_cache_valid 指令，每条明确指定状态码和时间，是最有效、最可控的方式。它不依赖后端响应头，由 Nginx 主动控制缓存生命周期。
按状态码语义分组设置合理时长
不同状态码代表不同业务含义，缓存时间应匹配其稳定性与敏感性：
-
200 / 301 / 302 / 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：兜底规则，覆盖所有未显式声明的状态码 → 如
proxy_cache_valid any 5s;，注意它不会覆盖已定义的状态码
确保缓存真正生效的三个硬性前提
仅配置 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; - 上游响应本身要“可缓存”：默认不缓存含
Cache-Control: no-cache、private或Set-Cookie的响应；必要时加proxy_ignore_headers Cache-Control Set-Cookie;强制忽略
验证是否按预期工作
调试阶段建议添加标识头，直观判断缓存行为：
- 在
location中加入：add_header X-Cache-Status $upstream_cache_status; - 用
curl -I http://host/path多次请求，观察响应头中X-Cache-Status是否从MIS变为HIT，以及响应时间是否明显下降 - 测试 301/302 时优先用
curl，避免浏览器本地强缓存干扰
