垂死病中惊坐起，爬虫偷走了你的信息 ww!

可能就是很单纯的… 把邮箱… 放在简介，然鹅就算 202X 年了还有人靠电子邮箱发广告和垃圾邮件，虽然眼不见心不烦，哎爬虫怎么这么坏

就是这些坏东西的方法很多… 真的很多，古早时候就有把 @写成 #的邪法，就以上面那个 Demo 为例，它本身就自带 cloudflare 有形的大手，首先，cf 会编码 "可能是像电子邮箱的东西"，任何能够执行 js 的浏览器会自动解码它，更别提人机验证了，直接把目录填进安全规则托管质询

不过能 "折腾就折腾"，有没有什么更神奇的方法，不依赖现有的基础设施，而且很方便？有的有的，这是工作量验证

原理

这种工作验证基于 AES,ChaCha32 等对称加密算法和一串摘要值，密码被故意设计成弱口令，这使得用户可以靠猜测比对推出密码

在个别 pow 验证码中也提供了这类小组件，为了效率，通常使用 WASM，JS 好写

因为是反爬虫所以也不需要很高强度的防护，大战 GPU 这种（X）

简单实现

找哈基米写的，就很舒服 (√)

弱口令的产生方法是公开的，为了防止预先推出就加上了一串公开的 uuid 合并为一个 key，加上了一些改进

用来反爬也没什么问题

↑ Demo

从 [菜鸟教程] 零基础 Cloudflare 优选教程 继续讨论:
之前看到有佬友问本优选是否有为一些地区 / 运营商配置特定的节点.
其实 saas.sin.fan 一开始就有为特定的城市配置特定的节点，例如海南移动，电信东北地区…

经过测试，部分 DNS 无法正确返回我们的 GeoDNS 配置，以下是兼容性列表.
列表较长，可以使用 ctrl+f 快速跳转到你使用的 DNS.

阿里云 (saas.sin.fan 的托管服务商):

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

腾讯云:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

Google:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

Cloudflare:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

OpenDNS:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

114.114.114.114:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

360:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

百度:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

字节跳动:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

CNNIC:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

OneDNS:

• 此服务商可以根据运营商返回对应的节点
• 此服务商可以根据省级地区返回对应的节点
• 此服务商遵循 saas.sin.fan 配置的节点权重设置

上篇搭了个 HTTPS 入口，这篇继续部署 CLIProxyAPI 作为 API 网关，让 Claude Code 能用上更多模型。

架构

走 Cloudflare 橙云代理，源站跑 Docker。

部署

写了个一键脚本：CLIProxyAPI AWS EC2 一键部署脚本・GitHub

准备工作：

• EC2 能 SSH、有 sudo

• Cloudflare DNS A 记录指向 EC2 IP，开橙云

• 安全组放行 2096

执行：

 # 下载脚本 mkdir -p ~/cli-proxy && cd ~/cli-proxy

curl -fsSLO https://gist.githubusercontent.com/xrf9268-hue/18c81e1c5225aa2e6541a52deeabbe82/raw/cli-proxy-setup.sh

curl -fsSLO https://gist.githubusercontent.com/xrf9268-hue/18c81e1c5225aa2e6541a52deeabbe82/raw/cli-proxy-config.yaml

curl -fsSLO https://gist.githubusercontent.com/xrf9268-hue/18c81e1c5225aa2e6541a52deeabbe82/raw/cli-proxy-docker-compose.yml

# 执行安装 chmod +x cli-proxy-setup.sh

./cli-proxy-setup.sh install --domain your.domain.com

脚本会自动装 Docker、生成自签证书、随机 API Key、拉镜像起服务。Key 会打印在屏幕上，记一下。

Provider 登录

部分 Provider 需要 OAuth 登录。回调端口只绑 127.0.0.1，得用 SSH 通道。

 # 开通道（保持不关）

ssh -L 51121:127.0.0.1:51121 <user>@<host>

# 在通道里执行登录（以 antigravity 为例） sudo docker compose -f ~/CLIProxyAPI/docker-compose.yml exec cli-proxy-api ./CLIProxyAPI --antigravity-login --no-browser

