迅雷等下载工具默认不发referer，匹配none规则，是否拦截取决于配置是否包含none；其referer可伪造或被代理截断，需用curl模拟测试并结合日志验证，但仅referer防护易被绕过，须配合token、限速、ua过滤等分层措施。
迅雷等下载工具通常不发送标准 Referer 头，或主动清空、伪造 Referer，因此它们的请求多数会匹配 valid_referers 中的 none 或 blocked 规则——是否被拦截，取决于你是否把这两类情况列入了“允许范围”。要验证防盗链规则能否真正拦截这类工具，关键不是看它“能不能发请求”，而是看它“发的请求是否被拒绝”。
明确迅雷类工具的 Referer 行为特征
迅雷、IDM、Motrix 等客户端在发起 HTTP 请求时：
- 默认不携带 Referer（即请求头中完全缺失
Referer:字段），对应valid_referers none的匹配场景； - 部分版本或手动配置后可能伪造 Referer（如设为
https://baidu.com），此时是否拦截取决于该域名是否在valid_referers白名单中； - 若使用代理或中间网关（如某些企业网络环境），Referer 可能被剥离为非法格式（如仅含域名无协议），落入
blocked类别。
用 curl 模拟迅雷请求进行精准测试
不依赖真实客户端，用 curl 控制 Referer 状态，可覆盖所有典型情况：
-
模拟无 Referer（最常见迅雷行为）：
curl -I http://yourdomain.com/image.jpg
→ 应返回200（若配置含none）或403（若未包含none）； -
模拟伪造 Referer（如盗链站或恶意脚本）：
curl -I -H "Referer: https://evil-site.com" http://yourdomain.com/image.jpg
→ 应返回403（只要evil-site.com不在白名单中）； -
模拟被代理截断的 Referer（如含空格、无协议）：
curl -I -H "Referer: example.com" http://yourdomain.com/image.jpg
→ 此类值不以http://或https://开头，属于blocked，结果取决于你是否启用blocked参数。
检查 Nginx 日志确认拦截效果
在 nginx.conf 的 log_format 中确保包含 $http_referer 和 $status：
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" "$http_user_agent"';
然后观察访问日志（如 /var/log/nginx/access.log）中是否有类似条目：
-
192.168.1.100 - - [22/Jul/2026:04:15:22 +0000] "GET /file.zip HTTP/1.1" 403 168 "-" "NetAnts/1.2"→ 无 Referer + 非法 UA，被拒； -
192.168.1.101 - - [22/Jul/2026:04:16:03 +0000] "GET /video.mp4 HTTP/1.1" 200 10485760 "https://baidu.com" "Thunder/11.4.1.2110"→ 若baidu.com不在白名单，却返回 200，说明规则未生效或配置位置错误。
特别注意：防盗链对下载工具的实际防护边界
单纯靠 Referer 无法彻底阻止迅雷等工具，因为：
- 它们可任意设置 Referer（比如填你的域名），绕过白名单；
- 支持断点续传、多线程，即使单次被 403，也可能换 UA 或 Referer 重试；
- 不走浏览器同源策略，不受 Referrer Policy 限制。
所以生产环境建议：Referer 限制只作为第一道轻量过滤，必须配合其他手段，例如：
- 对敏感资源路径加动态 Token（如
/download/file.zip?t=xxx&e=yyy）； - 限制单 IP 单位时间请求数（
limit_req）； - 要求 User-Agent 包含可信关键词，或拒绝已知下载器 UA（如
Thunder、NetAnts、IDM）； - 将大文件移至需登录态校验的后端接口，而非直接暴露静态路径。
