Cloudflare 提供了包括域名托管、重定向等在内的丰富、强大的免费层级服务功能，并且非常易用。使用 workers 搭建代理，cloudflare 之前虽未禁止，但明确不提倡，最新的服务协议已经修改、确定了了一旦检测到代理行为就封禁账户的条款。本文及后续文章会逐步介绍 cloudflare 的众多免费服务功能，深度挖掘、分享 cloudflare 免费计划的所有内容。Cloudflare 免费服务众多，但访问受限，不折腾直接用机场，「嘀嗒云」新年特惠开启中、最低 55 折，作者一直稳定使用，不妨一试。
示例场景
这里我们以关闭旧站 a.com，启用新站 b.net 为例。场景是出发点，换个场景，动、静态重定向选择和规则就会有所不同。
在哪里配置
如果是较为普遍的旧站迁移至新站，应该在旧站点域名处进行配置。因为是对旧站域名进行配置，只需要将旧站域名托管于 Cloudflare 并开启代理。
如何配置
新站上线，旧站内容已同步转至新站，但并非所有读者、观众已更新新站域名，也不希望再保持旧站的运行，此时适合采用全站跳转方式。全站跳转的基本逻辑是 old-domain.com->https://new-domain.com，状态码 301，只需针对旧站域名（old-domain.com）设置重定向规则。
我们可以使用动态重定向，也可以进行静态重定向，如果是上述旧站关闭、全站跳转至新站首页的需求应使用静态重定向。
配置要点
首先，如上图，在页面规则卡片应该选择右侧的『重定向规则』。在『重定向规则』则应该选择『重定向到其他域』。
在创建重定向规则界面，对于本文关闭旧站 a.com、启用新站 b.net 的场景，应该使用静态重定向而非动态重定向。同时，确保选择『所有传入请求』，因为旧站 a.com 即将关闭，不再保留任何内容，仅仅是保留了域名，以便老用户失联或迷路。
接下来，在 Cloudflare 中的单一重定向选择『所有传入请求』后，将所有针对旧域名（旧站）的请求全部跳转新站，如此也不必在旧站（a.com）或新站（b.net）进行不必要的公告。
关键的是，需要将重定向类型选为『静态』，URL 为 https://b.net 或 https://b.net/。如果选择『动态』，需要对新站 nginx/apache 进行额外配置。原因在于 cloudflare 动态规则必然会添加“*”作为任意路径或参数的占位，而静态站点会将“*”作为字面量的星号，也就会出现经典的“*!=*”问题，导致 404。
例如，动态重定向规则使用表达式 concat( “https://b.net“, "/")，跳转后的地址栏 URL 会是 “https://b.net/*”，"*" 对于新站（b.net）而言，不是通配符，而是路径或文件名。
静态重定向
- 是一个简单的 1:1 映射
- 直接将一个特定 URL 重定向到另一个特定 URL
- 不会处理或保留任何原始请求的路径参数
动态重定向
- 使用表达式引擎（如 concat()）
- 会尝试保留和处理原始请求的路径
- 默认会将原始请求的路径附加到新的 URL 后面
至此，最简单也最常见的重定向配置就完成了，确保新站运行正常即可，不必再担心旧站（a.com）和老用户的访问习惯了。对于很多单页应用（SPA），如发布页、落地页、个人静态博客等，使用静态重定向就足够了，不需要使用动态重定向。
其他
作者并不建议对于旧站（a.com）保留任何功能，多台主机的系统运维一定更复杂繁琐。但是，也有可能无法一步到位，在这种情况下，就需要使用动态重定向规则，并且将动态重定向规则置于上述静态重定向规则之前。例如，保留旧站（a.com）的部分功能作为后端，就需要提供/保留 API 接口，通过版本号区分新、旧站， 配置使用动态重定向规则 a.com/api/v2/* -> https://b.net/api/v2/$1 ，对 a.com 的直接访问 URL 和帖子永久链接不需要任何调整，仅通过类似 “/api/v2/”的 URI 区分出对新站的访问。
一般情况，通过页面规则完全可以满足普通站点间的重定向配置。但是，更为复杂的重定向需求就需要使用 cloudflare workers 了。
更多精彩，敬请关注「老E的博客」！
文章评论