丘盾文档中心

主题

其他配置 ​

WARNING

请根据需求进行配置，不然某些配置调整后导致服务不可使用不负责此问题

URL跳转 ​

image-20250404234620286

跳转类型分别有：URL跳转、域名跳转、端口跳转

URL跳转 ​

需要填写完整的URL，包括http://或者https://，如果有非默认端口，也需要带上端口号

匹配条件

如果是精准匹配，精准匹配跳转前的URL，即只有访问完全一样的URL才会跳转

如填写 https://scdn.koxiuqiu.cn/111 ，则就只能是准确访问了此URL才会匹配上条件，访问  https://scdn.koxiuqiu.cn/1111 或者 https://scdn.koxiuqiu.cn/222 都不会匹配

匹配前缀

匹配前缀则是只要访问的URL头部部分包含跳转前URL，即可跳转

如填写了https://scdn.koxiuqiu.cn，那么只要访问的URL含有这个将会直接触发匹配条件

正则匹配

以在跳转前URL中使用正则表达式，然后可以在跳转后URL中使用正则表达式中括号的变量，比如${1}、${2}分别表示第一个和第二个括号内的变量值

正则表达式(Regular Expression)是一种文本模式，包括普通字符（例如，a 到 z 之间的字母）和特殊字符（称为"元字符"），可以用来描述和匹配字符串的特定模式。正则表达式是一种用于模式匹配和搜索文本的工具。提供了一种灵活且强大的方式来查找、替换、验证和提取文本数据

正则表达式的模式可以包括以下内容：

  • 字面值字符：例如字母、数字、空格等，可以直接匹配它们自身
  • 特殊字符：例如点号 .、星号 *、加号 +、问号 ? 等，它们具有特殊的含义和功能
  • 字符类：用方括号 [ ] 包围的字符集合，用于匹配方括号内的任意一个字符
  • 元字符：例如 \d、\w、\s 等，用于匹配特定类型的字符，如数字、字母、空白字符等
  • 量词：例如 {n}、{n,}、{n,m} 等，用于指定匹配的次数或范围
  • 边界符号：例如 ^、$、\b、\B 等，用于匹配字符串的开头、结尾或单词边界位置

域名跳转 ​

指定跳转前域名，只要是此域名都触发匹配

如 scdn.koxiuqiu.cn ，访问此域名将都会执行跳转

端口跳转 ​

指定跳转前端口，只要是指定的端口都会跳转至另一个设置的端口

如 80 端口，跳转后端口设置成443，只要是80端口的请求都将会跳转至443

跳转状态码 ​

目前支持分别是：

  • 301 - Moved Permanently

即永久移动，是HTTP状态码中表示永久重定向的一种。当服务器返回这个状态码时，它告诉客户端请求的资源已经被永久移动到了一个新的URL上，并且以后的请求应该使用新的URL。这个状态码主要用于网站重构、更换域名或者更改URL结构等情况下，确保旧的URL能够正确地指向新的位置

  • 308 - Permanent Redirect

308永久重定向是一种表示资源已被永久移动到由Location首部指定的URL的响应状态码。当发生308重定向时，浏览器将自动进行重定向，同时搜索引擎也会更新其链接。与301状态码不同的是，在308重定向的过程中，请求方法和消息主体不会发生改变，而301状态码有时会导致请求方法被错误地修改为GET方法

  • 302-Found

在实际开发中，302 Found常用于网页跳转、身份验证等场景。 处理302 Found错误的方法包括检查重定向目标是否正确、排除循环重定向、处理重定向过程中可能出现的错误等。 使用开发者工具调试和利用浏览器插件进行重定向管理可以帮助开发者更好地理解和解决302 Found错误

  • 303 - See Other

当用户提交一个表单后，服务器可能会处理表单数据，并将用户重定向到一个新的URL，以显示处理结果。这时，服务器会返回303状态码，并在响应头中包含一个Location字段，指示新的URL

  • 307- Temporary Redirect

307临时重定向，HTTP1.1的状态码

一般情况下都是301 - Moved Permanently，如果你没有什么需求且确实要永久更换域名等情况，需要迁移和告诉搜索引擎我已经迁移此服务，转移权重，否则是302（看情况使用，一般情况下短暂使用），301带来的影响不可逆

Web防火墙(WAF) ​

image-20250405000248504

CAUTION

默认启用系统默认策略，如出现问题或只用自己设置的策略请记得前往更多选项关闭系统默认