会输出授权链接，本地浏览器打开、登录、授权完成。

Claude Code 配置

 export ANTHROPIC_BASE_URL="https://your.domain.com:2096" export ANTHROPIC_AUTH_TOKEN="你的key" export ANTHROPIC_DEFAULT_OPUS_MODEL="gemini-claude-opus-4-5-thinking" export ANTHROPIC_DEFAULT_SONNET_MODEL="gemini-claude-sonnet-4-5-thinking" export ANTHROPIC_DEFAULT_HAIKU_MODEL="gemini-claude-sonnet-4-5" 

测试：

 # 用 jq 格式化

curl "https://your.domain.com:2096/v1/models" -H "Authorization: Bearer 你的key" | jq

# 或用 python

curl "https://your.domain.com:2096/v1/models" -H "Authorization: Bearer 你的key" | python3 -m json.tool

能返回模型列表就成了。

原公益节点帖子

mihomo (clash) ECH 订阅地址

这个地址仅供测试，它无法改动，只支持 mihomo (clash) https://download.nature.qq.com/SnsShare/Windy/1768620180_b65eb5ff_ech-mihomo

前言

公益节点的域名，用的人一多，就会被墙，我注册了好多域名，也死了一堆，在不断抗争中不断头大。

抗封锁的进展

这几天在 TG 群里看到 CMLiussss 更新了 v2ray/mihomo/singbox 一些 ECH 相关的功能。

ech 是什么？

ech 就是把你真实访问的目标加密传给 cloudflare，
但是 cloudflare 能解密真实目标，对外只知道你往 cloudflare-ech.com 连接。
全球大量免费的 cloudflare 套餐都强制开启 ech，
墙如果杀掉 cloudflare-ech.com 会导致大量误伤。
所以目前看还是挺稳的

存在的问题

但是 sing-box/xray/shadowRocket（小火箭) 等软件，需要固定的 ech 密钥，cloudflare 的 ech 是四个小时一变，就算要做订阅，也是需要设置 4 小时更新一次，用起来不是很方便。

推荐的方法

mihomo (clash 系列的继承者) 能自动抓取 ech 密钥，非常方便。

订阅里依然使用 sni.111000.de5.net 这个被大部分地区屏蔽的域名，但不影响使用。

推荐客户端

安卓端：ClashMetaForAndroid v2.11.22 Releases · MetaCubeX/ClashMetaForAndroid · GitHub

苹果端：clash mi ‎Clash Mi App - App Store

PC 端 / 路由器 (nikki)，基本都能更新内核，更新到 v1.19.18 及以上版本即可。

引言：加入 L 站以来，小白也算是慢慢折腾，了解机场 VPS 等一系列网络基础设施概念后，尝试自己当一回赛博工人，借鉴大伙的智慧，手把手从里到外开始建站，装点一下属于自己的博客。再就是自己在 L 站也水了太多，没有自己的产出，督促自己写一篇文档，记录自己折腾的日子。整篇文档仅供参考，望大家轻喷。

参考资料：
1.[教程] Cloudflare 单域名 SaaS 优选教程。让 Cloudflare 不再成为中国减速器，最低延迟低至 10ms!
2. 菜鸟教程零基础 Cloudflare 优选教程
3.0 成本 10 分钟用 Cloudflare + GitHub + Astro 搭建一个全球秒开、永久免费的顶级个人博客

技术栈简要

• 博客托管：Netlify（稳定、免费、支持 Astro SSR）
• 优选传输：Cloudflare SaaS（免费证书、自定义主机名）
• 智能分流：DNSPod（国内优选，海外直连）

当然整个搭建过程也不是一帆风顺的，在我看来并不是按照大佬们的操作指示，一步一步来就会成功，这其中涉及到许多概念的理解，感谢新时代的 AI 技术为我答疑解惑。接着来分别阐述一下为什么选这些技术栈，具体技术就不做介绍了，这里着重说明为什么选 A 而不选 B 此类的问题。

整体流程

