referer白名单不是防攻击银弹，但对nginx边缘缓存是控制可信回源、防止缓存污染和盗刷的有效手段；需配合ip白名单、专用host头等机制，并仅用于内网可信链路。
Referer 白名单不是防攻击的银弹，但对 Nginx 边缘缓存而言，它是控制回源可信来源、防止恶意构造回源请求的有效手段。关键不在于“拦截所有非法 Referer”，而在于“只允许已知 CDN 节点回源”，避免缓存污染、资源盗刷或绕过鉴权逻辑。
为什么 Referer 校验在回源环节有意义
CDN 回源时，真实客户端的 Referer 通常已被中间节点覆盖或清空；但合法 CDN 节点在向源站发起回源请求时，可主动设置一个固定、可控的 Referer（如 cdn.internal），作为身份标识。源站 Nginx 通过校验该字段，能区分“真实 CDN 回源”和“直接访问源站”的请求——后者应被拒绝或降级处理（如不缓存、不返回敏感头）。
注意：Referer 可被伪造，因此该机制仅适用于内网可信链路（如 CDN 与源站之间走专线/VPC/安全组隔离），不能单独用于公网暴露接口的鉴权。
在 Nginx 中配置 Referer 白名单回源校验
在源站 Nginx 的 server 或 location 块中添加如下逻辑：
- 定义可信 Referer 列表，用 valid_referers 指令
- 用 $invalid_referer 变量判断是否匹配失败
- 对不匹配的回源请求，返回 403 或重定向到错误页，也可统一标记为不可缓存
示例配置：
valid_referers none blocked cdn.internal cdn-prod.example.com;
if ($invalid_referer) {
return 403;
}
说明：
- none 允许无 Referer 请求（如浏览器直接输入 URL）
- blocked 允许 Referer 被防火墙/代理删除的情况
- 后续域名支持通配符（*.example.com）和正则（需加 ~）
- 不建议在缓存 location 中放 if，可改用 map 提前赋值，再用 if 或 try_files 控制流程
配合其他机制提升可靠性
单靠 Referer 易被绕过，建议组合使用：
- IP 白名单：限制回源请求必须来自 CDN 提供的固定 IP 段（更硬性）
- 专用 Host 头：要求 CDN 回源时带 Host: origin.example.com，源站只响应该 Host
- 内部 Token 签名：CDN 在回源请求头中携带短期有效的签名（如 X-CDN-Sign），源站验证后放行
- 关闭源站公网访问：通过安全组、WAF 或 Nginx listen 绑定内网地址，确保只有 CDN 能触达
常见误用与排查建议
Referer 校验失效常因以下原因：
- CDN 配置未开启“回源携带 Referer”或设置了错误值（如留空或传了用户原始 Referer）
- Nginx 配置写在错误作用域（如放在 http 块而非具体 server/location）
- 忽略了 HTTPS 页面加载 HTTP 资源时 Referer 被浏览器截断的兼容行为
- 日志中未记录 $http_referer，导致无法快速确认实际收到的值
建议在 access_log 中加入 $http_referer 字段，并临时开启 debug 日志观察匹配过程。
