在 nginx 中设置几分钟或几小时的短期缓存，核心做法是在 proxy_cache_valid 指令中指定具体的时间单位（如 m 代表分钟，h 代表小时）以及对应的 http 状态码。例如，配置 proxy_cache_valid 200 30m; 即可让成功请求的响应缓存 30 分钟。这一设置直接作用于已开启缓存的 location 块内，nginx 会根据返回的状态码匹配相应的时间策略，从而决定缓存对象的过期时长。
如何为不同状态码设置差异化的缓存时长
针对不同的 HTTP 响应状态码，可以分别指定独立的缓存有效期，以实现更精细的控制。默认情况下，如果未指定状态码，Nginx 会对所有非错误状态码应用相同的缓存规则，但显式声明能避免歧义。例如，可以将成功的 200 和 301 响应缓存较长时间，而将 404 错误缓存较短时间以减少重复查询。这种差异化配置允许开发者根据数据的重要性及更新频率，灵活调整缓存生命周期。
server {
listen 80;
server_name example.com;
# 定义缓存路径、密钥和大小
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
location /api/ {
proxy_pass http://backend_server;
proxy_cache my_cache;
# 200 OK 和 301 Moved 缓存 1 小时
proxy_cache_valid 200 301 1h;
# 404 Not Found 缓存 5 分钟
proxy_cache_valid 404 5m;
# 其他所有状态码缓存 10 分钟
proxy_cache_valid any 10m;
add_header X-Cache-Status $upstream_cache_status;
}
}
上述配置中，proxy_cache_valid 指令按顺序生效。当后端返回 200 时，匹配第一行规则，缓存 1 小时；若返回 404，则匹配第二行，仅缓存 5 分钟；若是其他状态，则落入第三行的 any 规则，缓存 10 分钟。通过 $upstream_cache_status 变量，可以在响应头中查看当前请求是否命中缓存（HIT）或未命中（MISS），便于验证配置效果。
短期缓存对并发请求和回源的影响
设置短期缓存（如几分钟）的主要目的是平衡服务器负载与数据实时性。当多个客户端同时请求同一资源且缓存未命中时，Nginx 会向后端发起一次代理请求，并将结果缓存。在缓存有效期内，后续请求直接由 Nginx 返回，无需再次连接后端。然而，如果缓存时间过短，可能导致频繁的“缓存穿透”或高并发下的回源压力，因为缓存对象很快失效。反之，合理的短期缓存能有效吸收突发流量，减轻后端数据库或应用服务器的负担。
# 测试脚本：模拟连续请求并观察缓存状态
for i in {1..10}; do
curl -s -o /dev/null -w "Request $i: %{http_code}, Cache: %{time_total}s\n" \
-D - http://example.com/api/data | grep X-Cache-Status
done
在实际测试中，可以通过循环发送请求来观察 X-Cache-Status 的变化。第一次请求通常为 MISS，随后几次请求在缓存有效期内会显示为 HIT。一旦超过设定的缓存时间（如 5 分钟），下一个请求将再次变为 MISS，并重新从后端获取数据。这种机制确保了数据的相对新鲜度，同时避免了每次请求都穿透到后端。开发者应根据业务场景的数据更新频率，选择合适的缓存时长，既保证性能，又不牺牲数据的及时性。
基于 proxy_cache_valid 中 any 关键字的具体行为问题
在 proxy_cache_valid 指令中使用 any 关键字时，它代表除了前面明确列出的状态码之外的所有其他状态码。这是一个兜底规则，确保所有响应都有明确的缓存策略。如果省略了 any，且没有默认的全局缓存设置，某些非标准状态码可能不会被缓存，或者遵循 Nginx 的默认行为（通常是不缓存）。因此，显式定义 any 的缓存时长是最佳实践，可以避免因后端返回意外状态码而导致缓存策略失效。
