在 nginx 中通过自定义变量组合复杂的缓存键，核心做法是利用 proxy_cache_key 指令拼接多个变量。例如使用 $scheme$host$request_uri$is_args$args 可以区分协议、域名和查询参数，而加入 $http_cookie 则能实现基于用户身份的差异化缓存。这样做可以让 nginx 根据请求的具体特征生成唯一的缓存标识，从而避免不同用户或场景下的内容混淆。
如何构建包含 Cookie 的个性化缓存键
要实现基于用户身份的缓存隔离，只需将 $http_cookie 变量直接拼接到 proxy_cache_key 中。当请求携带不同的 Cookie 时，Nginx 会将其视为不同的资源并分别缓存；未携带 Cookie 的请求则共享默认缓存。这能有效解决后台管理系统或用户中心页面因登录状态不同而无法正确缓存的问题。
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;
location /api/user/profile {
# 组合协议、主机、URI 和 Cookie 作为缓存键
proxy_cache_key "$scheme$host$request_uri$http_cookie";
proxy_cache my_cache;
proxy_pass http://backend_server;
}
}
上述配置中，proxy_cache_key 使用了双引号包裹，确保变量解析正确。对于访问 /api/user/profile 的请求，如果用户 A 的 Cookie 为 user_id=1，生成的缓存键可能类似 httpexample.com/api/user/profileuser_id=1；而用户 B 的 Cookie 为 user_id=2，生成的键则为 httpexample.com/api/user/profileuser_id=2。两者在缓存目录中对应不同的文件，互不干扰。
如何处理带复杂查询参数的 API 缓存
对于包含大量查询参数的 API 接口，直接使用 $request_uri 会导致缓存碎片化。更稳妥的做法是只提取关键参数或使用 $args 配合排序逻辑（需借助 Lua 或外部模块），但在标准 Nginx 中，通常建议对特定路径使用 $uri$is_args$args 并确保参数顺序固定。若参数顺序不可控且影响结果，应结合业务逻辑在应用层处理，或在 Nginx 中使用 map 指令标准化参数。
server {
listen 80;
server_name api.example.com;
proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=30m;
location /api/search {
# 仅使用 URI 和查询字符串，忽略 Host 以节省空间（假设单域）
proxy_cache_key "$uri$is_args$args";
proxy_cache api_cache;
proxy_cache_valid 200 10m;
proxy_pass http://search_backend;
}
}
在此场景中，$uri 代表不带参数的路径部分，$is_args 在存在参数时输出 ?，否则为空，$args 包含完整的查询字符串。这种组合确保了 /api/search?keyword=a&page=1 和 /api/search?keyword=b&page=1 拥有不同的缓存键。需要注意的是，如果后端服务对参数顺序不敏感（如 ?a=1&b=2 与 ?b=2&a=1 结果相同），标准 Nginx 无法自动归一化，可能导致重复缓存。此时应考虑在应用层统一参数顺序，或使用 OpenResty 等扩展方案进行预处理。
当缓存键中包含敏感信息时会发生什么
如果在 proxy_cache_key 中直接包含 $http_cookie 或 $remote_addr 等敏感或动态性极强的变量，会导致缓存命中率急剧下降甚至缓存失效。因为每个用户的 Cookie 几乎唯一，每个 IP 的地址也各不相同，这使得缓存键变得“过于具体”，失去了共享缓存的意义。此外，将敏感数据明文存储在文件系统路径中可能存在安全风险。
