Nginx需同时满足三前提才能使proxy_cache_valid生效：http块定义cache区、location中启用proxy_cache、上游响应允许缓存（或忽略禁用头）；多条proxy_cache_valid按状态码精确匹配，后出现同码配置覆盖前值，404等错误码应设短周期（如30s）防假缓存。

直接在 location 或 server 块中写多条 proxy_cache_valid 指令，每条明确指定状态码和对应时间，Nginx 会按状态码精确匹配并生效——更具体的状态码优先于 any，后出现的同状态码配置覆盖前面的。

按业务语义分组设置合理时长

不同状态码代表不同含义，缓存周期应反映其稳定性与敏感性：

• 200 / 301 / 302：成功响应和重定向，内容通常稳定 → 推荐 proxy_cache_valid 200 301 302 10m;（301 可单独设为 7d）
• 404：资源不存在，缓存过长会导致“假 404” → 控制在 5s–60s，如 proxy_cache_valid 404 30s;
• 500 / 502 / 503 / 504：后端故障类错误，短时缓存可防雪崩 → 建议 5s–30s，例如 proxy_cache_valid 500 502 503 504 10s;
• 兜底规则：用 any 覆盖未显式声明的状态码，如 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 /path 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 Set-Cookie; 忽略）

利用作用域层级实现精细控制

Nginx 支持在不同配置块中重复使用 proxy_cache_valid，以最近的作用域为准：

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

处理易被忽略的干扰因素

常见导致缓存“看似不生效”的原因：

• 上游禁用头未忽略：后端返回 Cache-Control: no-store 时，必须加 proxy_ignore_headers Cache-Control Expires;
• Vary 头引发碎片化：如 Vary: User-Agent 会让每个 UA 生成独立缓存项，建议上游精简或 Nginx 层统一处理
• 测试方式不当：浏览器对 301 有强本地缓存，验证时请用 curl -I 并检查 X-Cache-Status: HIT