最清晰做法是为每类状态码单独配置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，是最清晰、最可控的做法。它不看后端返回的 Cache-Control，只由 Nginx 主动决定“这个状态码的响应能缓存多久”。

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

不同状态码代表不同业务含义，缓存时间必须匹配其稳定性与敏感性：

• 200 / 206 / 304：正常响应、范围请求、协商成功，内容稳定 → 推荐 proxy_cache_valid 200 206 304 1h;
• 301：永久重定向，语义承诺长期有效 → 单独设 proxy_cache_valid 301 7d;
• 302：临时跳转，可能随时变更 → 必须设短，如 proxy_cache_valid 302 2m;
• 404：资源不存在，缓存过长会掩盖新上线路径 → 控制在 30 秒内，如 proxy_cache_valid 404 30s;
• 5xx 错误（500/502/503/504）：后端临时故障，短时缓存可缓解雪崩 → 推荐 proxy_cache_valid 500 502 503 504 10s;
• any：兜底规则，覆盖未显式声明的状态码（如 403、429），但不覆盖已定义的 → 加一句 proxy_cache_valid any 5s;

确保缓存真正生效的三个前提

只配 proxy_cache_valid 不起作用，以下三项必须同时满足：

Umbrel Proxy Manager

高效管理与交互 Umbrel 代理服务，支持 Docker 容器。自动发现运行服务，将内部 Docker IP 映射为可访问的外部地址。

下载

• 在 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: no-cache 或 private 的响应；必要时加 proxy_ignore_headers Set-Cookie Cache-Control;

利用作用域层级做精细控制

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 多次请求同一 URL，观察响应头中 X-Cache-Status 是否出现 HIT（命中）、MISS（未命中）或 EXPIRED（过期）
• 测试 301/302 时优先用 curl，避免浏览器本地强缓存干扰