空 Referer 是正常行为，需在 valid_referers 中显式添加 none；检查 Nginx 日志中 $http_referer 是否为 "-"，用 awk 筛选 403 且 Referer 为空的请求；注意反向代理时 Referer 透传或主动注入。
直接查 Nginx 日志，看请求里 $http_referer 字段是否为空，再结合用户访问场景判断是否合理——空 Referer 本身不是错误，而是浏览器正常行为，关键在你的规则有没有为它留出口。
先确认是不是真“没发”，而不是“被拦了”
浏览器地址栏输入网址、点击书签、微信内嵌页、App 内打开网页、HTTPS 页面跳转 HTTP 外链等场景下，Referer 天然为空。这不是异常，是规范行为（strict-origin-when-cross-origin 或更严策略所致）。别一看到 403 就怀疑客户端有问题，先看日志原始记录：
- 用
grep -v "yourdomain.com" /var/log/nginx/access.log | head -20找非本站来源的请求，观察$http_referer列值是否为空或缺失 - 重点筛静态资源路径（如
.jpg、.css），命令示例：awk '$9==403 && $11 ~ /^"-"$/{print}' /var/log/nginx/access.log（匹配状态码 403 且第 11 列 Referer 为 "-"） - 注意：Nginx 日志中 Referer 为空时通常记为
"-"，不是空字符串
检查防盗链配置是否漏掉 none
如果 valid_referers 指令里没写 none，Nginx 就会把所有空 Referer 请求判为非法，触发 $invalid_referer = 1。这是最常见的误伤原因：
- 错误写法：
valid_referers www.example.com *.example.com;→ 直接访问https://example.com/logo.png就会 403 - 正确写法：
valid_referers none blocked www.example.com *.example.com;→ 明确放行空 Referer 场景 -
blocked也建议保留，它覆盖防火墙/代理截断后只剩域名、无协议的异常 Referer，移动端和部分内嵌 WebView 常见
用真实方式模拟验证是否生效
别只信 curl 默认行为，要贴近终端用户实际触发条件：
- 在浏览器地址栏直接输入图片或 CSS 的 URL（如
https://yoursite.com/style.css），看能否返回 200 和内容 - 用 curl 模拟空 Referer：
curl -I -H "Referer:" https://yoursite.com/icon.svg，响应头应含200 OK，不是403 - 从微信聊天窗口粘贴链接打开页面，再检查页面内资源加载是否报 403（微信 WebView 默认不发 Referer）
留意反向代理带来的二次丢失
如果你用了 Nginx 做反代，而被代理的后端服务自己也做 Referer 校验，那问题可能出在代理层没透传或重写：
- 默认
proxy_set_header Referer $http_referer;会把空 Referer 传过去，若后端只认https://your.com，就会拦截 - 此时需主动注入：
proxy_set_header Referer "https://your.com";（注意引号和协议），并确保放在proxy_pass之前 - 同时检查后端是否要求 Referer 必须带路径（如
https://your.com/），那就补上斜杠
