在 nginx 中，可以通过 map 指令结合 $upstream_status 变量来区分响应状态码，并配合 proxy_cache_valid 设置不同的缓存时间。具体做法是定义一个映射规则，将 200 和 302 分别映射到不同的缓存时长标识，然后在 location 块中引用这些标识进行缓存配置。这样，nginx 会根据后端返回的状态码自动应用对应的缓存策略。
如何配置 map 指令实现状态码与缓存时间的映射
使用 map 指令可以创建一个从上游状态码到自定义缓存标签的映射表。这个映射表通常放在 http 块中，以便全局生效。通过匹配 $upstream_status 的值，可以将 200 状态码映射为长缓存标签，将 302 状态码映射为短缓存或无缓存标签。这种映射方式灵活且易于维护，不需要修改核心逻辑即可调整缓存策略。
http {
# 定义状态码到缓存时间的映射
map $upstream_status $cache_control_tag {
default no-cache;
200 "max-age=3600";
302 "no-store, no-cache";
}
server {
listen 80;
server_name example.com;
location /api/ {
proxy_pass http://backend;
proxy_cache my_cache;
# 根据映射结果设置 Cache-Control 头
add_header Cache-Control $cache_control_tag always;
# 可选：直接基于状态码设置缓存有效期
# proxy_cache_valid 200 1h;
# proxy_cache_valid 302 0s;
}
}
}
上述配置中，map 块定义了 $cache_control_tag 变量的值。当后端返回 200 时，该变量值为 max-age=3600，表示缓存 1 小时；当返回 302 时，值为 no-store, no-cache，表示不缓存。在 location 块中，通过 add_header 指令将这些值添加到响应头中。注意，always 参数确保即使错误页面也会添加此头部，但通常我们只关心成功响应。此外，也可以使用 proxy_cache_valid 指令直接指定不同状态码的缓存时间，这是一种更直接的内置方法，无需依赖 map。
proxy_cache_valid 指令的具体用法与限制
proxy_cache_valid 是 Nginx 提供的原生指令，用于直接指定不同 HTTP 状态码的缓存持续时间。它的语法简单，支持按状态码分组设置。例如，可以设置所有 2xx 和 3xx 状态码缓存 10 分钟，而 404 不缓存。然而，它不支持细粒度的单个状态码差异化配置，如让 200 缓存 1 小时而 301 缓存 5 分钟，除非使用多个指令行。对于需要精确控制每个状态码的场景，map 方案更为合适。
# 在 location 块中使用 proxy_cache_valid
location /api/ {
proxy_pass http://backend;
proxy_cache my_cache;
# 设置 200 状态码缓存 1 小时
proxy_cache_valid 200 1h;
# 设置 302 状态码缓存 0 秒（即不缓存）
proxy_cache_valid 302 0s;
# 其他状态码默认缓存 10 分钟
proxy_cache_valid 200 302 10m;
}
在上面的代码中，proxy_cache_valid 200 1h; 明确指定了 200 状态码的缓存时间为 1 小时。proxy_cache_valid 302 0s; 则指定 302 状态码不缓存。如果存在多条匹配的规则，Nginx 会按照从上到下的顺序应用第一条匹配的规则。因此，必须注意规则的顺序。此外，proxy_cache_valid 还可以接受范围，如 2xx 表示所有 200-299 的状态码。但在本例中，我们需要区分 200 和 302，所以单独列出是必要的。这种方法配置简单，适合对缓存策略要求不那么精细的场景。
当后端返回 302 重定向时，Nginx 是否缓存重定向目标 URL
当后端返回 302 状态码时，Nginx 的缓存行为取决于具体的配置。默认情况下，proxy_cache_valid 不会缓存 302 响应体，因为重定向通常不包含需要缓存的内容。但是，Nginx 可能会缓存重定向响应本身，特别是如果使用了 proxy_cache_key 并且启用了缓存。关键在于，302 响应中的 Location 头指向的目标 URL 不会被 Nginx 自动缓存，除非对该目标 URL 发起新的请求并命中缓存。因此，针对 302 的缓存设置主要影响的是重定向响应本身的存储，而不是重定向后的内容。
# 验证 302 缓存行为的测试配置
location /redirect/ {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_cache_valid 302 5m; # 缓存 302 响应 5 分钟
# 检查缓存命中情况
add_header X-Cache-Status $upstream_cache_status;
}
在上述测试配置中，设置了 302 状态码缓存 5 分钟。这意味着，如果客户端请求 /redirect/，后端返回 302，Nginx 会将这个 302 响应存入缓存。在接下来的 5 分钟内，相同的请求将直接从缓存中返回 302，而不向后端发送请求。这可以减少后端负载，但需要注意的是，如果重定向的目标 URL 发生变化，缓存的 302 响应可能指向旧的地址。因此，在实际应用中，应谨慎设置 302 的缓存时间，通常建议设置为较短的时间或不缓存，以确保重定向的准确性。