[ 用户浏览器]
      |

      | 1. DNS查询: "主站在哪?"

      v[ DNSPod 智能解析 ]  | |

      | (国内用户)                      | (境外用户)

      | 2a. 返回【优选IP】              | 2b. 返回【官方Anycast IP】

      |    (来自 saas.sin.fan)         | (来自 cloudflare 回源域名)

      v                                v[ Cloudflare 边缘节点 ] <================================+ |

      | 3. 携带请求头: Host: 主站

      |    识别 SaaS 证书, 建立加密连接 (TLS)

      |

      | 4. 触发 Fallback Origin (回源后备)

      |    通过内部骨干网转发至: 回源域名

      v[ Netlify 目标服务器 ]
      |

      | 5. 匹配 Domain Alias (域名别名)

      |    确认 Host: 主站域名是“自己人”

      |

      | 6. 读取 Astro 构建的静态文件 (dist)

      |    返回数据 (且不触发 301 重定向)

      v[ 用户浏览器 (成功渲染) ] 

用简单的词汇描述一下整个过程，总的来说需要四个域名，其中两个是我们自己准备并托管的（A 和 B），另外两个分别是第三方服务分配或者维护的（C 和 D），我们只需要拿来用即可：

• 主域名 A（店面招牌）：相当于你经营了一家店，大家记住了你的店名，全世界的人都根据这个店名来访问，只提供了一条引路的作用，在资源访问等涉及效率方面没有优化
• 回源域名 B（内部通道）：托管在 Cloudflare 上（后文简称 CF ），因为 CF 在世界范围内有大量机房（距报告说的是每天 20% 的流量都会从它家走，还是很恐怖的），加上 Anycast 技术可以让你接入延迟最低的 CF 网络。由于主域名 A 不在 CF 托管，CF 默认不让进门，于是需要一个 “内部员工” B 来为 A 担保，相当于访问 A 也可以走 CF 专线了
• 优选域名 C（专业导航）：由三方大佬维护，既不存博客内容，也不管店名，作用是每天都去看哪条路接入 CF 是最快的，然后把这些最快的路告诉你们，实现绕过公网堵塞，实现秒开
• pages 域名 D（内容仓库）：在各种平台站托管时会给你分配一个 pages 域名，这是真正存放博客网站源文件的地方，只负责把网页内容通过回源域名 B 输出去

总结：数据怎么跑的？

1. 用户看你的招牌（A）
2. 招牌（A）根据导航（C）的建议，把用户引向最快的 CF 大门
3. 大门（CF）看到是自己人（B）担保的请求，立即放行
4. 大门内部通过专线去仓库（D）获取网页内容
5. 原路返回用户

博客托管

这里解决的是博客存储在哪的问题，刚开始时我以为博客文件都要存在 VPS 服务器上，然后请求的数据流是 [主机 → VPS]，后来我才发现静态博客大多采取第三方托管的方式，这里比较有名的托管服务有 Cloudflare Pages, Netlify, Vercel, GitHub Pages 等等。

首先尝试了 Cloudflare Pages，但 Cloudflare Pages 的问题在于，不托管在 Cloudflare 上的域名无法添加到 Pages 主页的自定义域名，具体情况如下图所示。

Cloudflare Pages 行不通，就去看看别人家。由于我搭建博客的时候阅读了 Astro 的官方文档，其中建议我在 Netlify 进行托管，后续的操作中我也就这么做了，整体没有遇到 Cloudflare 那样不认域名的问题，在此不赘述有关 Netlify 具体如何托管博客站，文档非常明白。

图：Astro 官方推荐的托管方式

图：在 Netlify 托管可以手动添加三方域名

优选传输

为什么采取两个域名分开托管的方式？

这是由 CF 自己的托管逻辑决定的，一旦你开启了小黄云托管，CF 会自动接管域名流量，分配一组 Anycast IP，但在 CF 内部，用户是无法修改这一部分的 IP 的，也就是说无法根据外部线路实现动态优化，在大陆内的访问无法得到保障。

