多级网关下Referer易失效，主因是CDN/WAF/Nginx等中间层清洗、改写或丢弃该头；需逐层配置透传（如CDN开启保留、Nginx显式proxy_set_header Referer $http_referer），并辅以IP白名单、secure_link签名等兜底方案。
在多级网关环境（如 CDN → WAF → Nginx 反向代理 → 后端 Nginx）中，Referer 头常被中间层修改、截断或丢失，导致防盗链规则误判——合法请求被拦，盗链请求却绕过。核心问题不是 Nginx 配置本身，而是 Referer 在链路中能否完整、可信地透传。
为什么多级网关下 Referer 容易失效
常见破坏场景包括：
- CDN 默认清洗 Referer：部分 CDN（如阿里云全站加速、Cloudflare 免费版）为隐私或缓存策略，会清空或固定 Referer 值（如设为“-”或跳转页域名）；
-
WAF 或反向代理主动改写：某些 WAF 规则或 Nginx 的 proxy_set_header 指令未显式传递 Referer，例如写了
proxy_set_header Host $host;却漏了proxy_set_header Referer $http_referer;； - HTTPS → HTTP 跳转丢失：当用户从 HTTPS 页面请求 HTTP 资源时，浏览器出于安全限制不发送 Referer，此时即使链路完好也为空；
- 代理链路过长触发清理：RFC 7231 规定代理可选择性移除敏感头，部分企业网关会统一 strip Referer。
确保 Referer 正确透传的关键配置
需逐层检查并加固，重点在「出口侧」和「入口侧」：
- 上游网关（CDN/WAF）启用 Referer 透传：在 CDN 控制台开启「保留原始 Referer」或「透传 Referer 头」选项；WAF 中关闭「Referer 过滤」或「隐私头清洗」类规则；
-
中间 Nginx 反向代理显式转发：在 proxy_pass 所在 location 块中加入：
proxy_set_header Referer $http_referer;
若需兼容空值或特殊字符，可加判断：proxy_set_header Referer $http_referer;（$http_referer 自动为空时不发送该头，符合预期）； -
后端 Nginx 接收端不依赖默认行为：不要假设 Referer 一定存在，配置 valid_referers 时必须包含
none和blocked，例如：valid_referers none blocked *.example.com example.com;
替代方案：当 Referer 不可靠时的兜底策略
Referer 易伪造且链路难控，生产环境建议组合使用：
-
用 $remote_addr + 白名单 IP 匹配：若 CDN 提供真实客户端 IP（如通过 X-Forwarded-For 或 CDN 自定义头），可在 Nginx 中提取并校验：
set $real_ip $http_x_forwarded_for;if ($real_ip ~ "^1.2.3.4|5.6.7.8$") { set $trusted_ref "1"; }
再结合 if 判断放行； -
启用 secure_link 模块做 URL 签名：对资源链接动态添加时效性签名（如
/img/logo.png?st=xxx&e=1730391000），完全绕过 Referer 依赖； - 日志+离线分析辅助识别：记录 $http_referer、$http_user_agent、$remote_addr，用脚本定期扫描异常 Referer 频次，人工加入黑名单或调整规则。
验证 Referer 是否真正到达 Nginx
最直接的方法是临时加一条日志，确认请求头内容：
- 在 server 或 location 块中添加：
log_format debug_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';access_log /var/log/nginx/debug.log debug_log; - 用 curl 模拟不同来源请求：
curl -e "https://example.com/page.html" http://your-site.com/test.jpgcurl -e "" http://your-site.com/test.jpg
查看 debug.log 中的 Referer 字段是否与预期一致。
