隐私模式下referer丢失是浏览器标准行为，需在nginx中显式配置valid_referers none并配合日志验证$invalid_referer状态，防盗链仅适用于静态资源，api和登录页等场景不应限制。
隐私模式下 Referer 丢失是浏览器标准行为，不是 Nginx 配置错误，但会导致防盗链误拦合法用户。排查重点不是“恢复 Referer”，而是确认 Nginx 是否已正确允许空值，并验证真实请求头状态。
看日志确认 Referer 实际值
在 Nginx 配置中加入专用日志格式，直接观察浏览器到底发了什么：
- 添加日志格式：log_format referer_log '$remote_addr - "$http_referer" $invalid_referer $request';
- 启用该日志：access_log /var/log/nginx/referer.log referer_log;
- 用隐私模式访问资源（如直接输入地址或点书签），检查日志中是否出现 "-" 1 或 "" 1 —— 这表示 Referer 为空且被判定为非法；若配置正确，应为 "-" 0，说明 $invalid_referer=0，请求未被拦截。
检查 valid_referers 是否显式包含 none
valid_referers 默认不接受空 Referer，必须手动写上 none 才能放行隐私模式、直输网址、书签访问等场景：
- 错误写法：valid_referers *.example.com example.com;（隐私模式全被拦）
- 正确写法：valid_referers none *.example.com example.com; 或 valid_referers none ~\.google\. ~\.baidu\.;
- none 必须显式写出，且建议放在最前面；漏掉它，所有空 Referer 请求都会触发 $invalid_referer = 1。
区分 blocked 和 none 的适用场景
某些情况下 Referer 并非完全为空，而是被浏览器截断成无效格式（如只有域名、无协议，或被扩展清空为字符串 "https://"）：
-
none 匹配 HTTP 头字段完全缺失或为空字符串（
Referer:或Referer:） -
blocked 匹配 Referer 存在但不可信的情况（如值为
https://、example.com、空格开头等） - 更稳妥的写法：valid_referers none blocked *.example.com;，覆盖更多边缘情况。
避免把防盗链套错位置
Referer 在很多场景下天然不可靠，硬加防盗链反而影响功能：
- 不要在 location /api/ { ... } 中限制 Referer —— API 请求常由 JS 发起，无 Referer 或来源混乱
- 不要在 location /login { ... } 中限制 —— 登录页常被收藏、分享或从邮件点击进入，依赖 none 才能打开
- 只对静态资源启用：location ~* \.(jpg|png|gif|css|js|woff2?)$ { ... }
