不能严格禁止空 Referer，因其涵盖大量合法场景如直接输入URL、App内嵌浏览器、隐私模式等；Nginx的valid_referers none正是为兼容此类行为而设计；真正有效的防护应采用secure_link签名验证或反向代理鉴权。
不能直接“严格禁止空 Referer”——因为这会误拦大量合法访问，比如用户直接输入图片 URL、书签打开、微信/QQ 内置浏览器、部分隐私模式或某些 PWA 场景。Nginx 的 valid_referers none 本意就是**允许空 Referer**，这是设计使然，也是兼容性刚需。
为什么空 Referer 无法也不应被“严格禁止”
空 Referer 不代表盗链，而是缺乏来源上下文的正常行为：
- 用户在浏览器地址栏直接输入图片链接（如
https://example.com/img/product-abc.jpg）→ Referer 为空 - 从 HTTPS 页面跳转到 HTTP 资源（或跨协议）→ 浏览器主动清空 Referer
- 微信、钉钉、飞书等 App 内置 WebView 加载图片 → 多数不携带 Referer
- 用户启用“禁止发送 Referer”扩展或开启严格隐私模式 → Referer 被主动剥离
真正保护核心商业图片的替代方案
放弃“堵 Referer”，转向更可控、更精准的防护机制：
-
启用 secure_link 模块做时间+签名验证：为每张商业图生成带过期时间与 HMAC 签名的临时 URL（如
/img/abc.jpg?st=xxx&e=1722300000），Nginx 校验签名与有效期，非法或过期链接立即 403。这是目前最可靠的一线防护。 -
将核心图片放在非公开路径 + 反向代理鉴权：图片不放静态目录，而存于
/data/private-images/等 Webroot 外路径；通过 location 转发至内部鉴权服务（如 Lua 脚本或轻量 API），检查 session、JWT 或 referer+UA 组合策略后再响应文件。 -
Referer 白名单 + 非空强制（有条件启用）：若业务场景明确要求“必须来自站内页面”，可移除
none，仅保留blocked和可信域名：valid_referers blocked example.com *.example.com app.example.com;
注意：此举需同步确保所有前端入口（含 H5、小程序 WebView、管理后台）都使用标准 a 标签跳转或 fetch 带 referrerPolicy，否则自身页面也会失效。
配置示例（推荐组合用法）
对 /img/private/ 下的高价值图片启用签名验证：
location ^~ /img/private/ {
secure_link $arg_st,$arg_e;
secure_link_md5 "your-secret-key$uri$arg_e";
<pre class="brush:php;toolbar:false;">if ($secure_link = "") { return 403; }
if ($secure_link = "0") { return 410; } # 过期
alias /data/private-images/;}
这样，即使盗链者拿到 URL，过期后自动失效；伪造签名几乎不可行；空 Referer 完全不影响合法带参链接访问。
Referer 防盗链是辅助手段，不是防线核心。保护商业图片，靠的是可控分发，而不是依赖一个可轻易绕过的 HTTP 头。
