HTML主文档请求时Referer为空、Origin为null，故Nginx的valid_referers仅对img/script等子资源有效，无法作用于HTML本身；其校验逻辑由服务器执行，前端只能配合（如referrerpolicy）或绕过。
HTML 本身无法“管理”防盗链，它只是被动发起请求的一方；真正起作用的是服务器对 Referer 头的校验逻辑。前端能做的只有配合或绕过，而不是控制。
为什么给 HTML 加 valid_referers 没用？
Nginx 的 valid_referers 指令只在 location 块中生效，且仅对被 HTML 引用的子资源（如 img、script、link 标签加载的 .jpg/.js/.css）起作用。HTML 主文档本身请求时 Referer 为空，Origin 为 null，服务器根本不会（也不该）用 Referer 规则拦截 GET /index.html 这类请求。
常见误操作：
- 在
location /或location = /index.html中写if ($invalid_referer) { return 403; }→ 导致搜索引擎爬虫、微信内嵌页、PWA 启动失败 - 把
favicon.ico或robots.txt一并纳入防盗链规则 → 日志刷屏、SEO 受损 - 白名单漏掉
none→ 用户直接输入图片 URL 或从 HTTPS 页面跳转到 HTTP 图片时，因浏览器清空Referer而被误拦
前端怎么让防盗链图片正常显示？
当你要引用第三方带防盗链的图片（比如 Unsplash、某图床），而对方服务器只允许空 Referer 或特定域名时，前端可主动控制发送行为：
立即学习“前端免费学习笔记（深入）”；
- 在
<head>中加：<meta name="referrer" content="no-referrer">→ 所有子资源请求都不带Referer头，适用于多数图床 - 对单个
<img>标签加referrerpolicy="no-referrer"→ 更精细，不影响其他请求：<img src="https://cdn.example.com/photo.jpg" referrerpolicy="no-referrer"> - 避免混用协议：HTTPS 页面加载 HTTP 图片时，现代浏览器会主动清除
Referer，导致合法请求也被拦；统一用 HTTPS
Nginx 配置防盗链时最容易错的三件事
如果你是资源提供方（即自己托管图片），Nginx 防盗链配置必须聚焦静态资源路径，而非 HTML 入口：
-
location正则要精确：用location ~* \.(png|jpe?g|gif|webp|svg|woff2?)$，别写成location ~* \..*$→ 否则可能误杀/api/v1/user这类接口 - 白名单必须含
none和blocked：valid_referers none blocked yoursite.com *.yoursite.com;→ 否则微信内嵌页、书签访问、隐私模式用户全挂 - 不要在
server级别写if→ Nginx 官方明确不建议，高并发下性能差且易出错；所有if必须包裹在具体location内
真正难处理的不是技术配置，而是业务边界：你无法靠 Referer 区分“合法用户”和“盗链脚本”，只要对方伪造一个合法 Referer 就能绕过。需要强保护时，得换 Token 签名或独立子域 + CORS + 后端鉴权——那已经不是 HTML 或 Nginx 单层能解决的事了。
