DedeCMS防盗链如何设置？防止资源被非法引用？

畫卷琴夢

发布时间：2025-09-05 10:24:01

838人浏览过

来源于php中文网

原创

DedeCMS防盗链需通过Apache或Nginx服务器配置实现，核心是利用HTTP Referer头判断请求来源，阻止非授权域名引用资源。Apache通过.htaccess文件设置Rewrite规则，Nginx则在配置文件中使用valid_referers指令，两者均在请求到达应用前拦截非法访问，提升效率并保护带宽。常见误区包括未将CDN或子域名加入白名单、错误处理空Referer及影响搜索引擎爬虫。进阶安全策略还包括合理文件权限、WAF防护、系统更新、上传限制和CSP实施，形成多层次资源保护体系。

dedecms防盗链如何设置？防止资源被非法引用？

DedeCMS防盗链的设置核心在于通过服务器配置来识别并拒绝非本站域名的资源请求，从而有效阻止图片、附件等内容被其他网站非法引用，保护带宽并维护版权。这通常不是DedeCMS系统内部的功能，而是依赖于Web服务器（如Apache或Nginx）的强大规则处理能力。

解决方案

要为DedeCMS站点实现防盗链，我们主要在Web服务器层面进行配置。这是最有效、最直接的方式，因为HTTP请求的判断和处理发生在资源到达DedeCMS应用程序之前。

对于Apache服务器 (.htaccess文件配置): 这是许多DedeCMS用户，尤其是共享主机用户最常用的方法。你可以在网站根目录下的

.htaccess

文件中添加以下规则。如果文件不存在，可以创建一个。

# 开启RewriteEngine
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain\.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yoursubdomain\.yourdomain\.com [NC] # 如果有子域名也需要放行
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?anotherdomain\.com [NC] # 如果你的CDN或合作站点需要访问，也需放行
RewriteRule \.(jpg|jpeg|png|gif|bmp|flv|swf|rar|zip|mp3|mp4)$ - [F,NC,L]

解释一下这段代码：

```
RewriteEngine On
```
：激活Apache的URL重写模块。
```
RewriteCond %{HTTP_REFERER} !^$ [NC]
```
：这行是说，如果HTTP Referer头不是空的（即不是直接访问或某些浏览器设置），则继续下面的条件判断。
```
[NC]
```
表示不区分大小写。
```
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain\.com [NC]
```
：这是核心，它检查请求的来源（Referer）是否不属于你的主域名。
```
yourdomain.com
```
请替换成你的实际域名。
```
!
```
表示“不匹配”，即如果Referer不是你的域名，则满足此条件。
```
RewriteRule \.(jpg|jpeg|png|gif|bmp|flv|swf|rar|zip|mp3|mp4)$ - [F,NC,L]
```
：如果上述所有条件都满足（即Referer不为空且不是你的域名或白名单域名），那么任何以这些后缀结尾的资源请求都会被拒绝，返回403 Forbidden错误。
```
[F]
```
表示Forbidden，
```
[L]
```
表示这是最后一条规则，不再继续处理。

对于Nginx服务器 (配置文件配置): Nginx的配置通常更直接，性能也更高。你需要在你的网站对应的Nginx配置文件（通常在

/etc/nginx/conf.d/

或

/etc/nginx/sites-available/

目录下）的

server

块中添加如下内容：

location ~* \.(jpg|jpeg|png|gif|bmp|flv|swf|rar|zip|mp3|mp4)$ {
    valid_referers none blocked server_names
                   *.yourdomain.com
                   yourdomain.com
                   *.yoursubdomain.yourdomain.com; # 如果有子域名
                   # 另外，如果你使用了CDN，需要把CDN的域名也加进来，例如：
                   # *.yourcdnprovider.com;

    if ($invalid_referer) {
        # 可以直接返回403错误
        return 403;
        # 也可以重定向到一个提示图片，例如：
        # rewrite ^/ http://yourdomain.com/images/hotlink_forbidden.png;
    }
}

解释一下这段代码：

