cloudflare

起因是本想用套一下 cloudflare 的 cdn，后来发现 cloudflare 有很多折腾的地方，现将原文从 cdn 配置扩展成我目前已知的好用的东西

cloudflare

R2, 对象存储服务
Worker，提供 serverless functions，我理解是一个简易后端，而且可以定时 trigger，目前我是用作纸飞机的机器人
Pages，提供网站部署，可以连接仓库，自动构建

在看文档的时候，顺便发现快速新建仓库的方法
KV 为 Worker, Pages 提供键值对存储服务，类似 Redis
Queues 为 Worker, Pages 提供消息队列服务，要钱
D1 为 Worker, Pages 提供数据库服务
Hyperdrive，把区域数据库变为全球分布数据库，没看懂，要钱
AI 利用 Worker 快速创建生成式 AI 模型
R2 OSS，对象存储服务
Stream，视频上传，存储，编码啥的，没看懂，要钱
Images, 存储，优化，分布图片，要钱
Area 1，电子邮件安全，要钱
Zero Trust 本意适用于公司安全的，相当于团队的 VPN（设置整体的网络策略），可以搭配 Warp 使用，利用 Tunnels 还可以实行无公网 IP 的内网穿透。搭配 Warp 还可以实现其他用途，当然肯定不稳就是了。
websites 挂到 cloudflare 上的网站管理
- DNS
- Email，自建邮局
- SSL/TLS
- Security
  
  WAF: 指定规则配置 blcok, interactive challenge, 限速等
  
  BOts: 机器人策略，免费版可以 challenge 一些常见的恶意机器人
  
  DDos：
  
  JS Challenge：运行脚本来判断
  
  Interactive Challenge：点击 checkbox，图片测试等
  
  Managed Challenge：由 Cloudflare 根据特点来选择 Challenge
Speed，设置一些相关优化

推荐设置就行，我目前是所有能打勾就打勾，没测试优化效率
Cache，设置缓存

Browser Cache TTL，浏览器的缓存

Cache Rules, 可以配置缓存规则，如果是整个域名的缓存见 Rules

Cache Reserve，看样子是在 Origin 和 Edge 之间又加了一层缓存
Worker Routes，将请求路由到 Worker 上
Rules，上面都是整体的设置，这里可以根据设定的规则条件设置上面的配置

还可以起到 rewrite url, modify request header, modify response header, redirect

根据 url 配置细致规则
Network

注意这里有一个 websocket 配置
traffic 都要钱
Scrape Shield 保护网站上的内容
Zaras，可以给网站添加第三方工具，有个 Google Ads 和 Google Analytics4，有时间用用

cloudflare cdn

被自己蠢哭，在 http 域配置 ssl_reject_handshake on;，最后没测试，导致今早调试，一直以为是 cloudflare 的问题。

害，废了一早时间。

dns 解析中的小黄云代表 proxied，可以说是一种 cdn 手段，用户先访问 cloudflare 服务器，如果没有缓存才会访问源站。

这里和普通的 cdn 不同，普通的 cdn 还需要配置加速域名（即最终暴露给用户的域名），而这里加速域名必须不能和源站域名相同。一个用于直接访问，一个用于回源。

而 cloudflare 通过小黄云，直接接管源站域名，改变 dns 解析结果（前者 dns 解析结果未变，所以加速域名和源站域名不能相同！），所以加速域名和源站域名是默认相同的。

所以是否小黄云成功，可以通过 dig 命令查看最终 dns 解析 IP 是不是 cloudflare 的 ip 来判断。
SSL/TLS 中的 4 个模式

以下可以手动实操，建议用 curl -L -v xxx 来查看结果。
1. off
  
  注意这里的 off 并不是不做任何操作，而是会把任何前端 https 请求重定向为 http 请求。
  
  此时如果你在源站 Nginx 设置了 http 请求重定向为 https 请求，就会重定向死循环。
  
  client 发出 https 请求，cloudflare 重定向为 http 请求发送给 server，server 返回重定向，cloudflare 返回重定向。
  
  client 向重定向的 http 发出请求，然后死循环。
  
  如果开启了这个，edge certificates 下的 always use https 选项也会被 cloudflare 隐藏掉（还挺智能）。
2. flexible
  
  注意这里的 flexible 前端允许 https 请求（是允许，前端不会重定向 http 请求），即相比之前不会在前端重定向了。
  
  但是所有 cloudflare 和 server 之间都必须是 http 请求。
  
  也就是说如果在源站 Nginx 配置了 http 重定向为 https 请求，会重复上面那个循环！
3. full
  
  前端允许 https 请求，后端允许 https 请求。
  
  具体表现为，前端请求为 http，后端就请求 http；前端请求为 https，后端请求 https。
  
  注意这里的简介描述有问题，简介描述 origin server 和 cloudflare 使用自签证书。但实际上受信任的 CA 颁发的证书也可以！
  
  如果你选择此方案并想要使用自签证书，那么可以在 origin server 页面配置一个 15 年的，生成成功后，注意在 Nginx 中也配置好这个自签证书。
4. full(strict)
  
  相比 full 只是多了对源站证书的要求。
  
  要求后端证书必须是受信任的 CA 颁发的证书，不能再是自签证书。
  
  这里注意的是同一个域名可以同时有多个受信任的 CA 颁发的证书，也就是说你可以自己用 certbot 签发一个，然后还同时使用 cloudflare 给你的。
注意配置以上 4 个选项时，注意是否开启 always use https。
如果开启了小黄云模式，那么 Nginx 自己配置域名证书可以说是没必要的。因为你所有通过域名访问都会经过 cloudflare（因为 dns 解析都变了），在前端都通过 https 加密好了。所以懒人配置且能保证 https 的方案：不配置证书，开放 80 端口，选择 flexible 模式。

如果你觉得 cloudflare 和 server 之间 http 连接不安全。

那么可以选择 full 然后自签证书或受信任 CA 颁发证书；full(strict) 受信任 CA 颁发证书。
通过域名访问网站查看证书发现是 cloudflare 里面给你颁发的 edge certificate 而不是你 nginx 中配置的那个。
edge certificate 最终返回给 client 的证书，只要挂了小黄云，并且要使用 https，则必须有这个。免费版只能使用 cloudflare 给你的证书。
client certificate 配置 client 和 cloudflare 之间的自签证书。如果没特殊要求就不用。
origin certificate 配置 server 和 cloudflare 之间的自签证书。如果想让 server 和 cloudflare 之间启动 https 传输，并且使用自签证书，就在这里配置。
miexed content errors

在 https 加密传输的页面请求了 http 资源。

注意这个错误是因为浏览器在请求资源之前检查请求协议是否为 https 来判断的。

也就是说普通的 Always Use HTTPS 解决不了这个错误（请求之后才会重定向）。
SSL/TLS Recommender

不会改变现有设置。作用是在 cloudflare 在检测到可以有更强的设置时，发邮件提醒你可以使用更强的设置。
Automatic HTTPS Rewrites

当请求的 http 资源能通过 https 访问时，cloudflare 替你自动替换为 https 资源。

也就是说这个改变是发生在 cloudflare 返回具体的内容时会重写资源链接（比如说返回一个 html，发现里面有对 http 的引用，就在返回之前，把 http 引用改为 https 引用）。
Always Use HTTPS

始终将 http 请求重定向为 https 请求。