通过 nginx 的 proxy_cache_key 指令，使用变量组合请求头（如 $http_authorization）与 url 路径来生成缓存键。这样可以将不同用户的权限状态直接映射到不同的缓存文件上，确保只有拥有正确凭证的请求才能命中对应的缓存数据。
如何配置 proxy_cache_key 以包含 Authorization 头
在 location 块中设置 proxy_cache_key，将 $uri 与 $http_authorization 拼接。Nginx 会自动对生成的字符串进行哈希处理作为文件名。如果用户未登录或 Token 无效，该变量值为空或特定格式，从而产生独立的缓存条目。
server {
listen 80;
server_name example.com;
# 定义缓存路径和参数
proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
location /api/data {
# 核心配置：缓存键包含 URI 和 Authorization 头
proxy_cache_key "$uri|$http_authorization";
proxy_cache my_cache;
proxy_cache_valid 200 10m;
# 转发请求到后端
proxy_pass http://backend_server;
proxy_set_header Host $host;
}
}
预期结果：当 Authorization: Bearer token_A 访问 /api/data 时，Nginx 计算哈希值并查找缓存；若存在则返回缓存内容。当 Authorization: Bearer token_B 访问同一 URL 时，因键不同，Nginx 向后端发起新请求并生成新的缓存文件。
如何处理 Cookie 鉴权场景下的缓存键设计
对于基于 Session Cookie 的系统，同样可以使用 $http_cookie 变量。但需注意 Cookie 通常包含大量数据，可能导致缓存键过长。建议提取关键的 Session ID 部分，或使用正则表达式截取，以避免缓存目录层级过深或哈希冲突。
# 假设从 Cookie 中提取 session_id
set $session_id "";
if ($http_cookie ~* "(?:^|; )session_id=(?<id>[^;]*)") {
set $session_id $id;
}
# 在 location 中使用截取的 ID
location /api/user_info {
proxy_cache_key "$uri|$session_id";
proxy_cache my_cache;
proxy_pass http://backend_server;
}</id>
预期结果：仅当 session_id 相同时才共享缓存。这比存储完整 Cookie 更节省磁盘空间，同时保证了会话隔离的安全性。
当 Authorization 头为空时缓存行为会怎样
当请求头中不包含 Authorization 字段时，$http_authorization 变量的值为空字符串。此时缓存键变为 $uri|。这意味着所有未携带认证信息的请求都会共享同一个缓存键，即“匿名缓存”。如果后端对匿名用户和已登录用户返回相同的内容（例如公开接口），这种设计是有效的；但如果后端根据是否有 Auth 头返回不同内容（如 401 vs 200），则需确保缓存策略能区分这些状态码，或者在后端设置 Vary: Authorization 响应头来辅助 Nginx 判断。