```
location ~* \.(jpg|jpeg|png|gif|bmp|flv|swf|rar|zip|mp3|mp4)$
```
：这个块匹配所有以指定后缀结尾的资源请求。
```
~*
```
表示不区分大小写的正则匹配。
```
valid_referers
```
：定义了合法的Referer来源。
- ```
none
```
  ：允许Referer为空的请求（例如直接在浏览器地址栏输入图片URL，或某些隐私设置）。
- ```
blocked
```
  ：允许Referer被防火墙或代理隐藏的请求。
- ```
server_names
```
  ：允许来自Nginx
```
server_name
```
  指令中定义的域名的请求。
- ```
*.yourdomain.com
```
  和
```
yourdomain.com
```
  ：你的主域名及其所有子域名。
```
if ($invalid_referer)
```
：如果Referer不合法（不在
```
valid_referers
```
列表中），则执行
```
if
```
块内的指令。
```
return 403;
```
：返回403 Forbidden错误。
```
rewrite ^/ http://yourdomain.com/images/hotlink_forbidden.png;
```
：一个更友好的做法是重定向到一个提示图片，告诉用户资源已被保护。

配置完成后，无论是Apache还是Nginx，都需要重启Web服务才能使配置生效。

DedeCMS防盗链为何主要依赖服务器配置，而非系统内置功能？

在我看来，这是一个Web应用架构的经典分工问题。DedeCMS作为一个内容管理系统，它的核心职责是内容的创建、编辑、发布和管理。它更侧重于数据库操作、模板渲染、用户权限等“应用层”的逻辑。而防盗链这种需求，本质上是对HTTP请求的“流量控制”和“访问权限”判断，这正是Web服务器（如Apache、Nginx）的强项。

设想一下，如果DedeCMS要自己实现防盗链，它就必须在每次用户请求图片、附件时，都启动PHP解释器，加载DedeCMS框架，然后通过PHP代码去读取HTTP Referer头，再进行判断。这不仅会大大增加服务器的CPU和内存开销（因为PHP是动态语言，每次执行都有一定的启动成本），而且效率低下。面对高并发的图片请求，这种方式很容易造成服务器过载，甚至出现性能瓶颈。

相比之下，Apache和Nginx这类Web服务器是专门为处理HTTP请求而优化的，它们在底层用C/C++编写，处理速度极快。它们可以直接在接收到请求的第一时间，在网络层面就完成Referer头的检查和判断，如果发现是非法请求，可以直接在Web服务器层面就拒绝掉，根本不会把请求转发给后端的PHP处理器。这种“近源阻断”的方式，效率最高，对服务器资源的消耗也最小。所以，将防盗链的职责交给Web服务器，是符合“职责分离”原则的最佳实践，既保证了效率，又减轻了DedeCMS本身的负担。

DedeCMS防盗链配置中，常见的误区和注意事项有哪些？

在实际操作DedeCMS防盗链时，我发现大家经常会遇到一些坑，或者忽略一些关键细节，这里我总结几点：

忘记白名单CDN或子域名： 这是最常见的错误。如果你使用了CDN来加速图片或附件，或者你的网站有子域名（例如
```
m.yourdomain.com
```
用于移动端），那么这些域名在防盗链规则中也必须被明确地列为“合法来源”。否则，CDN上的图片可能无法加载，或者子域名无法正常显示主域名的资源，这会严重影响用户体验。Nginx的
```
valid_referers
```
和Apache的
```
RewriteCond
```
都需要仔细检查并添加这些白名单。
对“空Referer”的处理： 有些用户通过直接输入图片URL访问，或者在某些网络环境下、使用特定浏览器插件时，HTTP Referer头可能是空的。是允许还是禁止？这需要你权衡。如果允许，一些直接访问的场景（比如搜索引擎图片搜索结果）会正常显示；如果禁止，则这些场景下图片会无法显示。我的建议是，通常可以允许空Referer，因为完全禁止可能会影响搜索引擎的索引或一些合法用户的访问。在Nginx配置中，
```
none
```
就代表允许空Referer。

Vozo
Vozo是一款强大的AI视频编辑工具，可以帮助用户轻松重写、配音和编辑视频。

