Nginx 缓存层中的请求上下文环境配置-Nginx-PHP中文网

nginx缓存上下文环境配置指http/server/location三级作用域内协同工作的变量与规则，决定缓存键生成、响应筛选、生命周期及命中判断，必须严格遵循指令作用域限制。

nginx 缓存层中的请求上下文环境配置

在 Nginx 缓存层中，“请求上下文环境配置”不是指某个独立指令，而是指缓存行为所依赖的一组上下文关联变量与作用域规则。它决定了“同一个请求是否被识别为相同缓存项”“缓存键如何生成”“哪些响应能进缓存”以及“缓存策略在哪个层级生效”。理解并正确配置这些上下文环境，是缓存命中率和数据一致性的基础。

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 报错，因为语法不合法。

缓存键是 Nginx 判断“两个请求是否应复用同一份缓存内容”的核心依据。默认值 $scheme$proxy_host$request_uri 忽略了 Host 头、Cookie、用户地区等关键维度，极易引发缓存污染或漏命。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

若需区分多域名（如 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 中不应包含动态变化却无关业务的字段（如时间戳、随机数），否则缓存永远不命中。

仅开启缓存不等于所有响应都会被存。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，直观反映当前请求在哪个上下文环节被决策。