nginx作为cdn源站时，referer校验需依赖cdn透传（首选x-original-referer头）、限定静态资源路径、组合cdn ip白名单与合法域名，并明确referer仅用于防盗链而非安全认证。
当 Nginx 作为源站被第三方 CDN 代理时，Referer 的透传与校验不能简单沿用直连场景的逻辑。核心矛盾在于：CDN 节点发起回源请求时，其自身是请求方，原始浏览器 Referer 已经“丢失一层”，若 CDN 不主动透传，源站将无法获知真实来源页面。
CDN 必须显式透传真实 Referer（关键前提）
绝大多数主流 CDN（如 Cloudflare、阿里云 DCDN、腾讯云 CDN、又拍云等）默认会原样转发客户端请求中的 Referer 头，但存在例外：
- 部分 CDN 在开启“隐私优化”或“Referrer Policy 强制策略”后，会主动改写或清空 Referer（尤其 HTTPS→HTTP 或跨域跳转时）
- 某些轻量 CDN 或自建边缘节点未配置透传逻辑，回源请求中 Referer 变为自身域名（如
Referer: https://cdn.example.net） - CDN 控制台需确认「透传原始请求头」或「保留 Referer」选项已启用；阿里云 CDN 可在“回源配置”中勾选“透传 Referer”，腾讯云需在“访问控制 → 回源请求头”添加
Referer字段
Nginx 源站应信任 CDN 透传的 Referer，而非直接读 $http_referer
若 CDN 已正确透传，它通常会把原始 Referer 放在标准 Referer 请求头中，此时 Nginx 可直接使用 $http_referer 进行校验——但前提是确认该头确实来自 CDN 且未被污染。
更稳妥的做法是：要求 CDN 将原始 Referer 写入一个专用头（如 X-Original-Referer），并在 Nginx 中优先读取该头：
- 在 CDN 后台配置回源请求头：
X-Original-Referer → $http_referer（或对应变量） - Nginx 配置中用
$http_x_original_referer替代$http_referer做校验 - 这样可完全规避 CDN 自身 Referer 对
$http_referer的覆盖风险
校验逻辑需适配 CDN 回源特征，避免误拦
直接套用 valid_referers server_names 很可能失败，因为：
- 真实 Referer 是用户所在站点（如
https://blog.com/article），不是你的域名 - CDN 回源 IP 是固定出口段，可结合 IP 白名单 + Referer 组合判断
- 推荐做法：仅对静态资源路径（如
location ~* \.(jpg|png|js|css)$）启用 Referer 校验，并允许 CDN 自身域名 + 空 Referer + 合法业务域名
示例配置：
location ~* \.(jpg|jpeg|png|gif|webp|css|js)$ {
# 允许：无 Referer（直接访问）、CDN 回源地址、合法业务域名
valid_referers none
blocked
*.yourdomain.com
yourdomain.com
cdn-provider.com; # CDN 官方域名，如 cloudflare.com
if ($invalid_referer) {
return 403;
}
}注意 Referer 的固有局限，不单独依赖它做安全控制
Referer 本质是浏览器提供的线索，不是认证凭证：
- 可被 curl、Postman、爬虫任意伪造
- HTTPS 页面加载 HTTP 资源时，浏览器按 Referrer Policy 默认清空 Referer
- 小程序、App、内嵌 WebView 等客户端常不携带 Referer
因此，它只适合用于过滤明显盗链流量，不可替代 token 验证、签名鉴权或 IP 白名单等强手段。若业务敏感，建议 CDN 层配合 secure_link 或动态 token 回源校验。
