前提

虽然阿茶在写网站的内容时，尽量会以文字进行描述，但是还是少不了会使用一些图片资源。但是，迄今为止，由于各种各样的原因，阿茶的图片总会时不时加载不出来或者是加载很慢。由于阿茶实在无法忍受图片在国内的加载速度，在查询了很多资料，拜读了各位大佬的blog后，终于决定将图片迁移到阿里云的oss中。

在一切配置完成之后，阿茶试了一下海外的加载速度，发现似乎不是那么得快。既然这样的话，阿茶就想到，似乎可以同时维护两套图床供海内外分别访问，问题来了，如何设置呢？

首先，阿茶用的是markdown写的文章，如果在网站端检测ip适配对应地址应该会很麻烦，可能需要去修改渲染器的源码，或者是去修改每一篇文章的文件，无论哪个操作都会耗时耗力。

那么阿茶就想到，是否能够在不改变现有文件中的访问地址，而是设置其他地方来达到这个目的。

阿茶现有的文章中所有图片链接都是以img.cha.moe开头，这个是使用了Cloudflare中的Page Rules进行的301重定向。

既然如此，那么就可以对这个重定向下手，对于不同的来源重定向到不同的图床地址即可。

在翻看Cloudflare查找如何设置的时候，阿茶看到了Cloudflare新出的Dynamic Redirects这个功能，看名称大概是阿茶想要的功能。于是阿茶便开始尝试了配置。

正文

普通图片

这个Dynamic Redirects在阿茶写下这篇文章的时候(2022-10-27)还是Beta版本，设置的方法在网络上更是少之又少。

不过阿茶在浩瀚的网络上检索后，终于找到了一丝丝线索，然后经过慢慢的摸索成功达成了自己的需求。

如上图所示，打开对应的设置，然后点击Create dynamic redirect按钮新建一个动态转发规则。

接下来就可以愉快（痛苦）的进行配置了。我没有找到官方文档（或许有，不过阿茶太笨没有找得到），所以小可爱如果看到这里可以跟着阿茶愉快的进行配置，阿茶已经为你扫清障碍啦。

这里阿茶希望的是访问一个图片地址，如这个地址：https://img.cha.moe/img/blog/article/others/20221027173636.jpg，在访问之后，如果用户的ip地址来自中国，就将其转发到阿茶的阿里云oss对应地址：https://cha-moe-blogimg-sh.oss-cn-shanghai.aliyuncs.com/img/blog/article/others/20221027173636.jpg。

注：这里阿茶没有将自己的阿里云oss地址以隐私方式呈现是因为就算我不说，小可爱也可以直接通过本站的代码找到，所以也没有关系。但是阿茶开启了防盗链，所以就算你拿到了这个地址大概也没有任何用，而且阿茶也关闭了直接访问功能呢，直接访问也是不可以的哦。

看到上图没有！接下来阿茶就要一点一点解释啦。

首先Rule name这个没什么好说的，起一个自己喜欢的名字就好。

然后就是图片中标号为①的地方，这里展开之后你会发现很多很多选项，阿茶这里选择了Hostname这个选项。

这里需要解释一下，Field中的Hostname选项代表的是域名主体，比如一个链接https://img.cha.moe/img/blog/article/others/20221027173636.jpg，这里指的是对应的img.cha.moe，和后面的路径/img/blog/article/others/以及文件名称20221027173636.jpg都没有关系。

然后第二个Operator选项设置为了equals。这里代表的意思就是完全相等。其实如果稍微熟悉编程语言的话，这里大概就是==、!=、include、exclude等作用。

接下来就是图片中标号为②的地方，这里就是逻辑上的与和或，因为阿茶需要判定地区和上面的域名是并列的关系，因此这里选择了And。

然后就是图片中标号为③的地方，这里阿茶选择了Country，代表地区，后面Operator和Value的地方设置的含义就是来源于中国。




接下来就是重头戏了。




在图片中标号为④的地方，这里按照阿茶最初的理解，就直接设置为了Dynamic，但是看到后面的参数位置却由地址变成了表达式。

于是阿茶尝试改回了静态(Static)，填入地址。

这里阿茶真的不知道填什么了。

