缓存键混入敏感信息会导致隐私泄露，应通过日志确认实际key、哈希脱敏替代明文字段、剔除伪必要头，并验证隔离效果与收紧目录权限。
缓存键里混入敏感信息（比如明文 Cookie、完整 Authorization 头、用户 ID、手机号等），会导致缓存文件本身携带可识别身份的数据，一旦被未授权访问或通过 Range 请求泄露，就可能引发数据越权或隐私泄露。这不是缓存没生效，而是缓存“带毒”了。
确认缓存键是否实际包含敏感字段
别凭经验猜，先看 Nginx 真实生成的 key 是什么：
- 在
http块中添加日志格式：log_format cache_log '$cache_key - $upstream_cache_status';，并在对应access_log中启用它 - 发起一次带敏感头的请求（如
curl -H "Cookie: user_id=12345; session=abcde" https://example.com/api/profile），检查 access 日志里记录的$cache_key是否含12345或abcde - 临时把
proxy_cache_key设为固定值（如"debug_key"），再发不同 Cookie 的请求——若全部命中 HIT，说明原 key 确实参与了敏感字段；若仍 MISS，说明 key 未生效或配置未加载
识别哪些字段属于“不该进 key 的敏感项”
判断标准只有一个：该字段是否影响后端返回的内容？不影响，就不该进 key；影响，也应脱敏后再进。
-
明文 Cookie 或 Token 绝对禁止直接拼接：例如
$cookie_session、$http_authorization，它们长度不定、含敏感内容、且多数场景下只需区分用户而无需暴露原始值 -
推荐替代方案：用哈希提取稳定标识，如
md5($cookie_user_id)或sha256($http_authorization)前 16 位，既保留区分度又消除可读性 -
警惕“伪必要”字段：例如
X-Forwarded-For通常只用于日志或限流，不参与业务响应；Referer在 API 场景中基本不影响 JSON 输出，一律剔除
验证并收紧缓存键配置
改完之后必须验证两点：key 是否变干净了、缓存是否还能正确隔离。
- 用
curl -I发起两个仅 Cookie 不同的请求，观察X-Cache-Status是否均为MISS（说明已隔离）；再发两次相同 Cookie 的请求，确认第二次是HIT（说明隔离有效） - 在响应头中加调试信息：
add_header X-Cache-Key-Sample "$cache_key";，用curl -I直接查看 key 片段，确认无明文敏感串 - 对已知含敏感数据的路径（如
/api/user/），优先用proxy_no_cache $cookie_user_id;彻底禁用缓存，比依赖 key 更安全
配套防护不能少
光改 key 不够，还要堵住其他泄露路径：
- 确保
proxy_cache_path所在目录权限严格（如chown www-data:www-data /data/nginx/cache，chmod 700），防止本地提权读取缓存文件 - 关闭不必要的响应头：
server_tokens off;，避免Server头落入缓存文件头部（CVE-2017-7529 类风险） - 对所有需认证的接口，统一加
add_header Accept-Ranges "none";并配合more_clear_headers "Accept-Ranges";（需 headers-more 模块），阻断 Range 攻击面
