Nginx 中如何运用 proxy_cache_valid 细分缓存时间

proxy_cache_valid 按状态码分组设置可精细化控制缓存时长，但需配合缓存区定义、启用缓存及确保响应可缓存三条件；匹配按顺序优先，后写覆盖前写，建议高优先级规则置前，并辅以 proxy_cache_use_stale、proxy_intercept_errors 等提升稳定性。

直接用 proxy_cache_valid 按状态码分组写，就能实现缓存时间的精细化控制。它不是“开关”，而是“计时器”——只管缓存多久，不管要不要缓存；要真正生效，还得配齐缓存区、启用缓存、确保响应可缓存。

按状态码显式分组设置

把语义相近或运维需求一致的状态码归为一组，每组单独指定时间：

• proxy_cache_valid 200 206 304 1h; → 正常响应和协商成功，内容稳定，适合长缓存
• proxy_cache_valid 301 7d; → 永久重定向，语义承诺长期有效，可放心缓存一周
• proxy_cache_valid 302 2m; → 临时重定向必须短缓存，避免用户错过上游变更
• proxy_cache_valid 404 30s; → 防恶意探测，缓存“不存在”结果几十秒足够，太长会掩盖新资源上线
• proxy_cache_valid 500 502 503 504 10s; → 后端故障类错误短时缓存，缓解雪崩，但不宜超过 1 分钟

注意匹配顺序和优先级

Nginx 从上到下逐行匹配，一旦命中就停止检查。所以更具体的规则建议放在前面：

• 写 proxy_cache_valid 301 7d; 和 proxy_cache_valid 302 2m; 是安全的，不会互相干扰
• 避免把 proxy_cache_valid any 1m; 放在最前——它会提前截断所有更精确的规则
• 同一状态码出现多次时，后写的会覆盖前面的（比如先写 200 10m，后面又写 200 5m，最终生效的是 5 分钟）

让配置真正起作用的三个硬性条件

缺一不可，否则 proxy_cache_valid 再精细也无效：

• 在 http 块中定义缓存区：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;
• 在 location 或 server 块中启用：proxy_cache my_cache;
• 确保上游响应本身可缓存：默认不缓存带 Set-Cookie、Cache-Control: private/no-store 的响应；若需强制缓存，加 proxy_ignore_headers Set-Cookie Cache-Control;

配合其他指令提升稳定性

单靠 proxy_cache_valid 不足以应对复杂场景：

• 加 proxy_cache_use_stale error timeout http_404;：缓存过期时，若后端又挂了，仍可返回旧的 404 或错误页，提升可用性
• 加 proxy_intercept_errors on; + error_page 404 = @custom_404;：把大体积 HTML 错误页换成轻量静态文件，再配缓存，更省资源
• 调试时加 add_header X-Cache-Status $upstream_cache_status;：响应头里能看到 HIT/MISS/EXPIRED，直观验证是否按预期工作