核心是禁用易伪造变量参与缓存key构造，避免攻击者通过篡改host等头污染key；应使用可信服务端注入标识（如$upstream_http_x_backend_id）、白名单校验业务头、隔离认证请求缓存空间，并显式配置缓存策略。
防范代理缓存键注入导致的任意文件覆盖，核心是不让攻击者通过伪造请求头（如 Host、自定义 header）篡改缓存 key 的生成逻辑。Nginx 本身不会“缓存 Host”，但若你在 proxy_cache_key 中直接使用 $host 或 $http_host 等变量，攻击者发一个恶意 Host 头，就能让不同域名共享同一缓存条目，最终用恶意响应覆盖合法接口的缓存内容。
禁用易伪造变量参与缓存 key 构造
这是最直接有效的防线。Nginx 缓存 key 必须基于可信、不可篡改的输入生成：
- 绝对避免在
proxy_cache_key中使用$host、$http_host、$http_user_agent、$http_referer等客户端可完全控制的变量 - 推荐使用固定上游服务标识，例如
proxy_cache_key "$scheme$request_method$upstream_http_x_backend_id$request_uri$args";，其中x_backend_id由后端或 Nginx 内部模块（如auth_request）注入，不依赖客户端输入 - 若需区分租户，应使用服务端签名校验后的 ID（如 JWT 解析出的 tenant_id），而非前端传来的
$http_x_tenant_id
白名单校验业务相关请求头
当必须依赖某些请求头（如灰度标识、语言偏好）参与缓存决策时，不能直接信任原始值：
- 对关键 header（如
X-Version、X-Region）做正则匹配或枚举校验，例如：map $http_x_version $valid_version {<br> "v1" "v1";<br> "v2" "v2";<br> default ""; # 非法值清空<br>}
再在 cache key 中使用$valid_version - 拒绝未在白名单内的自定义 header，可在
location块中用if ($http_x_tenant_id !~ ^[a-z0-9]{8,16}$) { return 400; }提前拦截
强制隔离认证类请求的缓存空间
带 Cookie 或 Authorization 的请求，天然不应共享缓存。即使 key 设计合理，也需双重保障：
- 在
proxy_cache_key中显式加入$http_cookie或$http_authorization—— 这会让每个用户生成唯一 key，避免越权缓存命中 - 对登录、用户中心等敏感路径，直接禁用缓存：
proxy_no_cache $cookie_session $http_authorization;<br>proxy_cache_bypass $cookie_session $http_authorization;
- 配合后端返回的
Cache-Control: private, no-store，并确认未配置proxy_ignore_headers Cache-Control
启用缓存策略显式控制，减少隐式行为依赖
Nginx 默认会遵循后端返回的缓存头，但这也成了攻击入口。需主动接管决策权：
- 关闭对危险响应头的默认遵从：
proxy_ignore_headers Cache-Control Expires Set-Cookie;
然后用proxy_cache_valid统一设定可信状态码的缓存时间 - 对所有非公开接口（如含
/api/v1/user/路径），强制设为不缓存：location ~ ^/api/v1/user/ { proxy_cache off; } - 定期审计缓存目录中的实际文件内容，确认无 HTML 页面或重定向响应混入敏感路径缓存
