关键不是“事后擦除”，而是从缓存生成、存储和响应阶段阻断敏感内容进入路径：禁用敏感接口缓存、校验Cache-Control、隔离认证请求缓存key、清除敏感响应头、防御Range攻击、严格权限管控缓存目录。
处理 Nginx 缓存中的敏感信息，关键不是“事后擦除”，而是从缓存生成、存储和响应阶段就阻断敏感内容进入可被读取的路径。Nginx 的 proxy_cache 机制本身不主动过滤内容，但其缓存文件结构（含原始响应头+响应体）和 Range 请求处理逻辑，可能让攻击者绕过正常 HTTP 流程直接读取缓存元数据或未脱敏内容。
严格控制哪些响应能进缓存
避免缓存含用户私有数据的响应，这是最根本的防线：
- 用 proxy_no_cache 和 proxy_cache_bypass 指令，在 location 块中明确排除敏感接口：例如登录、用户资料、订单详情等动态接口，一律不缓存
- 检查后端返回的 Cache-Control 响应头，确保其包含
no-store或private；Nginx 默认会尊重这些指令，但需确认未被proxy_ignore_headers Cache-Control覆盖 - 对带认证凭证（如 Cookie、Authorization）的请求，默认禁用缓存：在 proxy_cache_key 中加入
$http_cookie或$http_authorization变量，使每个用户缓存 key 唯一且互不共享
清理缓存头部泄露风险
Nginx 缓存文件头部（前几百字节）固定包含 Magic 字符串、时间戳及完整原始响应头——这里可能暴露 Server、X-Powered-By、甚至调试头如 X-Debug-Info：
- 在 upstream 或 proxy_pass 配置中，用 proxy_hide_header 移除所有非必要响应头：
proxy_hide_header X-Powered-By; proxy_hide_header X-Debug-Info; - 全局关闭版本标识：
server_tokens off;，防止Server: nginx/1.22.1这类信息落入缓存头 - 避免使用
add_header向敏感响应注入额外头字段，尤其不要拼接请求参数或用户输入
防御 Range 请求导致的缓存头读取（CVE-2017-7529 类风险）
当攻击者发送恶意 Range 请求（如 Range: bytes=0-1024），Nginx 可能直接返回缓存文件开头部分，暴露内部结构或残留敏感头：
- 升级 Nginx 至 1.13.4 或更高版本，已修复 CVE-2017-7529 及相关整数溢出问题
- 对静态资源或公开 API，启用 proxy_buffering off 并配合
proxy_cache_valid 200 10m;等精细策略，减少大响应体缓存机会 - 若业务允许，对所有带身份上下文的 location 添加
add_header Accept-Ranges "none";，并用more_clear_headers "Accept-Ranges";（需 headers-more 模块）彻底移除该头，削弱 Range 攻击面
定期清理与权限隔离
缓存是临时存储，但生命周期管理不到位会放大风险：
- 设置合理的 proxy_cache_valid，避免长期缓存动态内容；对 5xx 响应慎用缓存（如
proxy_cache_valid 500 502 503 504 1s;） - 确保 proxy_cache_path 目录权限为
drwx------（即700），仅 nginx worker 进程可读写，防止提权后直接遍历缓存文件 - 配合 logrotate 或自定义脚本，定期清理过期缓存（
proxy_cache_purge需谨慎使用，避免误清）
