直接在location块中为不同http状态码单独配置proxy_cache_valid指令，可精准控制缓存时长：200/206/304设1h，301设7d，302设2m，404设30s，5xx设10s，any兜底5s；须同时满足proxy_cache_path定义、proxy_cache启用及响应可缓存三项前提。

直接在 location 块里为不同 HTTP 状态码单独写 proxy_cache_valid 指令，就能精准控制各自缓存时长。它不是设一个统一时间，而是按状态码语义分层定策略——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 只管“缓存多久”，不管“是否缓存”。以下三点必须同时满足：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 在 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;
• API 路径覆盖（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