下载
搜索引擎爬虫的考量： 谷歌、百度等搜索引擎的爬虫有时会抓取图片资源。虽然它们通常不会“盗链”，但过于严格的防盗链规则可能会误伤这些爬虫，导致图片无法被正常索引，进而影响SEO。幸运的是，主流搜索引擎的爬虫行为通常不会被常规的防盗链规则误伤，因为它们要么不发送Referer，要么发送的Referer是其自身的域名，而我们通常只针对外部域名进行限制。不过，如果你的防盗链规则过于激进，比如无差别地拦截所有非本站Referer，那就需要额外关注。
配置后的测试： 配置完防盗链规则后，务必进行彻底测试。
- 用本站页面加载图片，看是否正常。
- 用一个外部网站（你可以自己建一个测试页面）尝试引用你的图片，看是否被阻止。
- 尝试直接在浏览器地址栏输入图片URL访问，看是否被允许（取决于你对空Referer的设置）。
- 检查网站的日志文件，看是否有403错误或其他异常。
规则的精确性： 确保你的
```
RewriteRule
```
或
```
location
```
匹配的资源类型是准确的。如果匹配范围过广，可能会误伤一些不应该被限制的文件；如果过窄，则可能无法完全覆盖所有需要保护的资源。例如，除了图片，你可能还需要保护PDF、视频、音频文件等。

除了防盗链，DedeCMS资源安全还有哪些进阶防护策略？

防盗链只是DedeCMS资源安全的一环，在我看来，构建一个真正安全的资源环境需要一个多层次、全方位的策略。除了防盗链，以下这些进阶防护措施同样重要，甚至更为基础：

严格的文件权限设置： 这是最基础也是最容易被忽视的安全措施。DedeCMS安装后，很多目录和文件的权限需要仔细设置。通常，文件权限应设置为
```
644
```
，目录权限设置为
```
755
```
。特别要注意的是，
```
data
```
、
```
uploads
```
、
```
templets
```
等目录绝不能设置为
```
777
```
（所有人可读写执行），这会给攻击者上传恶意脚本大开方便之门。确保只有Web服务器进程有足够的权限进行读写，而其他用户则没有。
Web应用防火墙 (WAF) 的引入： 部署WAF是一个非常有效的进阶防护手段。ModSecurity（对于Apache）或Nginx自带的WAF模块，可以实时监控和拦截各种常见的Web攻击，如SQL注入、XSS、文件上传漏洞等。虽然WAF不能直接解决防盗链问题，但它可以阻止攻击者利用DedeCMS的其他漏洞来篡改或滥用你的资源。例如，防止恶意文件上传到
```
uploads
```
目录，这比仅仅防盗链更具根本性。
DedeCMS系统及插件的定期更新： 任何软件都会有漏洞，DedeCMS也不例外。保持DedeCMS系统核心程序、模板以及所有安装的插件和模块更新到最新版本，是堵塞已知安全漏洞最直接有效的方法。许多资源被非法利用，往往不是因为防盗链没做好，而是因为系统本身的漏洞被利用，导致攻击者直接获取了资源路径或控制权。
上传文件类型和大小的严格限制： 在DedeCMS后台，务必对允许用户上传的文件类型进行严格限制，只允许图片、文档等安全类型，禁止上传
```
.php
```
、
```
.asp
```
、
```
.exe
```
等可执行文件。同时，设置合理的文件大小限制，防止恶意用户通过上传超大文件进行DDoS攻击或耗尽服务器存储空间。如果DedeCMS自带的上传功能不够完善，可以考虑使用更安全的第三方文件上传组件。
内容安全策略 (CSP) 的实施： CSP是一种浏览器安全机制，可以有效防止跨站脚本攻击（XSS）和数据注入攻击。通过在HTTP响应头中添加
```
Content-Security-Policy
```
，你可以告诉浏览器哪些资源（如脚本、样式、图片）可以从哪些源加载。虽然这主要针对前端安全，但它也能间接保护你的资源不被恶意脚本滥用。例如，你可以限制图片只能从你的域名加载，这在一定程度上也能起到类似防盗链的效果，但其主要目标是防御XSS。