如果小可爱有用过Page Rules的配置，那么大概你会在Hostname那里填上img.cha.moe/*，而这里填上https://cha-moe-blogimg-sh.oss-cn-shanghai.aliyuncs.com/$1。

为什么我会知道呢？因为没有文档和参考内容的情况下，阿茶就是这么干的。

这里没有什么提示设置上的错误，于是阿茶迫不及待的去输入地址尝试。

结果，结果却打开了google的dns查询页面。因为使用Cloudflare的page rule需要将对应的hostname（这里是img.cha.moe）设置一个A记录，而阿茶设置的刚好是8.8.8.8。那也就是说，阿茶的这个设置没有生效，于是Cloudflare就真的将该请求按照A记录进行了转发。

那么问题来了，如果这样设置不正确的话，那应当如何设置呢？

经过不懈的努力（指找资料），阿茶在下方的参考链接中找到了答案。

这里应当设置为Dynamic，然后表达式需要设置为concat("https://cha-moe-blogimg-sh.oss-cn-shanghai.aliyuncs.com",http.request.uri.path)。

找到这个答案后，大概就能够明白是什么意思了。concat函数代表的是将多个参数合并成为1个。

至于后面的参数，代表什么意思呢？这里最初阿茶也不知道，但是试了一下能够成功，于是阿茶就这样不求甚解的完成了设置。（才怪，后面其他需求还是涉及到了这个部分，所以这里稍微透露一点剧情，这个东西叫做Fields reference，Cloudflare的文档中有对应页面）

后面的301（永久转发）就不用多说了吧，如果小可爱还不知道的话建议自行使用搜索工具哦。

这个是针对国内的设置，设置好后就可以点击蓝色按钮保存并启用了。

接下来，针对国外的设置大同小异。

不过需要注意的是，Country的Operator阿茶设置的是does not equal，代表的是除了中国之外的所有地区。

还有就是最下面的转发地址需要设置为对应的国外的图床地址。

特殊图片

由于阿茶在使用友链的时候，设置的地址也是使用了img.cha.moe作为开头的地址，而最初使的图床是有缓存的，这就导致阿茶最开始在换头像的时候，由于缓存机制的存在，阿茶一直无法成功更新其他小可爱网站上的友链的阿茶的头像（定语真长）。虽然有一个解决方法就是去找各个小可爱更新一下友链信息，但是这样也太麻烦他们了。

所以，本着不麻烦别人的原则，阿茶决定自己尝试解决问题。

其实在使用Page Rule的时候，阿茶就用掉一个规则来解决了这个问题，那就是将这个地址https://img.cha.moe/img/blog/favicon/*转发到对应的github上的放置头像的地方https://github.com/chmoe/cdn/raw/master/img/blog/favicon/$1。

可是在有了上面的教训之后，阿茶知道不能够这样进行配置，于是按照上面的方法“正确的”进行配置后却发现了问题。

当阿茶尝试访问https://img.cha.moe/img/blog/favicon/avatar.svg这个头像地址的时候，不但没能够成功跳转到对应的地方，还跳转到了过去使用的图床（有缓存的那个）于是阿茶看到了过去的头像。

在仔细研究之后阿茶才理解，是因为没有匹配到刚刚这条规则，于是就匹配到了第二条规则，也就是来自海外的请求，于是匹配到了最开始的图床，自然而然按照目录就访问到了这个原来的头像。

但是，当阿茶无论如何都不知道该如何配置的时候，无意间想到了刚才配置时候的时候那串http.request.uri.path神秘代码，看大概意思是能够理解是获取访问地址的路径(也就是域名之后，文件名之前的这串字符串)。

阿茶在网络上检索后，找到了Cloudflare的文档Fields reference。这里详细介绍了各种各样的神秘代码代表着什么。

于是阿茶突然意识到，自己在Field中选择的Hostname对应的其实不是阿茶想象的域名+路径，而是只是域名（阿茶这个小傻子最开始还明白，后来随着配置的深入慢慢变得忘记了）。

也就是说阿茶需要比较的不是域名本身，而是整个url地址。因此这里应该选择的不是Hostname，而是URI Full。因为阿茶不需要匹配其他规则，所以这里就直接写到了文件名。

下面的匹配规则这次自然是选择了静态(Static)，因为不需要拼接，而是直接对应文件的转发。

于是结果就变成了下图。

当然，这里完全没有必要配置那么多的匹配规则，这些规则只是阿茶在没有将Hostname选项改成URI Full时不断尝试的结果（留在这里只会显得阿茶非常非常的笨蛋）。

在写完这段话之后才发现截图中的是设置了四个equals，这里大概是因为将Hostname选项改成URI Full时自动恢复了默认值，阿茶最开始设置的四个状态是equals、contains、start with、end with，阿茶近乎疯狂的尝试了各种匹配规则，嗯，不用小可爱吐槽，阿茶真的是好笨啊w

那么，这篇文章就算是水好了。

参考

Definitive Guide on Cloudflare Redirects