在这样的情况下，引入 CF 的 SaaS （Custom Hostnames）服务，即使我们的主域名不在 CF 托管，只要有一个回源域名在担保，也可以给主域名访问提供加速和 SSL 证书。

主域名在 CF 外，我们可以自己定义 DNS 怎么解析，分线路优化。回源域名在 CF 内，保留了海外访问加速通道。

具体到我的情况，我的主域名是在阿里云购买的，然后在 DNSHE 免费申请了一个.de5.net 的域名当回源，藏在后面的域名，不用太好看，能用就行。

图：DNSHE 免费域名

下列为托管的具体步骤，参考了 MIYUSAMA 的贴菜鸟教程零基础 Cloudflare 优选教程，自认为非常详细了，几乎一模一样，有不懂的可以问问 Gemini 等 AI，然后实在不知道的，我有空看到了也会回复大家。

智能分流

一开始我的主域名托管在阿里云上的，毕竟就是从阿里买的，平台的技术力也毋庸置疑，但是用着用着发现，阿里云 DNS 解析没办法指定海外线路，这一点在分流的时候影响还挺大的。相比而言，同样免费套餐的腾讯 DNSPod 默认有海外线路解析。

图：阿里云免费版不支持选取境外解析线路

图：DNSPod 解析列表有境外解析选项

DNS 托管迁移很简单，以我从阿里云托管到腾讯为例，首先找到腾讯的 NX 服务器，一般来说是一对，然后填入阿里云的 NX 服务器配置就行了，这一步的作用是，腾讯告诉阿里，我拿到了这个域名的解析权，后面你就不用管了。

优选结果

图：优选前，DNS 解析权托管在 CF 上

优选后，DNS 解析托管在 DNSPod 上，加速线路分别交给 CF 和 saas.sin.fan (看起来好像没什么变化)

失败的尝试

cloudflare 优选域名加速个人博客求助

L 站很多帖子是对子域名进行优化，技术路线是：CF 回源域名 + CF Pages + 主域名阿里云解析，这一套方法在我尝试下来行不通，原因和前文提到的一样，无法将托管在其他平台上的主域名，加入到 Pages 的自定义域名列表中。

Gemini 给出过解决方案，重写 rules 或者 用 workers，主要思路是改 Host 头为主域名，但实际没有成功过，只能访问回源域名，然后主域名解析不到内容，我猜测原因是在同一个 CF 账号下，Pages 的自动路由策略会干扰 SaaS 的手动回源策略，导致回源域名根本拉不动 Pages 的内容。

图：Gemini 的胡说八道

结束语

技术在于折腾，看起来好像没啥提速效果，但是从整个网络数据流走向，以及架构方面，我有了很多新的收获，也感谢 L 站的各位积极分享！

全新版本，可能有点问题（但我目前没发现）如果有的话麻烦佬友提 issue 或者 pr 了

大致使用就是接入 OIDC 后，
首先新建渠道

然后创建个配置，定义一下模型输入和输出格式就好

然后添加以下渠道

如下是一些配置项：
Cursor 自带的 Opus-4.5 带 thinking 的模型名称为
claude-4.5-opus-high-thinking
不带 thinking 的叫
claude-4.5-opus-high

其中响应处理器 [“thinkingTags”] 的作用是将响应的 reason 转为 content 中的 … ，如此就能在 Cursor 中展示思考内容

仓库地址：GitHub - NickJerome/tiny-ai-api-hub

虽然最后的目标是想实现 Claude Code 也可用（测了下好像可以，但是感觉哪里怪怪的）

主要用来解决纯前端发起 api 请求时的 cors 跨域问题，直接透传给目标 api

支持在线调试，为了防止大串 base64 干扰，Body 里会显示高亮占位符，真实请求时自动替换为图片 base64

参考：

• 使用 he.net 获取近乎无限且永久的域名 - Lim's Blog
• 免费 17 级域名，无需续期可托管 CloudFlare | 玖玖小博客
• ip6.arpa 签发 SSL 教程

省流：

