nginx静态资源防盗链通过valid_referers指令与$invalid_referer变量实现，仅限location块内配置白名单（none、blocked、域名、通配符、正则），匹配后return 403，须精准作用于静态文件路径，高风险场景可叠加secure_link签名机制。
静态资源防盗链在 Nginx 中主要靠 valid_referers 指令配合 $invalid_referer 变量实现，核心是限制哪些来源（Referer）能合法访问图片、CSS、JS 等文件。它不依赖后端，开销低，适合拦截粗暴盗链，但需注意 Referer 可被伪造，不能替代鉴权。
白名单配置：明确允许谁访问
在匹配静态资源的 location 块中定义合法来源，支持多种写法，多个规则为“或”关系：
- none：允许无 Referer 的请求（如用户直接输入 URL、HTTPS 页面引用 HTTP 资源、隐私模式）
- blocked：允许 Referer 被代理或防火墙清空的请求（常见于某些内网或安全策略环境）
-
example.com：精确匹配该域名（
www.example.com和example.com视为不同，需都写上） -
*.example.com：通配所有子域名（如
cdn.example.com、blog.example.com） -
~\.example\.(com|org)$：正则匹配，注意点号要转义，结尾加
$避免误匹配
拦截动作：返回 403 是最稳妥的选择
校验后必须明确响应行为。推荐使用 return 403：
- 语义准确，CDN、爬虫、浏览器都能正确识别拒绝状态
- 日志中
$status明确为 403，便于排查和监控 - 避免用
rewrite跳转到提示图——这会返回 200，掩盖真实拦截意图，还可能引发循环匹配或参数丢失 - 若需展示友好提示图，应改用
error_page 403 =200 /images/forbidden.png;，既保持语义又呈现内容
作用范围：只对静态资源启用，避免误伤
防盗链逻辑必须限定在真正需要保护的资源路径或后缀上：
- 推荐用正则精准匹配常见静态类型：
location ~* \.(jpg|jpeg|png|gif|webp|css|js|woff2?|ttf|eot|svg|mp4|pdf)$ - 确保该
location块内包含root或alias，否则文件根本找不到，防盗链形同虚设 - 不要放在
http或upstream块中——valid_referers只在server或location内生效 - HTML、API 接口等动态内容不应套用此规则，否则可能影响正常页面加载或 AJAX 请求
增强防护：补充签名机制应对高风险场景
当 Referer 防护不够用（如需防止登录用户分享直链、限时下载、会员专属资源），可启用 secure_link 模块：
- 确认 Nginx 已编译含
--with-http_secure_link_module（主流发行版通常默认支持） - URL 中携带
?md5=xxx&expires=1717027200，Nginx 校验签名是否由 secret_key + URI + 过期时间生成 - 令牌生成必须严格一致：URI 不带查询参数、不自动解码；时间戳为 Unix 秒级整数
- 适合保护下载包、后台导出文件、预览视频等强时效性资源，与 Referer 防盗链形成分层防护
