Nginx缓存上下文环境配置指http/server/location三级作用域内协同工作的变量与规则，决定缓存键生成、响应筛选、生命周期及命中判断，必须严格遵循指令作用域限制。
在 Nginx 缓存层中，“请求上下文环境配置”不是指某个独立指令，而是指缓存行为所依赖的一组上下文关联变量与作用域规则。它决定了“同一个请求是否被识别为相同缓存项”“缓存键如何生成”“哪些响应能进缓存”以及“缓存策略在哪个层级生效”。理解并正确配置这些上下文环境，是缓存命中率和数据一致性的基础。
缓存上下文必须落在 http/server/location 三级作用域内
Nginx 缓存相关指令有严格的上下文限制，不能随意嵌套：
-
proxy_cache_path 只能在
http块中定义——它声明缓存物理路径、共享内存区（keys_zone）、层级结构和过期策略，是整个缓存系统的“地基”。 -
proxy_cache 可在
http、server或location中启用——实际开启缓存的开关，决定该作用域下所有请求是否走缓存流程。 - proxy_cache_key 和 proxy_cache_valid 同样支持 http/server/location ——但它们的值会按“最内层生效”原则覆盖，比如 location 中定义的 key 会覆盖 server 中同名配置。
- 错误示例：
proxy_cache写在 events 块或 upstream 块里会直接导致 nginx -t 报错，因为语法不合法。
缓存键（proxy_cache_key）决定请求是否“算同一个”
缓存键是 Nginx 判断“两个请求是否应复用同一份缓存内容”的核心依据。默认值 $scheme$proxy_host$request_uri 忽略了 Host 头、Cookie、用户地区等关键维度，极易引发缓存污染或漏命。
- 若需区分多域名（如 www.example.com 和 api.example.com），应在 key 中显式包含
$host； - 若后端依赖 Cookie（如登录态、购物车），可加入
$cookie_sessionid或$cookie_user，避免用户 A 看到用户 B 的缓存页； - 若接口带分页参数
?page=2，$request_uri已含查询串，但若用了重写（如 /list/2），则需用$uri$is_args$args组合确保一致性； - 注意：key 中不应包含动态变化却无关业务的字段（如时间戳、随机数），否则缓存永远不命中。
响应筛选（proxy_cache_valid）控制“什么内容值得缓存”
仅开启缓存不等于所有响应都会被存。Nginx 默认只缓存 GET/HEAD 请求的 200、301、302 等成功响应，且必须显式配置 proxy_cache_valid 才真正生效。
- 必须为至少一类状态码指定时间，例如
proxy_cache_valid 200 302 10m;，否则即使响应头允许缓存，Nginx 也不会存； - 可用
any覆盖兜底，如proxy_cache_valid any 1m;，但慎用于 5xx 或重定向，可能掩盖后端故障； - 若后端返回了
Cache-Control: no-cache或Set-Cookie，Nginx 默认跳过缓存——可通过proxy_ignore_headers显式忽略，但需确认业务无副作用。
缓存生命周期与刷新机制依赖上下文联动
缓存不是“写入即永久有效”，其存活由多个上下文参数协同控制：
-
inactive=3h（在 proxy_cache_path 中）表示：缓存项若 3 小时内未被再次访问，就自动清理，不管是否过期； -
proxy_cache_valid定义的是“首次缓存后最长保留时间”，即 TTL； -
proxy_cache_background_update on允许在缓存即将过期时，后台静默回源更新，同时仍把旧缓存返回给客户端——这个能力必须在启用缓存的 location 中配置才起作用； - 调试时可在响应头加
add_header X-Cache-Status $upstream_cache_status;，值为 HIT/MISS/EXPIRED/BYPASS，直观反映当前请求在哪个上下文环节被决策。
