直接在 location 块中按状态码分组配置 proxy_cache_valid 即可实现精细化缓存控制，如 proxy_cache_valid 200 206 304 1h; 301 7d; 302 2m; 404 30s; 500 502 503 504 10s; any 5s;，但需同时满足定义缓存区、启用 proxy_cache、确保响应可缓存三个前提。

直接在 location 块里为每类状态码单独写 proxy_cache_valid，就能实现精细化控制。它不是设一个“全局时长”，而是按 HTTP 状态码的业务含义分层定时间——200 和 404 本就不该缓存一样久，301 和 302 的语义差异也必须体现在配置里。

按状态码语义分组设置合理时长

不同状态码代表不同响应性质，缓存时间要匹配其稳定性与敏感性：

• 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、429）→ proxy_cache_valid any 5s;，注意它不会覆盖已定义的状态码

必须同时满足三个硬性前提

proxy_cache_valid 只管“缓存多久”，不管“是否缓存”。以下三点缺一不可：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 在 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 Cache-Control Set-Cookie;

利用作用域层级做精细覆盖

Nginx 按最近的作用域生效，适合差异化策略：

• 全局基础策略（http 块）：proxy_cache_valid 200 5m; any 1m;
• 接口路径覆盖（location /api/）：proxy_cache_valid 200 30s; 500 5s;
• 结果：该路径下 200 缓存 30 秒、500 缓存 5 秒；其余未覆盖状态码仍走 any 1m

验证是否真正生效

不能只看配置是否存在，要观察运行时行为：

• 在 location 中加一行：add_header X-Cache-Status $upstream_cache_status;
• 用 curl -I 多次请求，观察响应头中 X-Cache-Status 是否出现 HIT、MISS 或 EXPIRED
• 注意：浏览器对 301 有强本地缓存，测试时优先用 curl 绕过干扰