Nginx Referer防护核心是校验而非单纯转发：先用valid_referers白名单校验来源，$invalid_referer为真时拦截（如return 403）；需配合proxy_set_header安全重写Referer值、Referrer-Policy控制出向泄露，并明确其仅作初级过滤，不可替代Token等强认证。
Referer 防护转发不是“把 Referer 转发出去”，而是**在转发请求前，先校验来源是否可信，再决定是否放行或改写 Referer 头**。Nginx 本身不主动“转发”Referer，它默认会透传上游请求头；真正需要做的是：拦截非法 Referer、清理敏感信息、或按策略重写 Referer 值，避免泄露内部路径或参数。
一、禁止非法 Referer 访问（基础防护）
适用于静态资源（图片/CSS/JS）或管理后台接口，防止盗链和跨站调用：
- 在
location块中使用valid_referers定义白名单，必须包含none（允许直接访问）和blocked（允许被代理截断的 Referer） - 配合
if ($invalid_referer)返回 403 或重定向到默认图 - 示例配置：
valid_referers none blocked *.yourdomain.com yourdomain.com;
if ($invalid_referer) {
return 403;
}
}
二、安全地透传 Referer（控制内容而非简单转发）
当后端服务需依赖 Referer 做业务判断（如来源统计、权限跳转），但又不能暴露原始敏感 URL 时，应主动重写 Referer：
- 用
proxy_set_header Referer替换为简化值，例如只保留域名 - 避免直接透传原始
$http_referer，尤其当上游 Referer 含有 token、用户 ID、搜索关键词等 - 示例（仅透传协议+主域名）：
if ($http_referer ~* ^https?://([^/]+)) {
set $safe_referer "https://$1";
}
proxy_set_header Referer $safe_referer;
三、配合 Referrer-Policy 做响应级防护
Referer 校验是“进向防护”，而 Referrer-Policy 是“出向防护”——控制本站在跳转到第三方时发送多少 Referer 信息：
- 对含敏感参数的页面（如
/login?token=xxx），推荐设为no-referrer-when-downgrade或strict-origin-when-cross-origin - 统一加在
server或location块中：
注意：always 参数确保 30x 重定向响应也带上该头，避免策略丢失。
四、绕过风险与关键提醒
Referer 可被客户端轻易伪造，因此所有基于它的防护都只是第一道过滤层：
- 不要单独用 Referer 校验保护核心 API（如支付回调、用户删除），必须叠加签名、Token 或 IP 白名单
- 单页应用（SPA）、小程序、App 调用通常不带 Referer，盲目启用会导致功能中断
- HTTPS 页面加载 HTTP 资源时，浏览器会清空 Referer，若混合协议存在，需额外兼容
- CDN 或反向代理可能修改或剥离 Referer，配置前需确认真实请求头到达 Nginx 时的状态
