空 Referer 是合法访问的常见状态，需在 valid_referers 中显式包含 none 才能放行；排查应先查 Nginx 日志确认拦截请求的 Referer 字段是否为空且状态为 403，再检查配置是否遗漏 none，最后结合 IP 和协议场景细化控制。
空 Referer 不是异常，而是很多合法访问的默认状态——比如用户直接在浏览器地址栏输入图片 URL、从书签打开、HTTPS 页面引用 HTTP 资源、或某些 App/小程序发起请求时，浏览器都会主动清空 Referer。如果防盗链规则里没明确允许 none，这类请求就会被 403 拦截，看起来像“正常用户打不开图”。排查关键不是找谁删了 Referer，而是确认你的规则是否合理覆盖了这些真实场景。
第一步：确认日志里哪些请求因空 Referer 被拦
先让 Nginx 日志记录 Referer 值，看实际拦截情况：
- 修改
log_format，加入$http_referer字段（例如：'$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer"'） - 重启 Nginx，用 curl 或浏览器直接访问一张图片链接（不带任何来源页）：
curl -I https://yoursite.com/img/test.jpg - 查 access.log，找到对应请求行，看
"$http_referer"字段是否为空（显示为"-"或""）且状态码是 403
第二步：检查 valid_referers 是否包含 none
如果日志确认是空 Referer 触发拦截，马上检查防盗链配置中有没有 none：
- 正确写法示例：
valid_referers none blocked server_names *.example.com example.com; -
none表示允许 Referer 完全缺失的请求（直接访问、书签、部分微信内嵌页等） - 漏掉
none是最常见原因；只写域名白名单，等于默认拒绝所有空 Referer - 注意：不要把
none写成"none"或none;后面多加空格导致语法错误
第三步：区分“该允许”和“不该允许”的空 Referer
不是所有空 Referer 都该放行。比如 CDN 回源、爬虫、恶意脚本也可能不带 Referer。可结合来源 IP 做二次判断：
- 若你用了 CDN，回源请求通常来自固定网段（如阿里云 CDN 是
100.64.0.0/10），可在 if 判断前加 IP 条件：if ($invalid_referer && $remote_addr !~ ^100\.64\.) { return 403; } - 对真正面向用户的静态资源（如文章配图），保留
none是稳妥选择 - 对后台接口、下载链接等敏感路径，可去掉
none，强制要求合法来源
第四步：验证 HTTPS→HTTP 场景是否被误伤
浏览器在 HTTPS 页面加载 HTTP 资源时，会清空 Referer（混合内容限制）。如果你网站同时存在两种协议，需额外处理：
- 确保
blocked在 valid_referers 中——它匹配那些被剥离协议的 Referer（如//example.com） - 更彻底的办法是统一协议：所有资源用 HTTPS 加载，避免触发 Referer 清空
- 临时测试可用 curl 模拟：
curl -e "https://example.com" -I http://yoursite.com/img/a.jpg，观察是否返回 403
空 Referer 本身不可控，也不该被当成错误去修复。重点是让规则适配真实访问链路，而不是反过来要求用户必须从某页面点进来。