1. 去 https://tunnelbroker.net 创建隧道
2. 解析 ipv6/64 地址，得到一个很丑的 *.ip6.arpa 域名
3. 前往 dash.cloudflare.com ，添加域名，激活
4. 回到 https://tunnelbroker.net ，查看隧道，找到下面的 rDNS，把 cf 提供的 Nameserver 填进去，一共两个，点 Save
5. 片刻后，去 cf 手动触发一次激活验证，刷新几下
   
6. 在 cf 复制 ZoneID、GlobalKey、你注册 cf 的邮箱地址，在终端执行 (出处)：

curl --location --request PATCH 'https://api.cloudflare.com/client/v4/zones/<你的区域ID>/ssl/universal/settings' \
--header 'X-Auth-Email: 你的CF注册邮箱' \
--header 'X-Auth-Key: 你的CF全局APIKey' \
--header 'Content-Type: application/json' \
--data-raw '{"enabled":true,"certificate_authority":"ssl_com"}' 

更换 SSL 证书签发商（仅在 cf 有效）
7. 这样你就得到了一个很丑的 17 级域名
8. 关于 “无限” 的玩法：使用 he.net 获取近乎无限且永久的域名 - Lim's Blog

理论上讲，只要是支持 ipv6/64 rDNS 的都可以

玩玩即可，不要滥用，滥用会封号

The hostname is part of a banned domain. This web property cannot be added to Cloudflare at this time. If you are an Enterprise customer, please contact your Customer Success Manager. Otherwise, please email abusereply@cloudflare.com with the name of the web property and a detailed explanation of your association with this web property.

已经被 cf 拉黑了…

注：优惠券 30 天使用期限
注 2: 可以免费 push, 开号与注册域名几乎无限制

之前的 eu.cc. 可以托管到 cf 了

域名邮箱注册就能领三张免费注册 eu.cc 一年的优惠券，应该是不能用来续费，手机号地址随便填就行，可托管到 cloudflare

上集回顾：[公益 + 开源] BetterClaude：更流畅的 Claude 使用体验，代理公益站如 Anyrouter

1) 更新重点：结合 Axisnow GTM 做 “智能路由再优化”

这次升级的核心，是把入口域名做成全局调度 + 边缘执行的架构：

用户依旧只需要记一个域名，但系统会按地区把流量调度到更合适的节点。

Axisnow GTM 文档（可复制）：自建 CDN 并优化中国访问 | AxisNow Docs

架构图

架构解读

1. 入口层 (Entry Layer)
   • 用户始终访问统一顶级域名：betterclau.de
2. 全局调度层 (GTM Layer)
   • betterclau.de 通过 CNAME 将 DNS 解析权转交给 gtm.betterclau.de
   • 这层是 “大脑”：根据用户来源 IP（地理位置 / 运营商特征）做初步分流
3. 执行 / 边缘层 (Edge Layer)
   • 默认 / 海外路径（紫色）：大多数地区 → cf.betterclau.de → Cloudflare
   • 优化 / 国内路径（绿色）：大陆→ jp-01 / hk-01 等优化节点（国内线路更优，降低 RTT / 丢包）
4. 安全
   • 如果 JP 和 HK 节点受到攻击，系统会停用亚太 CDN 节点，回退到 CF 节点来进行防御。

简单说：用户只访问一个入口，但 “入口会自己把你送到最适合你的那条路上”。

2) 使用方式

方式 A：开源自建

• 仓库：GitHub - AkideLiu/betterclaude-workers: BetterClaude API Gateway
• 部署：看 README（只需要一个 Cloudflare 账号）

方式 B：直接用现成服务（最简单）

规则非常简单：在原域名前加 BetterClaude 前缀即可。

Claude 代理

格式：https://betterclau.de/claude/{host}

示例（anyrouter）：

原站： https://anyrouter.top
加速： https://betterclau.de/claude/anyrouter.top

OpenAI 代理（0.1+）

Chat Completions：
原站： https://api.openai.com/v1/chat/completions
加速： https://betterclau.de/openai/api.openai.com/v1/chat/completions

Responses API：
原站： https://api.openai.com/v1/responses
加速： https://betterclau.de/openai/api.openai.com/v1/responses

