proxy_cache_valid 的核心作用是为不同 HTTP 状态码指定缓存时长，但需同时满足定义缓存区、启用缓存及上游响应可缓存三项前提；必须按状态码显式配置，如 301/302 需单独声明，且配合 ignore headers 才能生效。

proxy_cache_valid 的核心作用是：为不同 HTTP 状态码指定缓存时长，但它本身不决定“是否缓存”，只决定“缓存多久”。要让它真正起效，必须满足三个硬性前提，且配置方式需紧扣状态码语义。

FastAPI Flask Proxy

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

下载

必须同时满足的三项前提
缺一不可，否则 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、no-store，也不能带 Set-Cookie 头（除非加 proxy_ignore_headers Set-Cookie; 主动忽略）

按状态码分组设置合理时长
每条 proxy_cache_valid 指令明确列出状态码和时间，Nginx 会精确匹配，更具体的优先于 any：

• proxy_cache_valid 200 301 302 10m; → 成功响应和重定向，内容较稳定，适合中等缓存
• proxy_cache_valid 301 7d; → 永久重定向，可长期缓存；proxy_cache_valid 302 2m; → 临时重定向，必须设短
• proxy_cache_valid 404 30s; → 防爬虫反复刷不存在路径，太长会掩盖新资源上线
• proxy_cache_valid 500 502 503 504 10s; → 后端故障类错误，短时缓存缓解雪崩，但不宜过久
• proxy_cache_valid any 5s; → 兜底规则，覆盖所有未显式声明的状态码（不覆盖已定义的）

重定向响应要单独显式声明
Nginx 默认不缓存 301/302，哪怕写了 proxy_cache_valid 200 10m 也不生效：

• 必须写成 proxy_cache_valid 301 1h; proxy_cache_valid 302 5m; 这类具体形式
• 若后端返回的 302 带 Cache-Control: no-cache，需配合 proxy_ignore_headers Cache-Control; 才能让规则生效
• 注意：proxy_cache_valid 缓存的是当前请求的响应（含 Location 头），不递归缓存跳转目标地址

验证是否按预期工作
调试时加一行头方便判断：add_header X-Cache-Status $upstream_cache_status;
用 curl -I 多次请求同一路径，观察：

• 首次返回 X-Cache-Status: MISS，状态码如 404 或 302
• 短时间内再次请求，若变为 HIT 且状态码、Location 头一致，说明缓存已生效
• 浏览器对 301 有强本地缓存，测试务必用 curl，避免干扰