HTTPS下Nginx防盗链需解决Referer可信性断层：因跨协议跳转、微信等客户端、window.open等场景导致Referer为空或不可靠，必须白名单none和blocked；按资源分级控制，图片可宽松，敏感资源需叠加token；避免直接403，宜返回提示图或1×1透明GIF。
HTTPS 环境下配置 Nginx 防盗链，核心不是“加个 valid_referers 就完事”，而是解决 Referer 在加密场景下的可信性断层问题。HTTPS 页面向 HTTP 资源发起请求时，浏览器会主动清空 Referer；跨协议、跨域、某些移动端 WebView（如微信内置浏览器）甚至会屏蔽或伪造 Referer。直接套用 HTTP 下的防盗链规则，极易导致合法用户 403，比如小程序页面、H5 分享页、邮件客户端内嵌页全部打不开图片。
明确 Referer 在 HTTPS 中的失效边界
不是所有 HTTPS 请求都带可信 Referer。以下情况 Referer 为空或不可靠，必须提前纳入白名单：
- 用户从 HTTPS 页面跳转到 HTTP 资源（浏览器出于安全策略丢弃 Referer）
- 点击邮件客户端、IM 工具（如微信、钉钉）中的链接打开网页，Referer 常被截断或设为 null
- 使用 window.open() 或 target="_blank" 打开新页，且目标页与来源页协议/域名不一致
- 部分隐私模式或浏览器扩展主动清除 Referer 头
配置中必须包含 none 和 blocked
valid_referers 指令里，none 和 blocked 不是可选项，而是 HTTPS 场景下的刚需：
- none：允许无 Referer 的请求（如地址栏直输、书签访问、HTTPS→HTTP 跳转）
- blocked：允许 Referer 存在但被防火墙/代理篡改、协议降级后丢失域名的请求（常见于企业内网出口或某些 CDN 回源）
- 仅写 yourdomain.com 或 *.yourdomain.com，会把大量真实用户拒之门外
按资源类型分级控制，避免一刀切
图片、视频、CSS、JS 的风险等级不同，防盗链强度也应区分：
- 对公开图片（如 banner、头像）、WebP/JPEG 资源：启用宽松策略，允许 none / blocked / 白名单域名
- 对敏感资源（如会员专享图、下载链接、API 返回的 base64 图片）：可叠加 IP 白名单或 token 验证，不单靠 Referer
- 对 JS/CSS 文件：慎用防盗链，否则可能阻断合法 CDN 加载或构建工具热更新
用自定义响应替代简单 return 403
返回 403 容易暴露防护存在，也缺乏引导。更稳妥的做法是：
- 重定向到一张低分辨率提示图（如 /images/hotlink-denied.png），图上带版权信息和联系入口
- 返回 200 + 空白像素 GIF（1×1 transparent gif），既节省带宽又不暴露错误状态
- 日志中记录 $invalid_referer、$http_referer、$remote_addr，用于后续分析盗链来源
