防盗链性能优化核心是减少匹配次数、避免正则回溯、跳过非关键请求、用缓存兜底；应精简Referer匹配逻辑，限制放行域名数量，禁用none/blocked，仅在静态资源location中启用，优先使用map预编译匹配，结合CDN前置过滤。
防盗链本身不直接处理高并发请求，它的开销主要来自每次请求时的 Referer 头解析与匹配判断。在图片流量大的场景下，若规则写得低效或未配合缓存，反而会拖慢响应、增加 CPU 消耗。优化核心是：**减少匹配次数、避免正则回溯、跳过非关键请求、用缓存兜底**。
精简 Referer 匹配逻辑，避免正则滥用
很多配置习惯用模糊正则匹配 Referer，例如：
❌ 低效写法（触发回溯、性能差）：if ($invalid_referer) { return 403; }
其中 $invalid_referer 是通过 valid_referers none blocked *.example.com; 定义的——看似简洁，但 Nginx 内部对每个 valid_referers 条目都会做字符串扫描或正则尝试，尤其当域名列表多、含通配符时，CPU 开销明显上升。
✅ 推荐做法：
- 只保留必须放行的域名，最多 3–5 个；禁用
none和blocked（它们会强制检查所有请求） - 用精确域名匹配代替通配符：
valid_referers example.com app.example.com api.example.com; - 完全不需要防盗链的资源（如公开图标、CDN 回源请求），直接跳过判断
把防盗链判断移到 location 级别，避开无关路径
把 valid_referers 放在全局 http 或 server 块里，会导致所有请求（包括 JS/CSS/HTML/接口）都走一遍 Referer 判断，纯属浪费。
✅ 正确做法：
- 仅在真正需要保护的静态资源 location 中启用，例如：
location ~* \.(jpg|jpeg|png|gif|webp|svg)$ {<br>
valid_referers example.com www.example.com;<br>
if ($invalid_referer) { return 403; }<br>
expires 7d;<br>
add_header Cache-Control "public, immutable";<br>
}
这样 CSS、JS、API 路径完全绕过防盗链逻辑，减轻主流程负担。
用 map 替代 if + valid_referers，降低运行时开销
if 在 location 中属于“运行时指令”，每次请求都要执行；而 map 是预编译映射表，查表速度极快，更适合高频判断。
✅ 更优写法（推荐）：
在 http 块中定义：
map $http_referer $is_valid_ref {<br>
default 0;<br>
~^https?://(www\.)?example\.com(/|$) 1;<br>
~^https?://app\.example\.com(/|$) 1;<br>
}
在对应 location 中使用：
location ~* \.(jpg|png|webp)$ {<br>
if ($is_valid_ref = 0) { return 403; }<br>
# 后续正常处理<br>
}
注意：map 中的正则只编译一次，且支持精确锚定（^ 和 $），比 valid_referers 更可控、更轻量。
搭配 CDN 或边缘缓存，让盗链请求根本不到源站
真正的高并发压力往往来自恶意爬虫或聚合平台批量刷图。与其在 Nginx 层硬扛判断，不如把过滤前置：
- 在 CDN（如 Cloudflare、阿里云全站加速）上配置 Referer 黑白名单，拦截 95% 以上非法请求
- 源站 Nginx 只处理可信来源（如 CDN 回源 IP 段），可直接信任
X-Forwarded-For或设置固定回源 Header - 对已知盗链 UA（如 python-requests、curl）加简单 UA 过滤，作为辅助手段
这样源站 Nginx 几乎只服务合法用户，防盗链模块自然不再成为瓶颈。
