把资源本体加密和访问来源限制叠加使用，才能让盗链者拿不到、拿到也解不开，这是当前资源防护性价比最高的做法。
为什么单独防盗链不够用先搞清楚资源是怎么泄露的
很多站长以为加了防盗链就万事大吉，结果资源还是被搬运，原因很简单：防盗链只管"谁有资格访问"，管不了"访问之后拿走了什么"，对方用爬虫伪装成正常浏览器，照样能把资源下载下来,然后放到自己的服务器上。
防盗链只堵了入口，没管出口
传统的防盗链靠检查 HTTP Referer 字段，判断请求来自哪个页面,这个机制天生有漏洞：
- Referer 可以被伪造，用 curl 直接指定
-e参数就能骗过去 - 空 Referer 请求（比如直接在地址栏输入、某些隐私浏览器）常常被放行
- 移动端 App 内嵌 WebView 发出的请求，Referer 可能为空或被自定义
就算你用了更严格的 IP 白名单，盗链者换代理 IP 就能绕开，所以防盗链本质是降低批量盗取的效率,而不是彻底阻断。
加密解决的是"拿到了也看不懂"的问题
加密的思路完全不同，它不阻止别人下载，而是让下载下来的文件无法直接使用，比如视频被切成碎片后逐个加密，播放时需要动态密钥才能解密，别人拿到的是一堆密文,没有密钥就是废数据。
行业共识认为，只有加密与防盗链配合，才能同时解决"非法访问"和"非法使用"两个环节的问题。
- 防盗链：拦截绝大多数正常浏览器端的非法引用，减少服务器流量消耗
- 加密：让少数绕过防盗链的下载行为失效，保护资源的实际内容
以常见的静态图片为例，单纯防盗链别人能直接复制图片文件；如果图片本身做了像素级水印或加密处理，复制走了也难以商业化使用。
加密和防盗链怎么同时做？一套可落地的组合策略
这里以视频网站和文档下载站为例，给出完整的操作路径，两者侧重点不同,但底层逻辑一致。
第一步：给资源本体加密
视频资源优先用 HLS AES-128 加密,具体操作流程：
- 使用 FFmpeg 将视频转成 HLS 分片格式
- 生成一个 16 字节的 AES 密钥文件（
enc.key） - 创建
enc.keyinfo
- 执行加密切分命令，
ffmpeg -i input.mp4 -hls_key_info_file enc.keyinfo -hls_time 10 -hls_playlist_type vod output.m3u8 - 将生成的
.m3u8、.ts分片和密钥文件部署到服务器，并控制密钥接口的访问权限
网页文档或静态资源则可以使用 对称加密 + 前端解密 方案，把 HTML、JS、CSS 内容加密后存储，在服务器端判断请求合法后再动态解密输出，更稳妥的做法是在服务端渲染时直接注入内容,避免明文静态文件暴露在公网。
第二步：设置防盗链规则
Nginx 环境下的基础配置，直接在 server 块里加入：
location ~ .(mp4|m3u8|ts)$ {
valid_referers none blocked www.example.com example.com;
if ($invalid_referer) {
return 403;
}
}使用 CDN 服务商（如简米云、酷番云）时，在 CDN 控制台的"访问控制"或"防盗链设置"中：
- 配置 Referer 黑白名单
- 开启 URL 鉴权功能，设置鉴权密钥和有效时长
- 对于视频流，开启 CDN 的"拖拽鉴权"或"播放鉴权"选项
注意：Referer 规则不要设置 none 为允许，否则空 Referer 请求全放行，如果担心影响搜索引擎抓取，可以单独为爬虫配置 UA 白名单。
第三步：动态令牌与时效链接兜底
静态防盗链规则容易被模拟，动态令牌可以做到"一次一签"。
- 服务器签发带时间戳和签名参数的播放链接，
https://res.example.com/video/index.m3u8?sign=abc123&t=1710000000 - 服务端校验时间戳是否过期，以及签名是否正确（通常用 MD5 或 HMAC 对路径+密钥+过期时间计算）
- 签名链接有效期内可播放，过期后返回 403
这种方式既能把访问权限控制在特定时间内，又能防止链接被复制后无限次使用，对于高价值课程视频，在生成播放地址时还可以绑定用户的会话 ID,换设备播放立刻失效。
下面用一个表格对比这三种手段的效果：
| 策略 | 拦截伪造来源 | 防止下载解密 | 动态控制权限 | 实现成本 |
|---|---|---|---|---|
| Referer 防盗链 | 低 | 无 | 无 | 极低 |
| 签名 URL | 中 | 无 | 高 | 低 |
| 组合使用 | 中高 | 高 | 高 | 中 |
视频防盗链加密方案哪个好？主流方案横向对比
视频资源是最容易被盗链的对象之一，业内常见的方案包括 HLS AES-128、HTTP-FLV + 自定义头部校验、以及商用 DRM 系统。
HLS AES-128 加密：主流且免费
苹果提出的 HLS 协议自带 AES-128 加密标准，几乎所有现代播放器都支持,它的特点是：
- 不依赖第三方 SDK，原生播放器直接能播
- 密钥可以通过 HTTP 接口动态下发，方便控制权限
- 缺点是需要服务器额外配置密钥管理，且如果密钥被截获，加密形同虚设
在实施时，密钥接口必须单独做鉴权,不能让密钥文件放在公开可访问的目录。
商用 DRM：适合高价值内容
Widevine、FairPlay、PlayReady 这些方案，安全性远高于 AES-128，因为密钥在在硬件级 TEE 环境中管理，但缺点是授权费用高，且需要播放器做深度集成，对于纪录片、付费课程这类高客单价内容，DRM 是更稳的选择。
自研加密：谨慎使用
自己写一套加密算法做视频混淆，多数情况下不安全，因为前端播放器必须拿到解密逻辑，逆向人员花费一定时间就能提取出算法和密钥，除非你有专业的客户端安全团队,否则建议直接使用成熟方案。
一个简明的对比表：
| 方案 | 安全级别 | 开发成本 | 授权费用 | 适用场景 |
|---|---|---|---|---|
| HLS AES-128 | 中 | 低 | 无 | 中小型视频站点 |
| 自定义头部校验 | 低 | 低 | 无 | 内部系统 |
| 商用 DRM | 高 | 高 | 按量收费 | 影视平台、大厂课程 |
网站资源防盗链设置方法：从轻到重的三档方案
不是所有资源都需要满配加密,根据资源价值选择合适的层级。
轻量级：Referer 校验
适合图片、CSS、JS 这类静态资源，直接在 Web 服务器或 CDN 配置 Referer 规则，操作最快，但防不了伪造和空来源，对于个人博客,这已经能挡住九成以上的站外引用。
中量级：签名 URL
适合下载链接、API 接口、在线预览文件，生成带时效和签名的 URL，比如七牛云、又拍云的"私有空间 + 时间戳鉴权"模式，在云存储控制台开启"原图保护"或"访问鉴权"即可,无需自己写代码。
重量级：加密 + 防盗链 + 水印
适合视频、付费文档、软件安装包，采用 HLS 或 DRM 加密，叠加签名 URL，再在视频中嵌入用户 ID 水印，一旦泄露，可以通过水印定位到具体用户，这属于"防扩散"层面的兜底。
对于 WordPress 站点，可以直接使用插件实现防盗链，WP Content Copy Protection & No Right Click，但这类插件只做表层保护，容易被绕过，还是要在服务器层配置才放心。
加密与防盗链组合常见的疑问
下面三个问题经常被站长讨论，直接给出结论。
加密和防盗链组合会影响搜索引擎抓取吗？
正常情况下不会，搜索引擎爬虫抓取的是页面 HTML，不需要读取视频分片或加密文件，如果你加密的是静态页面，则应在服务端对搜索引擎 UA 返回原始内容，同时保证 URL 稳定，推荐做法是只对资源文件做保护，不对页面 HTML 做整体加密,否则会影响收录和排名。
用 CDN 的情况下怎么配置防盗链？
在 CDN 控制台完成偏置设置即可，以简米云 CDN 为例，在"访问控制 > 防盗链"中配置 Referer 列表，在"URL 鉴权"中开启鉴权并设置主密钥，注意同时开启 CDN 的"私有 Bucket 回源"功能，防止源站被绕过，配置完成后，用无 Referer 的请求测试访问，确认返回 403。
加密后的资源还能被录屏盗走吗？
不能完全杜绝，加密能防止资源被直接下载后二次传播，但录屏是模拟播放过程，相当于用摄像头拍电影，对于录屏风险，只能靠添加用户名水印（每几秒闪现一次）来威慑，并在协议中明确禁止录屏和追究责任，从技术层面讲，可以在播放器里禁用系统录屏权限但这只对受控环境有效，移动端越狱或 root 后仍可绕过。
回到最初的结论：内容加密是内功，防盗链是外功，两者结合才能让资源防护体系真正完整。 先按资源价值分级，再逐步叠加手段,才是适合多数站点的落地路径。