proxy_cache_valid仅控制缓存有效期而非是否缓存，必须显式配置状态码；304响应不由其处理，需proxy_cache_revalidate配合；后端响应头优先级高于该指令，忽略时需谨慎处理私有内容。
proxy_cache_valid 不决定“要不要缓存”，只决定“缓存多久”——它对状态码的控制是精确但脆弱的，漏配一个关键码（比如 304 或 301），就可能让缓存形同虚设。
proxy_cache_valid 必须显式列出要缓存的状态码
默认情况下，Nginx 只缓存 200、301、302 响应，且仅当后端返回了可缓存的响应头（如 Cache-Control: public, max-age=60）时才生效。但如果你后端返回的是 304 Not Modified，proxy_cache_valid 完全不处理它——它只管“写入缓存”的响应，不管“验证成功”的响应。
-
proxy_cache_valid 200 302 10m：只对 200 和 302 响应设置 10 分钟有效期；301、304、404 等一律不缓存（除非额外配置） -
proxy_cache_valid 200 301 302 1h：显式包含 301，避免重定向被反复回源 -
proxy_cache_valid any 1m：兜底规则，对所有未被前面规则覆盖的状态码统一缓存 1 分钟（慎用，可能缓存错误响应） - 多个
proxy_cache_valid指令按顺序匹配，**最先匹配的那条生效**，不是取最长或最大
304 响应不走 proxy_cache_valid，靠 proxy_cache_revalidate 控制
客户端带 If-Modified-Since 或 If-None-Match 请求，后端返回 304 时，Nginx 默认不会更新缓存元数据（比如过期时间），也不会写新文件。这意味着：即使你设置了 proxy_cache_valid 200 1h，缓存内容过期后收到 304，它仍会以原过期时间继续服务，直到真正回源拿到新 200。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 加
proxy_cache_revalidate on：收到 304 后，自动延长缓存有效期至当前时间 + 原max-age（需后端返回有效Cache-Control） - 不加该指令，304 仅用于快速响应客户端，对缓存生命周期无影响
-
304本身不能被proxy_cache_valid配置——语法上不支持，配置了也忽略
容易踩的坑：后端响应头优先级高于 proxy_cache_valid
即使你写了 proxy_cache_valid 200 1h，只要后端响应里带了 Cache-Control: no-cache 或 max-age=0，Nginx 默认就不会缓存。这不是 bug，是设计行为。
- 强制覆盖：加
proxy_ignore_headers Cache-Control Expires X-Accel-Expires，让 Nginx 忽略后端的缓存指令 - 选择性忽略：只忽略
Cache-Control，保留Expires处理，用proxy_ignore_headers Cache-Control - 注意副作用：忽略
Cache-Control后，私有响应（如含Set-Cookie）也可能被缓存，必须配合proxy_cache_key加入用户标识（如$cookie_sessionid） - 测试时看
$upstream_cache_status：值为BYPASS就说明被响应头拦住了，不是配置没生效
实际配置中几个关键组合建议
真实场景下，单靠 proxy_cache_valid 不够，得和其它指令协同：
- 静态资源缓存：
proxy_cache_valid 200 206 301 302 24h; proxy_cache_valid 404 1m;（404 也缓存，防频繁探测） - API 接口缓存：
proxy_cache_valid 200 5m; proxy_cache_valid 301 1h; proxy_ignore_headers Cache-Control;（信任后端业务逻辑，不依赖其响应头） - 兼容老旧后端：
proxy_cache_valid 200 10m; proxy_cache_valid 302 30s; proxy_cache_background_update on;（短缓存 + 后台刷新，兼顾一致性与可用性） - 调试阶段必加：
add_header X-Cache-Status $upstream_cache_status;，直接在响应头看到是HIT、MISS还是BYPASS
最常被忽略的一点：proxy_cache_valid 的作用范围是“响应写入缓存那一刻”，它不干预请求是否被代理、是否被跳过（那是 proxy_cache_bypass 和 proxy_no_cache 的事），也不干预缓存键怎么算（那是 proxy_cache_key 的事）。把它当成一个纯“倒计时开关”，理解就清晰了。