Gemini 代理（0.1+）

格式：https://betterclau.de/gemini/{host}/{path}

示例（Gemini 官方）：

原站： https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent
加速： https://betterclau.de/gemini/generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent

Gemini CLI 多种登录方式里，我只测了 API Key。Google Account / Vertex AI 是否完全可用不确定，欢迎经常用的大佬反馈。

3) 运行统计 + 加速地址直达（12/25–1/5）

公益站信息：https://linux.do/t/topic/1354149

统计时间：从 BetterClaude 上线 2025/12/25 到 2026/01/05 截止。

说明：

• 成功率仅供参考，数据量可能因配置错误、速度测试等导致不准确
• 速度测试接口会固定返回 401，可能影响成功率
• 部分公益站通过 BetterClaude 的使用量不大，样本偏少
• 如有公益站长不希望允许使用 BetterClaude 的服务，可以私信我。我会在 WAF 上面直接阻断对应域名。

DNSHE 为全球开发者、学生和开源爱好者提供免费域名服务 ：
✓ 无需信用卡绑定
✓ 无隐藏费用
✓ 支持全类型 DNS 记录解析
✓ 即时上线各类数字项目
https://my.dnshe.com

・初始额度：可注册 3 个域名

选择后缀，开始注册

注册后登录 CloudFlare
https://dash.cloudflare.com/login
加入域，输入域名 → 选择 Free 套餐 → 继续前往激活

选择免费计划

回到 DNSHE 配置

配置 DNS 将下列的内容复制进去
margaret.ns.cloudflare.com
nikon.ns.cloudflare.com

继续前往激活

任务完成

开发者可以在本地环境，通过 Web 端管理和交互 Cloudflare 资源。

功能点：

* D1 Database Studio：浏览数据库表、运行 SQL 查询（带语法高亮）、编辑/增删数据行。
* KV Browser：查看、编辑和批量删除键值对 (Key-Value)，支持 JSON 格式。
* R2 File Manager：类似于对象存储管理，支持浏览、上传、下载和删除存储桶中的文件。
* Queue Inspector：监控队列消息，并支持发送测试消息。
* Durable Objects：查看活跃的 DO 实例并检查其状态。
* Zero Config：自动读取项目中的 wrangler.toml 配置文件。

〇. 前言

文本教程面向建站新手，因此会跳过一些对新手来说难以理解的信息，也会不厌其烦的讲解一些重要内容。如果你认为本文过于笼统，说明本文不适合你.

本文默认你已经完成了 Cloudflare 的接入部分。如果你连接入 Cloudflare 都不会，本文对你来说没有意义，请退出.

一。接入了 Cloudflare, 我的网站就不怕 CC/DDoS 了吗？

先说结论: 并不是 , Cloudflare 的五秒盾 (交互式质询 / JS 质询) 是可以被绕过的.
通常情况下，Cloudflare 会给通过质询的浏览器下发一个名为 cf_clearance 的 cookie, 同子网 (/24) UA 下的请求可以携带这个 cookie 直接在有效期内跳过质询。意味着攻击者可以在第一次请求时使用真实浏览器进行过盾，之后则直接进行自动化请求.

同理，还有更多方法绕过 Cloudflare 的五秒盾。这里不再赘述.

二。自助的付费计划对我来说有用吗？

付费计划会提供更好的 TTFB, 以及更多的功能。以及 Cloudflare 托管的 WAF 规则。可根据自身网站的体量做取舍.

注：如果你只是单纯想优化用户到边缘的连接速度，你其实并不需要购买付费计划。有关这部分内容，请参考 [菜鸟教程] 零基础 Cloudflare 优选教程 - 开发调优 - LINUX DO.

三。基础的 WAF 规则配置.

从这里开始就是正式的配置教程了.

转到 Cloudflare 域面板中的 安全性 / 安全规则 下，本章节的操作会在这里进行.

1. 为已知机器人跳过之后的 WAF 规则

创建自定义规则，

找到 已知自动程序，配置为是 (开)

