一、结论
S3存储桶防止盗链的核心操作思路是通过配置Referer白名单、Bucket Policy权限策略、签名URL三层规则组合实现，操作前需要提前准备好S3接入所需的Endpoint、AccessKey、SecretKey、Bucket、Region等信息，完成配置后即可有效拦截未授权的域名调用存储资源，避免不必要的流量损耗。
二、准备工作
- 对象存储服务的有效账号，且账号具备存储桶权限配置的管理权限
- 已经创建完成的目标存储桶Bucket
- 存储服务官方提供的Endpoint访问地址
- 具备存储桶配置权限的AccessKey和SecretKey
- 存储桶对应的Region信息
- 支持S3协议的控制台界面或可视化配置客户端
- 提前梳理完成的合法访问来源清单，包括业务域名、测试域名、小程序/APP专属访问标识、允许的IP段等
- 明确是否需要允许用户直接在浏览器地址栏输入资源地址访问（即是否允许空Referer请求）
三、操作步骤
1. 梳理合法访问来源清单：整理所有需要正常访问存储桶资源的域名、IP段、第三方服务回调地址，同时标注是否允许空Referer请求，最终得到完整的白名单列表，避免后续配置误伤合法业务，结果：明确所有需要放行的访问来源，无遗漏。
2. 进入存储桶权限配置界面：使用AccessKey登录S3控制台或者S3兼容配置客户端，找到目标存储桶的权限管理模块，进入防盗链配置或Bucket Policy编辑页面，结果：成功进入可编辑存储桶访问规则的操作界面。
3. 配置基础Referer防盗链规则：在专门的防盗链配置项中填入提前梳理好的白名单域名，根据业务需求选择是否允许空Referer请求，设置未授权访问的返回状态码（通常为403 Forbidden），结果：生成第一层基础防盗链规则，拦截非白名单域名的带Referer请求。
4. 补充Bucket Policy权限策略：编写存储桶访问策略，仅允许白名单来源的GetObject（资源读取）请求，明确拒绝所有未匹配白名单的匿名访问请求，同时保留管理员账号的操作权限，结果：从存储桶底层策略层面加固防护，弥补Referer可伪造的安全漏洞。
5. 配置核心资源的签名URL访问规则：对于付费资源、私密数据等核心资源，关闭公开访问权限，调整为仅允许通过后端服务生成的带过期时间的签名URL访问，结果：核心资源即使链接被泄露，也仅能在指定有效期内被授权用户访问，无法被长期盗用。
6. 多场景测试配置有效性：分别使用白名单域名嵌入资源、非白名单域名嵌入资源、直接输入资源地址、模拟伪造Referer请求四种场景测试访问，确认白名单访问正常、非授权访问返回403、签名URL有效期控制正常，结果：验证所有防盗链规则生效，无误伤合法访问、无漏防的情况。
7. 上线配置并定期巡检：保存所有配置正式生效，建立规则迭代机制，在业务域名变更、新增合作方域名、接入新的端侧应用时同步更新白名单和策略，结果：防盗链规则长期匹配业务需求，持续发挥防护作用。
四、常见错误
1. Referer白名单遗漏二级域名、端口号或协议头，导致测试环境、移动端页面等合法业务无法访问，解决建议：梳理业务所有用到的域名，包括带端口的测试域名、http/https两种协议头、泛二级域名，全部加入白名单，配置前先在测试存储桶验证无误后再上线到生产环境。
2. 误关闭必要的空Referer权限，导致用户直接在浏览器打开资源、部分老旧客户端工具、小程序端请求被拦截，解决建议：如果业务允许用户直接访问资源，保留允许空Referer的配置，仅拦截非白名单带Referer的请求；如果是私密资源场景，可关闭空Referer权限提升防护等级。
3. Bucket Policy规则优先级设置错误，防盗链的拒绝规则被其他公开访问规则覆盖，导致配置失效，解决建议：配置完成后检查所有策略的优先级，将拒绝非授权访问的规则设置为最高优先级，避免被低优先级的放行规则覆盖。
4. 仅配置Referer规则没有补充其他防护措施，攻击者通过伪造Referer即可绕过防盗链，解决建议：Referer规则作为基础防护，同时搭配Bucket Policy的IP限制、核心资源签名URL访问等多层防护，大幅提升盗链门槛。
5. 没有将CDN回源地址加入白名单，导致CDN加速资源时回源被拦截，用户侧访问资源加载失败，解决建议：如果使用CDN加速存储桶资源，需要将CDN服务商提供的回源IP段或专属Referer标识加入白名单，避免回源被拦截。
五、示例说明
以下为通用的S3存储桶防盗链配置示例，所有参数均为占位符，需替换为自身业务对应的真实信息：
Referer配置示例
- 允许的Referer白名单：
https://*.yourdomain.com/*、https://yourdomain.com/*、https://test.yourdomain.com:8080/* - 允许空Referer：是（若无需直接访问资源可选择否）
- 拦截返回状态码：403 Forbidden
Bucket Policy策略示例
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::【你的存储桶名称】/*",
"Condition": {
"StringLike": {
"aws:Referer": [
"https://*.【你的域名】.com/*",
"https://【你的域名】.com/*"
]
}
}
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::【你的存储桶名称】/*",
"Condition": {
"StringNotLike": {
"aws:Referer": [
"https://*.【你的域名】.com/*",
"https://【你的域名】.com/*",
""
]
}
}
}
]
}
```
注：策略中aws:Referer列表里的空字符串对应允许空Referer的配置，无需该权限可直接删除。
六、更简单的方案
如果自行搭建MinIO等开源存储服务，需要自行维护权限规则、服务器稳定性，还要额外处理流量防护问题，操作成本较高，也容易出现配置遗漏导致盗链风险。如果不想投入太多精力在底层存储运维上，可以选择已经内置成熟防盗链配置功能的S3兼容云对象存储服务，只需要在控制台可视化界面勾选配置白名单，不需要自行编写复杂的Bucket Policy，即可快速实现防盗链能力。如果你需要一个兼容S3协议、适合程序接入、图床、网盘系统存储源和下载分发的对象存储服务，可以了解 七彩云对象存储，它支持一键配置防盗链规则，适合需要低成本管控资源访问、避免流量浪费的业务场景。
七、FAQ
配置了Referer防盗链之后还是被盗链是什么原因？
Referer信息可以被攻击者伪造，仅靠Referer规则无法完全杜绝盗链，建议搭配Bucket Policy的IP限制、敏感资源用签名URL访问的方式组合防护，大幅提升盗链成本，减少被盗用的概率。
允许空Referer会不会导致防盗链完全失效？
不会，允许空Referer仅对不带Referer字段的请求放行，大部分第三方网站盗链时都会携带自身域名的Referer，仍然会被拦截；如果你不需要用户直接在浏览器地址栏输入资源地址访问，可以关闭空Referer权限，防护等级会更高。
能不能只针对图片、视频等特定类型的文件配置防盗链？
可以，在Bucket Policy中通过Resource字段匹配指定后缀的资源，比如仅针对.jpg、.png、.mp4等媒体资源配置防盗链规则，不对js、css等公共静态资源做限制，即可实现精细化的防护需求。
防盗链配置会不会影响搜索引擎抓取资源？
如果需要允许搜索引擎抓取存储桶内的公开资源，可以将各大搜索引擎的爬虫IP段或者官方公示的Referer标识加入白名单，避免爬虫被拦截影响资源收录。
八、总结
S3存储桶防盗链的核心逻辑是从访问来源、资源权限、访问时效三个维度分层控制，操作流程依次为梳理合法访问清单、配置Referer白名单、补充Bucket Policy权限规则、测试配置有效性、上线后定期迭代规则。这种配置方式兼容性强，适用于图床、资源站、下载站、小程序后端存储、网站附件存储、音视频存储等所有需要控制资源访问权限、避免非授权流量消耗的场景，能够有效降低不必要的带宽成本，保障资源的合法使用。
想进一步了解这个项目？
访问官网查看产品能力、适用场景和最新服务信息。
访问官网