专栏/「扩展篇」使用Cloudflare的重定向规则传递资源路径和查询字符串

「扩展篇」使用Cloudflare的重定向规则传递资源路径和查询字符串

2024年08月29日 14:05--浏览 · --点赞 · --评论
粉丝:2235文章:77


关于本教程

在之前的教程中我们已经实现了使用Cloudflare的页面规则固定和隐藏

STUN穿透后的网页端口 链接


不过之前教程中的方法只能处理域名而无法处理资源路径和查询字符串

即重定向前链接中的资源路径和查询字符串不能继承到重定向后的链接中


这个问题并非不能解决 但想使用页面规则来解决 就有些困难

更好的方法是使用 重定向规则


相比起页面规则 重定向规则的设置和更新方法会更加复杂

但好处也是显而易见的 其拥有更多的规则容量和重定向方式

可以处理资源路径和查询字符串


当然如果没有传递资源路径和查询字符串的需求

还是使用之前教程中的页面规则会更加简单方便


建议在阅读本教程之前先阅读之前的教程


设置DNS记录及其解析

在设置DNS记录和解析方面和之前教程中的差不多

依然需要设置两组域名(子) 即重定向前的域名和重定向后的域名

链接


创建重定向规则

登录CF 》 点击侧边栏中的网站 》 选择你的域名 》 点击侧边栏中的规则 》

重定向规则 》 创建规则


规则名称任意填写 这里使用 stun-redirect

传入请求匹配 选择 自定义筛选表达式


以 ie12.com为例 使用时以实际域名加以替换

其中6666端口代表STUN穿透后的端口 之后会使用API进行更新


传入请求匹配:

  • 字段:主机名

  • 运算符:wildcard (通配符)

  • 值:*.ie12.com

如果希望某些二级域名不被该规则匹配 可以继续添加条件

按下后面的 And 再添加一个条件 关系为


字段依然选择主机名 运算符改为 不包含

值则填写不需要重定向的子域名 比如 blog.ie12.com


这样一来 输入请求的主机名以 .ie12.com结尾且不包括

blog.ie12.com 的请求会匹配上这一条重定向规则


URL重定向:

  • 类型:动态

  • 表达式:

  • 状态代码选择302

  • 勾选保留查询字符串

  • 保存规则


示例


表达式含义

这个表达式看起来比较复杂但是含义并不复杂

其将传入链接中的内容截取后拼接到新的链接中


wildcard_replace 表示将输入的内容以一定的规则进行截取

并组合输出新的内容

http.request.full_uri 表示传入的完整的URL


"*://*.ie12.com/*" 就是一个匹配规则

对传入的链接进行匹配 *的部分会被截取到变量中以供之后使用


而后面的 "https://${2}.stun.ie12.com:6666/${3}"

表示合成输出的内容 变量 ${2}  ${3}  为刚才存储截取部分的变量


图示

更新重定向规则

相比起更新页面规则 更新重定向规则要复杂一些


创建访问令牌


2024-09-21

CF对重定向的命名方式发生了改变
原先的动态重定向已经改为单一重定向



与此同时设置界面的描述也发生了变化 不过在设置方法上并没有变化


与更新页面规则时不同 要获取并更新重定向规则需要两组权限

创建令牌的前序过程和之前教程中的基本相同

请参考之前教程中的设置 链接


需要的权限如下:

  • 账户 》账户规则集 》编辑

  • 区域 》动态重定向 》编辑

示例


获取区域ID

在侧边栏的概况里面有显示

有了令牌和区域ID之后就可以开始获取规则集ID了


示例


获取规则集ID

与之前的教程中的相似 依然使用lucky计划任务中的

callweb功能进行获取

  • 接口地址:

  • 请求方法 GET

  • 请求头:

  • 开启 禁用接口调用成功字符串检测

  • 保存规则

示例


按下手动触发并查看日志中的返回结果

其中的 "http_request_dynamic_redirect" 即为重定向规则集

值得注意的是其ID是位于名字前面的 别看错了


示例


获取重定向规则ID

在获取了规则集中ID后就可以开始获取

重定向规则集中的规则ID了


  • 接口地址:

  • 请求方法:GET

  • 请求头:不变

示例


按下手动触发并查看日志中的返回结果

图中划线的ID即为重定向规则ID


示例


测试更新

在获取完上述的信息之后就可以开始更新重定向规则了


请求接口:

请求方式:PATCH

请求头:不变

请求主体:


上面的 expression 为匹配传入链接的表达式


而下面的 action_parameters 里的 expression则是

用于构建重定向后的链接的表达式 

可以直接从上一步获取重定向规则ID时返回的内容中复制出来


尽管其请求方法为PATCH 文档中也没有明确必填参数 应该只需要提交要修改的部分就行

但是实际测试下来 发现还是要填写完整的信息

不然会出现显示成功但实际上没有更新成功或部分项目被替换成某种默认值


图示


按下手动触发并查看日志中的返回结果

若设置正确即可看到返回的重定向规则信息中目标URL的

地址和端口号已经发生变化


示例

 

在STUN穿透中更新规则

与在计划任务中时基本相同

当然最重要的就将测试时使用的固定端口改为STUN规则里的变量


可以使用webhook手动触发测试进行验证

其会使用6666作为测试时的端口号


示例

关闭 禁用成功字符检测

填写下列内容用于判断请求是否成功

最终效果验证环节

在浏览器中输入 redirect.ie12.com/test/abc/search?q=123

应会跳转到 redirect.stun.ie12.com:STUN穿透端口/test/abc/search?q=123

(lucky反向代理服务的前端地址 似乎不会匹配查询字符串)


示例

参考:

  • Cloudflare API Documentation

    https://developers.cloudflare.com/api/operations/listZoneRulesets

  • Functions reference

    https://developers.cloudflare.com/ruleset-engine/rules-language/functions/#wildcard_replace

  • cloudflare 301重定向规则设置-Wood Chen

    https://woodchen.ink/archives/cloudflare-301-redirectional-settings-2eod9f


投诉或建议