当然，你也可以手动选择允许的机器人类别。你可以在 此处 看到所有经过 Cloudflare 验证的机器人和其类别.

往下滑，选择操作为跳过，注意放置位置一定要放到第一个

完成后点击保存.

2. 为你的 API 创建跳过规则

如果你的网站没有需要外部服务器 / 用户调用的 API, 可以跳过此步骤.

新建一个自定义规则，请根据你的 API 路径，方法 自行修改示例规则中的内容

此段规则的表达式为

(http.host eq "api.sin.fan" and 
http.request.uri wildcard r"/api/pub/v1/users/*" and
http.request.method eq "POST")

如果要创建更多的路径，在该小节规则后接一个 OR 重复即可.

往下滑，选择操作为跳过，位置应该放在上一个已验证机器人跳过规则后.

请注意，这些 API 通常会被自动程序调用，因此还需要跳过 自动程序攻击模式.

3. 质询可疑的请求

这部分推荐还是自己写，这里给出几个建议.

A. 从 radar 获得 ASN Bot 流量占比，并对高流量占比的 ASN 进行质询

比如上面这些 ASN. 在之后我会单独提供一个现成的高 Bot 流量占比的 ASN 列表.

B. 质询使用旧版本 HTTP 的请求

此规则在我站点上的通过率仅为 0.07%

表达式为

(http.request.version in {"HTTP/1.0" "HTTP/1.1" "HTTP/1.2"})

X. 可选：质询所有第一次访问网站的请求

如果网站正在被攻击，可以使用此规则进行质询。此规则与 I'm under attack 模式的最大区别就是不会对 API 流量进行质询。因为 API 请求已经被之前的规则标记为跳过了.

表达式为

(http.request.uri wildcard r"/*")

4. 限速策略

创建一个限速策略规则，表达式为

(not cf.bot_management.verified_bot)

向下滑动，找到 当速率超过… 部分，
你需要根据你的网站自行调整设置。可以根据以下步骤进行配置:

1. 进入你的网站，按下 F12
2. 转到网络选项卡
3. 勾选关闭缓存检查框，按下 F5 刷新网页
4. 待页面加载完成后，查看下方的数据

我的网站一次访问需要 37 次请求，我假设我的用户会在 10 秒 内强制刷新 5 次 (ctrl+F5), 然后关闭缓存访问 5 个新页面，那么 10 秒 内的请求是 370 次。那么你应该在 请求 部分填写 370.

向下滑动，如果你是 Free 计划，你的操作只能选择 阻止 10 秒.
选择完成后点击保存.

四。托管规则调整.

转到 安全性 / 安全规则，选择 DDoS 保护 选项卡。创建替代

规则集操作修改为阻止

点击浏览规则，搜索 imp, 将操作全部改为阻止.

搜索 likely, 将仅有的一条规则改为阻止.

五。安全设置调整.

转到 安全性 / 设置，本章节接下来的操作会在此页面完成.
向下滑动，

找到 质询通过期 设置，默认为 30 分钟。你可以根据需求调整为更短或更长的时间。本文之前提到过，攻击者可以通过合法的 cf_clearance cookie 跳过质询，因此不推荐将该时间设置的特别长，通常情况下默认的 30 分钟已经足够了。如果你需要一定的安全性，可以修改为 15 分钟.

继续向下，你会找到 自动程序攻击模式 / 超级自动程序攻击模式.
Free 中，此设置默认为关。可以开启.
付费计划中，调整为如下设置

提一嘴：此检查聊胜于无。只能拦截一部分唐逼脚本小子的 CC. 甚至经过我的测试，一部分提供免费 CC 服务中基础的 HTTP SPAM 中部分请求 (≈30%) 都能得到较高的 bot score.

Free 中 自动程序攻击模式 的纯摆设，没啥作用.