防跨站脚本攻击 ​

image-20250405000445573

防止上传可执行脚本文件 ​

image-20250405000527391

image-20250405000544646

\.(php|jsp|aspx|asp|exe|asa|rb|py)\b

防止远程执行服务器命令 ​

image-20250405000639378

image-20250405000657818

\b(eval|system|exec|execute|passthru|shell_exec|phpinfo)\s*\(

命令注入 ​

image-20250405000731179

image-20250405000739542

\b(pwd|ls|ll|whoami|id|net\s+user)\s*$

image-20250405000748009

\b(pwd|ls|ll|whoami|id|net\s+user)\s*$

防止读取网站目录之外 ​

image-20250405000844870

image-20250405000852376

((\.+)(/+)){2,}

防止Web访问特殊目录 ​

image-20250405000939657

image-20250405000954754

/.git
/.svn
/.htaccess
/.idea
/.env
/.vscode

防止SQL注入漏洞 ​

image-20250405001023457

禁止一些网络爬虫 ​

image-20250405001047843

防止短时间大量请求涌入(CC攻击) ​

image-20250405001123941

CAUTION

行为可能带来的负面影响，根据需求谨慎设置避免出现服务不可用，设置错误导致封禁正常请求使用

防止第三方网站引用本站资源(防盗链) ​

image-20250405001312350

WAF提示 ​

系统默认设置：XSS、路径穿越、特殊目录、网络爬虫、CC攻击

NOTE

如无其他特殊需求一般无需设置，直接开启系统默认即可（包测速全绿），如以上有策略需要设置但是系统默认的又有了也有其他需求的策略可以系统默认和自设同时开，自设策略优先于系统默认

缓存配置(重要) ​

很多情况下缓存配置不当就可能会导致服务不正常，例如我们众所周知的wordpress博客系统，只要开启缓存就导致出现各种奇奇怪怪的问题，需要关闭系统默认缓存且自行配置适配的，配置得当缓存策略，就可以更好的加速自己的服务速度

例如在缓存命中极其低，或者是压根没法缓存的，就可检查你是不是在更多选项那边开启了“过时缓存策略”功能吧！

“走缓存了”意味着请求的数据直接从缓存中获取，而不是从原始数据源（如数据库或服务器）获取。这种情况通常发生在缓存命中时，即缓存中有有效数据且能够满足请求。以下是对这一概念的详细分步解释：

  1. 缓存命中（Hit）：
    • 当请求的数据存在于缓存中且未过期时，系统直接从缓存返回数据，无需访问原始数据源
    • 这种情况提高了响应速度，减轻了服务器负载
  2. 缓存未命中（Miss）：
    • 当请求的数据不在缓存中，或者数据已过期，系统需要从原始数据源获取数据
    • 获取到数据后，通常会将数据存入缓存，以便后续请求时能够命中缓存
  3. 缓存类型：
    • 页面缓存：缓存整个页面，减少重复渲染的开销
    • 数据库查询缓存：缓存数据库查询结果，减少与数据库的交互
    • 对象缓存：缓存应用程序对象，提高对象访问效率
  4. 缓存有效期（Expiration）：
    • 数据在缓存中保留的时间，超过该时间后数据被视为无效，需重新获取
    • 有效期内的数据会被直接命中，提高性能
  5. 缓存一致性：
    • 确保缓存中的数据与原始数据源一致，避免数据不一致导致的问题
    • 使用刷新机制或写通过策略来维护一致性
  6. 缓存命中率（Hit Rate）：
    • 命中次数与总请求次数的比率，反映缓存的有效性
    • 高命中率意味着系统性能更优，响应更快
  7. 缓存失效与替换策略：
    • 失效：数据过期或被显式移除
    • 替换策略：如LRU、LFU，决定如何替换缓存中的数据以腾出空间
  8. 缓存穿透与击穿：
    • 穿透：缓存未命中，数据不存在，导致频繁查询数据库
    • 击穿：缓存失效前后，大量请求集中访问，导致系统负载骤增
    • 解决方案包括布隆过滤器、互斥锁、永不过期缓存等
  9. 缓存监控与优化：
    • 使用工具监控缓存性能，分析命中率、未命中率等指标
    • 根据监控结果优化缓存配置，如调整过期时间、增加缓存大小

通过合理设计和优化缓存机制，可以有效提升系统性能，减少响应时间，提高用户体验

系统默认缓存策略如下 ​

image-20250405001908198

image-20250405001944292

image-20250405001955794

缓存配置极其复杂，如无特殊需求简单配置或者默认即可，如果有需求或不懂可联系管理员，对文档进行更新/来后台帮你简单配置

配置 CC 防御 ​

如存在误封情况请进行以下操作解决

  1. 调整防护规则
  2. 添加白名单
  3. 配置自定义规则，进行条件放行

CAUTION

CC 规则不固定，按网站需求自行配置

Websocket ​

WebSocket 协议在2008年诞生，2011年成为国际标准。现在所有浏览器都已经支持了。WebSocket 的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话

HTTP 有 1.1 和 1.0 之说，也就是所谓的 keep-alive ，把多个 HTTP 请求合并为一个，但是 Websocket 其实是一个新协议，跟 HTTP 协议基本没有关系，只是为了兼容现有浏览器，所以在握手阶段使用了 HTTP

最简单直接的讲就是：用来实时刷新请求的，例如聊天站等需要实时刷新的，一般都是客户端主动请求而这个将会实时刷新请求

66b56224-5073-4047-bdf0-2dc0a8da3580

WebSocket 的其他特点：

  • 建立在 TCP 协议之上，服务器端的实现比较容易
  • 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器
  • 数据格式比较轻量，性能开销小，通信高效
  • 可以发送文本，也可以发送二进制数据
  • 没有同源限制，客户端可以与任意服务器通信
  • 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL

WebSocket 是一个持久化的协议，相对于 HTTP 这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的 PHP 生命周期来解释

HTTP 的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次 HTTP 请求就结束了

在 HTTP1.1 中进行了改进，使得有一个 keep-alive，也就是说，在一个 HTTP 连接中，可以发送多个 Request，接收多个 Response。但是请记住 Request = Response， 在 HTTP 中永远是这样，也就是说一个 Request 只能有一个 Response。而且这个 Response 也是被动的，不能主动发起

你 BB 了这么多，跟 WebSocket 有什么关系呢？ 好吧，我正准备说 WebSocket 呢

首先 WebSocket 是基于 HTTP 协议的，或者说借用了 HTTP 协议来完成一部分握手

场景再现：

scss
客户端：啦啦啦，有没有新信息(Request)

服务端：没有（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：没有。。（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：你好烦啊，没有啊。。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：好啦好啦，有啦给你。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：。。。。。没。。。。没。。。没有（Response） —- loop

long poll ​

ong poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起请求后，如果没消息，就一直不返回 Response 给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

场景再现：

rust
客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）

服务端：额。。 等待到有消息的时候。。来 给你（Response）

客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。

何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起

从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的

ajax轮询 需要服务器有很快的处理速度和资源。long poll 需要有很高的并发，也就是说同时接待客户的能力

所以 ajax轮询 和 long poll 都有可能发生这种情况

undefined
客户端：啦啦啦啦，有新信息么？

服务端：正忙，请稍后再试（503 Server Unavailable）

客户端：。。。。好吧，啦啦啦，有新信息么？

服务端：正忙，请稍后再试（503 Server Unavailable）

WebSocket ​

通过上面这两个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源

一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高

哦对了，忘记说了 HTTP 还是一个无状态协议。通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍

所以在这种情况下出现了 WebSocket 。他解决了 HTTP 的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改

repl
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）

服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）

客户端：麻烦你有信息的时候推送给我噢。。

服务端：ok，有的时候会告诉你的。

服务端：balabalabalabala

服务端：balabalabalabala

服务端：哈哈哈哈哈啊哈哈哈哈

服务端：笑死我了哈哈哈哈哈哈哈

这样，只需要经过一次 HTTP 请求，就可以做到源源不断的信息传送了

gRPC ​

RPC，全称Remote Procedure Call，中文译为远程过程调用。通俗地讲，使用RPC进行通信，调用远程函数就像调用本地函数一样，RPC底层会做好数据的序列化与传输，从而能使我们更轻松地创建分布式应用和服务

TIP

在启用之前，请确保源站支持gRPC。不启用gRPC时当前网站会自动恢复为普通网站

WebP ​

选中后表示开启自动WebP压缩；图片的宽和高均不能超过16383像素；只有满足 [缓存条件] 的图片内容才会被转换；最小缓存时间为：7200秒

image-20250405003052219

TIP

匹配条件请严格配置，否则不生效，配置也会导致报错，无需求不需要开启