404和500类状态码必须设短缓存以防雪崩、刷量和误判；404缓存应≤30秒避免假缺失，5xx缓存宜5–15秒以平衡容错与故障感知，且需满足proxy_cache_path、proxy_cache启用及无no-store/Set-Cookie等三个前提。
404 和 500 类状态码必须设短缓存，不是为了提速，而是防雪崩、防刷、防误判。它们本质是“临时性信号”，缓太久会把错误固化，掩盖真实问题。
404 缓存：控制在 30 秒内，避免假缺失
用户访问一个不存在的路径，后端返回 404。如果 Nginx 把它缓 5 分钟，期间即使该页面已上线，用户仍看到“找不到”——这就是“假 404”。更危险的是，爬虫或恶意请求反复刷这个路径，会把无效响应撑满缓存区，挤占正常资源空间。
- 推荐配置：proxy_cache_valid 404 30s; 或更保守的 15s
- 若需自定义 404 页面且希望缓存它，得先用 error_page 404 = @handle_404 拦截，再让 @handle_404 返回带 200 OK 的静态页，此时缓存的是 200，可设为 proxy_cache_valid 200 10s;
- 不建议用 any 30s 替代显式写 404 —— any 是兜底，优先级最低，容易被忽略或覆盖
500/502/503/504 缓存：统一设 5–15 秒，兼顾容错与感知
这类错误代表后端不可用（超时、崩溃、拒绝连接等）。缓太长会让用户持续看到错误页，误以为服务永久挂了；缓太短又起不到缓解压力的作用。短周期缓存的核心价值是：挡掉瞬时洪峰，给后端争取恢复时间，同时不阻断运维对故障的实时判断。
- 推荐组合：proxy_cache_valid 500 502 503 504 10s;
- 可搭配 proxy_cache_use_stale error timeout http_500 http_502; —— 当后端出错时，Nginx 可直接返回旧缓存（哪怕已过期），提升可用性
- 注意：不要单独给某个 5xx 码设长于 15 秒，比如 503 5m 容易导致服务降级被“缓存住”，用户无法及时感知恢复
关键配置前提不能漏
proxy_cache_valid 对 404 和 5xx 生效，有三个硬性条件缺一不可：
- http 块中已定义 proxy_cache_path（含 keys_zone 名称）
- 当前 location 启用了 proxy_cache（如 proxy_cache api_cache;）
- 后端响应未带 Cache-Control: no-store 或 Set-Cookie 头（否则默认不缓存，需加 proxy_ignore_headers Cache-Control Set-Cookie; 强制覆盖）
验证是否生效的小技巧
加一行头方便调试：add_header X-Cache-Status $upstream_cache_status;。用 curl 请求一个会返回 404 的路径，看响应头里是不是出现 X-Cache-Status: HIT，再隔 35 秒重试，应变成 MISS 或 EXPIRED —— 这说明 30 秒缓存逻辑走通了。
