应排查缓存键是否隐含敏感信息，重点验证用户身份、认证凭据等是否直接拼入键中，通过日志记录原始输入并检查token、cookie等是否明文出现，发现即需移除或脱敏。
排查缓存键中是否隐含敏感信息，关键不是检查“键长”或“看起来像不像”，而是验证该键是否把本不该公开的用户身份、认证凭据、调试参数等直接拼进缓存文件名——而这些内容一旦落入缓存路径，就可能被日志记录、监控采集、甚至在错误配置下被意外暴露。
确认敏感字段是否实际参与了缓存键计算
不要只看 proxy_cache_key 配置行，要验证它真实生成的值：
- 临时加一行日志：在 location 块中配置 log_format cache_key '$scheme$request_method$host$request_uri $cookie_token $http_authorization';，再用 access_log /var/log/nginx/cache-key.log cache_key; 记录原始输入
- 发起一个带 Token 的请求（如
curl -H "Authorization: Bearer abc123" https://api.example.com/profile），检查日志中是否出现明文 Token 或 Cookie 值 - 若出现，说明该字段已进入键生成链路——而 Nginx 缓存文件名是键的 MD5 哈希，但日志、监控、调试工具可能直接打印原始键字符串，造成泄露
识别哪些字段属于高危敏感变量
以下变量一旦出现在 proxy_cache_key 中，即构成明确风险，应立即移除或脱敏：
- $cookie_*（如 $cookie_session、$cookie_auth）：会把 Base64 或明文凭证写入键字符串
- $http_authorization：直接携带 Bearer Token 或 Basic 凭据，极易被日志捕获
- $args 或未过滤的 $query_string：可能含 ?token=xxx、?code=yyy 等一次性凭证
- $http_x_api_key、$http_x_user_id 等自定义头：若未做白名单校验，攻击者可伪造注入
用最小化键验证并替换为安全替代方案
快速验证当前键是否过度携带敏感信息：
- 临时将键简化为 proxy_cache_key "$scheme$request_method$host$request_uri";，观察命中率是否异常飙升——若明显上升，说明原键混入了不稳定/敏感字段，导致缓存碎片化，反而掩盖了污染问题
- 对需用户隔离的接口，不直接塞 Token，改用服务端可控标识：proxy_cache_key "$scheme$host$request_uri $upstream_http_x_user_hash";（其中 x_user_hash 由后端或 auth_request 模块生成的固定哈希）
- 若必须区分用户，优先使用 $cookie_token 但配合 proxy_hide_header Set-Cookie; 和 proxy_ignore_headers Set-Cookie;，防止后端响应头泄露凭证
检查缓存文件系统与日志是否已暴露敏感痕迹
缓存键影响的不只是内存或逻辑，还有磁盘上的真实文件路径和日志内容：
- 进入 proxy_cache_path 定义的目录（如
/data/nginx/cache），执行find . -name "*abc123*" -o -name "*Bearer*"，搜索是否已有含敏感字符串的缓存文件名 - 检查 access_log 和 error_log 中是否记录了完整缓存键（尤其当使用自定义 log_format 包含 $cache_key 变量时）
- 确认所有日志路径权限为 640，属主为 nginx 用户，且无 world-readable 权限
