valid_referers指令通过检查Referer字段实现防盗链，匹配成功则$invalid_referer为空，否则为1；需配合if判断使用，支持none、blocked、server_names及正则，但Referer机制不安全，仅作基础防护。
在 Nginx 中，valid_referers 指令用于实现图片等静态资源的防盗链，核心是通过检查 HTTP 请求头中的 Referer 字段，判断请求是否来自合法来源。配置不当容易导致误拦（自家页面打不开图）或形同虚设（盗链仍能访问），关键在于理解匹配逻辑和常见陷阱。
valid_referers 的匹配规则与常用写法
valid_referers 不是“只允许这些 referer”，而是“如果匹配成功，则将内置变量 $invalid_referer 设为空字符串；否则设为 1”。后续通常配合 if 判断该变量来拒绝或重定向请求。
-
none：匹配 Referer 为空的情况（如直接输入 URL、HTTPS 页面引用 HTTP 资源被浏览器清除 Referer） -
blocked：匹配 Referer 非空但被代理/防火墙篡改后不含协议和域名（如 "localhost" 或纯路径） -
server_names：匹配指定的域名（支持通配符*和正则~） - 可组合使用，多个条件之间是“或”关系
示例配置：
location ~* \.(jpg|jpeg|png|gif|webp)$ {
valid_referers none blocked server_names
*.example.com example.com
~\.google\.
~\.baidu\.;
<pre class="brush:php;toolbar:false;">if ($invalid_referer) {
return 403;
# 或者重定向到默认图：rewrite ^/.*$ /static/forbidden.png break;
}}
必须注意的几个实际问题
Referer 机制本身不安全，仅作基础防护，不能替代鉴权。实际部署中常见问题包括：
- HTTPS 页面加载 HTTP 图片时，现代浏览器会主动清空 Referer，导致
none必须保留 - 移动端 App、微信内嵌浏览器、某些 PWA 场景下 Referer 可能缺失或不可靠，盲目拦截会影响正常访问
- 正则匹配需转义点号：
~\.baidu\.正确，~.baidu.会错误匹配任意字符 - 通配符
*只能放在开头，如*.example.com合法，example.*无效
更稳妥的防盗链补充建议
单靠 Referer 防盗链局限明显，推荐组合策略提升实用性：
- 对重要资源启用带时间戳和签名的 URL（如
/img/abc.jpg?t=1712345678&sign=xxx），Nginx 用ngx_http_secure_link_module校验 - 限制 Referer 的同时，结合 User-Agent 简单过滤（如屏蔽已知盗链工具 UA），但不宜过度依赖
- 日志中记录
$invalid_referer和$http_referer，定期分析误拦率和真实盗链特征 - 对 CDN 回源请求，确保 CDN 在转发时透传或重写 Referer，避免因 CDN 中间层导致合法请求被拦
验证配置是否生效的小技巧
修改配置后务必测试，不要只信理论：
- 用 curl 手动模拟不同 Referer：
curl -H "Referer: https://example.com/page.html" https://yoursite.com/test.jpg - 在浏览器开发者工具中，临时编辑 HTML，用
<img src="..." alt="Nginx中图片资源防盗链Valid_referers配置" >引用你的图片，观察 Network 面板返回状态码 - 检查 Nginx error log，若出现
rewrite or internal redirection cycle，说明if + rewrite逻辑有环，应改用return或proxy_pass到内部 location