付费计划中，Cloudflare 会根据 TLS 指纹，ja4/ja3, IP 在 Cloudflare 数据库中的纯净度计算出一个 bot score. 通常情况下，已知的自动化请求会得 1 分，也就是 绝对自动化流量 , 但是目前的绝大部分爬虫都能自定义 TLS 指纹，UA, 以及有不是那么脏的 IP 代理池。甚至 itdog 的部分节点进行 HTTP 测速都能得到较高的分数 (>1 分).
在 Pro 中允许对 =1分 的请求进行质询或阻止，Business 中允许对 2-29分 的请求进行阻止或质询.

六。速度优化

转到 速度 / 设置
点击启用所有可用设置。然后转到 内容优化 选项卡.

向下滑动，可以考虑是否开启 Cloudflare Fonts 优化。如同 Cloudflare 的介绍，这会内联并缓存 Google Fonts.

向下滑动，可以考虑是否开启 Rocket Loader 优化。此选项会异步执行你的 JS 脚本，从而加快页面渲染的速度。对 WP 站有奇效。但是此设置也有可能导致部分依靠 JS 脚本的功能损坏。你可以根据 Cloudflare 的文档 忽略单个脚本.

七。缓存优化

1. 配置

转到 缓存 / 配置

向下滑动，找到 浏览器缓存 TTL 选项，此设置影响一个文件在浏览器中的缓存时长。通常可以修改为更长的时间，例如 14 天 甚至更长.

向下滑动，找到 Crawler Hints 选项，设置为开.

2. 缓存规则

转到 缓存 / Cache Rules

新建规则，选择 缓存默认文件扩展名 模板，这些都是默认的静态文件，通常可以设置更高的边缘缓存 TTL 和 浏览器缓存 TTL.
设置完成后，点击保存.

默认情况下，cloudflare 不会缓存没有后缀名的文件 / HTML 文件，因此通常情况下，你不需要单独为 API 路径设置一个绕过规则.

3. Tiered Cache

转到 缓存 / Tiered Cache

设置为开.

八。规则修改

转到 规则 / 设置
修改设置如下

九. SSL 设置.

转到 SSL/TLS/ 概述

通常情况下，推荐设置为完全，你需要在源服务器上配置一个 SSL 证书 (推荐使用 Cloudflare 的自签名源服务器 SSL 证书).
为了安全，你还需要关闭服务器的 80 端口并限制 443 端口只能被 Cloudflare 的 IP 访问.
通常推荐在服务商防火墙进行设置，如果你的服务商没有提供防火墙，则直接使用服务器防火墙即可，以下是 ufw 命令示例.

sudo ufw allow from 173.245.48.0/20 to any port 443
sudo ufw allow from 103.21.244.0/22 to any port 443
sudo ufw allow from 103.22.200.0/22 to any port 443
sudo ufw allow from 103.31.4.0/22 to any port 443
sudo ufw allow from 141.101.64.0/18 to any port 443
sudo ufw allow from 108.162.192.0/18 to any port 443
sudo ufw allow from 190.93.240.0/20 to any port 443
sudo ufw allow from 188.114.96.0/20 to any port 443
sudo ufw allow from 197.234.240.0/22 to any port 443
sudo ufw allow from 198.41.128.0/17 to any port 443
sudo ufw allow from 162.158.0.0/15 to any port 443
sudo ufw allow from 104.16.0.0/13 to any port 443
sudo ufw allow from 104.24.0.0/14 to any port 443
sudo ufw allow from 172.64.0.0/13 to any port 443
sudo ufw allow from 131.0.72.0/22 to any port 443 

sudo ufw allow from 2400:cb00::/32 to any port 443
sudo ufw allow from 2606:4700::/32 to any port 443
sudo ufw allow from 2803:f800::/32 to any port 443
sudo ufw allow from 2405:b500::/32 to any port 443
sudo ufw allow from 2405:8100::/32 to any port 443
sudo ufw allow from 2a06:98c0::/29 to any port 443
sudo ufw allow from 2c0f:f248::/32 to any port 443 

转到 SSL/TLS/ 边缘证书
向下滑动，开启 始终使用 HTTPS 选项。修改 最低 TLS 版本 为 TLS 1.2.

至此，本文教程就告一段落了。你已经完成了 Cloudflare 的基础设置.