nginx 缓存 404 页面需拦截并改写为 200 后缓存：先定义专用缓存区，再通过 proxy_intercept_errors 和 error_page 拦截 404 并内部重定向至 @handle_404，最后在该 location 中返回可缓存的 200 响应（如静态 404.html），配合 proxy_cache_valid 200 10s 实现短时防刷。

Nginx 对错误页面（比如 404）做短期缓存，核心不是直接缓存 404 状态码本身——因为 proxy_cache_valid 404 1s 虽然语法合法，但默认情况下 Nginx 不缓存非 2xx/301/302 响应，除非你主动拦截并转换状态码。

所以真正可行的路径是：拦截后端返回的 404 → 改写为 200 → 再缓存这个 200 响应。这种方式既防刷又可控，也是生产环境推荐做法。

---

✅ 正确配置思路：拦截 + 重定向 + 缓存 200

你需要三部分协同：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

1. 定义专用缓存区（http 块内）

proxy_cache_path /var/cache/nginx/404_cache 
  levels=1:2 
  keys_zone=404_cache:10m 
  inactive=5m 
  max_size=100m 
  use_temp_path=off;

• 专用于错误页缓存，避免和主缓存混用
• inactive=5m 表示 5 分钟没被访问就自动清理，配合短周期更安全

2. 在 location 中启用拦截与内部重定向

location / {
  proxy_pass http://backend;
  proxy_intercept_errors on;   # ⚠️ 必须开启，才能捕获 404
  error_page 404 = @handle_404; # 拦截后交由内部 location 处理
}

• proxy_intercept_errors on 是关键开关，否则 error_page 不生效
• = @handle_404 表示内部重定向且状态码改为 200（不是 302 跳转）

3. 在 @handle_404 中返回可缓存的 200 页面

location @handle_404 {
  proxy_cache 404_cache;
  proxy_cache_valid 200 10s;        # 只对 200 生效 → 缓存 10 秒
  proxy_cache_use_stale updating;
  proxy_cache_lock on;

  # 方式一：静态文件（最轻量，推荐）
  root /usr/share/nginx/html;
  try_files /404.html =404;

  # 方式二：代理后端 HTML（需后端返回 200）
  # proxy_pass http://static_backend/404.html;
  # proxy_set_header Host $host;
}

• try_files /404.html =404：找不到 /404.html 就真返回 404（兜底）
• proxy_cache_valid 200 10s 是实际起作用的缓存策略，10 秒足够防刷，又不会卡太久
• proxy_cache_lock on 防止并发请求重复回源，尤其适合突发 404 场景

---

? 验证是否生效

加一行响应头方便调试：

add_header X-Cache-Status $upstream_cache_status;

请求一个不存在路径，观察响应头：

• 第一次：X-Cache-Status: MISS
• 后续 10 秒内：X-Cache-Status: HIT
• 超过 10 秒后首次：X-Cache-Status: UPDATING（锁住时）或 MISS

---

⚠️ 注意事项

• 不要依赖 proxy_cache_valid 404 1s 单独生效——它只在 Nginx 自己生成 404（如 return 404）时才可能缓存，对 proxy_pass 返回的 404 默认不缓存
• 若后端返回的是带 body 的 404（如 JSON 错误），也可用 sub_filter 替换内容+改状态码，但复杂度高，静态页方案更稳
• 确保 /var/cache/nginx/404_cache 目录存在且 Nginx 进程有读写权限

不复杂但容易忽略