Posts

原理 项目参考开源的 dani-garcia/vaultwarden: Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs 将Rust源码编译为WASM以支持在Cloudflare Worker上运行。其中Worker负责REST API，D1负责存储加密后的数据 部署 首先确保你安装了Rust，若无可前往： 安装 Rust - Rust 程序设计语言 克隆仓库： afoim/warden-worker: A Bitwarden-compatible server for Cloudflare Workers 创建D1数据库 wrangler d1 create warden-sql 替换 wrangler.jsonc 的数据库ID 初始化数据库 wrangler d1 execute warden-sql --remote --file=sql/schema_full.sql 编译Rust WASM cargo build --release 部署 Worker wrangler deploy 设置白名单邮箱 wrangler secret put ALLOWED_EMAILS 设置JWT（脸滚键盘即可） wrangler secret put JWT_SECRET wrangler secret put JWT_REFRESH_SECRET 设置2FA加密密钥（32字节Base64编码文本） ...

引言 接简介 这个时候我们实际上是需要将那个错误提交的文件在所有Git提交上抹掉，并且逻辑自洽 当然，如果你不嫌麻烦或者仓库提交本来就很少，你可以一点点的手动重写Git提交历史。又或是将历史提交合并为一个提交，强制推送 但是，这些方法要不太磨人，要不不优雅 假设这个仓库有1000+提交又不想合并所有提交历史呢？ 正式开始 有个PIP包正好可以满足我们的需求， git-filter-repo pip install git-filter-repo 安装后，进入你的Git仓库运行，接下来，我们只需要传一个文件路径给它即可 –path 是传入的文件路径，可以是相对路径也可以是绝对路径。但是注意，要用 / 分割路径 –force 是让它忽略安全性条件（如必须是一个刚克隆的仓库） –invert-paths 是反选路径，也就是 剔除 指定 –path 的文件 执行后它会查找该文件所在仓库的所有提交，并仅将该文件剔除，若某一提交中仅对该文件做了更改，则一整条提交直接消失（因为提交中无文件更改）；若某一提交中除了对该文件做了更改，还有其他文件，则该条提交仍然存在，但是文件变更记录中不再有该文件 git-filter-repo --force --path src/secret.txt --invert-paths 比如这里我们一不小心提交了个 微信密码 我们可以用该命令将其 剔除 git-filter-repo --force --path 微信密码.txt --invert-paths 可以看到，效果非常拔群， 微信密码.txt 已经不翼而飞了 但是还有个问题，就是我们曾经的 提交文本 暴露了 我们曾经曾上传过微信密码相关的文件 ，虽然实际上文件已经被剔除了 那有没有办法把这条提交删掉呢？有的，兄弟有的 我们可以使用原生的 git rebase ，以该提交作为 基点 ，将后续提交接在该提交上，这样就可以 架空 该提交。宏观来看，我们就在Git仓库中从 中间 删除了一条提交 首先，我们需要获取该提交的 哈希 ，这里假设为 4e19d1fc6af5119cb33128a92d5d4e80fc42e6ef （仅需前8位即可） 接下来，使用变基命令 git rebase --onto 4e19d1fc^ 4e19d1fc 这里会报错并自动中断变基进程，Git表示该提交有些文件和当前的提交冲突，无法自动解决冲突 ...

原理探寻 由于 Umami 使用的是 SSR ，我原以为EdgeOne Pages不支持该模式，尝试部署后发现最大的问题在于 Error: SSR functions package size exceeds 128MiB limit (157MiB) 也就是说，EdgeOne Page是支持SSR程序的，只是Umami构建后的函数太大了，那么我们的思路就很清晰了，只需要裁切一些代码即可 那么该项目就应运而生了 afoim/umami: Umami is a modern, privacy-focused analytics platform. An open-source alternative to Google Analytics, Mixpanel and Amplitude. 我将Umami v3中的无关紧要的东西，如 像素统计 链接统计 团队 地理位置文件 删去了，最终可以在EO上部署一个残血版的Umami 至于数据库，我用的是 https://supabase.com/ 需要注意，连接方式不能用 Direct Connection Demo： Umami 视频： https://www.bilibili.com/video/BV1JiqSBaEY1/ 唯一的缺陷，无法获取用户地区（原逻辑有个高达60M的本地Geo文件） 上手部署 Fork 该仓库 [afoim/umami: Umami is a modern, privacy-focused analytics platform. An open-source alternative to Google Analytics, Mixpanel and Amplitude.](https://github.com/afoim/umami-edgeonepages/tree/main) 连接到EdgeOne Pages，但先别点部署 填写环境变量 DATABASE_URL 从Supbase中拿，类似于 postgresql://postgres.kupggtyqiaepzvjqbboy:[YOUR-PASSWORD]@aws-1-ap-northeast-1.pooler.supabase.com:5432/postgres 绑定你的域名，访问并登录。用户名： admin | 密码：umami 疑难解答 内部重定向貌似出了问题，如果你想要访问设置更改你的管理员密码请手动前往 /settings/preferences 他们解决了这个问题，但是… ...

静态网站能不能被打死？ 首先，先给结论： 如果你托管在 Cloudflare Page ，那确实不用担心，因为它既不对静态请求计费，自身的CDN网络也足够强大，只要不是一天一PB，都是稳如老狗的 但是，如果你托管在 EdgeOne/ESA 等计费平台，是 可以被打死 的 有人就会问了： 我都是静态网站了，源站都没有，怎么能被打死呢？ 是的，你的确没有源站，静态网站也不计请求数，但是如果你任何防护都不配，所有人，或者说所有IP都可以批量刷取你站的流量，一天刷个几TB。几天后，CDN方可能就会给你取消接入了 那么我们要解决的问题也就明晰了，其实跟动态网站一样，本质就是： 让网站尽可能服务真实用户 。只不过对于动态站，这是为了 防止源站被打死 ，而对于静态网站，是为了 CDN看到大额流量 如何做WAF？ 首先，如果你使用的CDN是国内节点，就直接拦截海外访问 因为大部分刷子的IP都来自海外（大陆IP金贵），直接拦截可以很好防止大文件被刷取，如图片等。我就是个例子 其实做好这一步，你已经 99% 不会被刷死了，因为海外刷子本来可以刷 100~1000KB不等的图片，但现在只能刷 拦截页面 了（一般不到 5KB ），而一般拦截页面没有太多信息，甚至有些平台能自定义拦截页面，使其返回空报文（小于1KB） 假如原本刷子可以拿 十万个 IP刷死你，而现在刷子需要 100 * 100000 个 IP才能刷死了 ，这无疑是个指数级别的增长，并且你还是静态站，刷死你除了让业务停机，你也不会收到任何账单，大部分刷子会放弃刷站 接下来我们仍然可以配置额外防护，比如 速率限制，全局JS质询 等，这些都是针对于真实访客无感的验证 对于 速率限制 。真实访客不会进你站疯狂按F5短时间刷大量请求 对于 JS质询 。真实访客是用 浏览器 访问的，而不是 curl wget okhttp httpx 等无JS执行模块的轻 请求发生器 访问的，所以建议开启全站JS拦截 接下来才是重磅的，如果你的站被刷特别严重，尽管在L7全拦截住了，但是流量还是止不住的被刷刷刷，那就不要犹豫，关闭CDN的 HTTP 2.0 这是什么原理？我们都知道，在HTTP 2.0，引入了 连接复用 ，也就是在一个TCP连接里面可以发很多HTTP请求，这无疑降低了攻击成本 经过实测，关闭HTTP 2.0后，攻击者从1分钟刷50G暴跌到了10分钟刷5G 视频： https://www.bilibili.com/video/BV1paryBeEbP/ 总结：如何成为最耐刷的网站？ 拦截海外 所有请求JS质询（注意不要质询到API） 设置速率限制 关闭CDN的HTTP 2.0 奇技淫巧 ESA禁海外访问 针对于ESA，免费版用户可能无法设置区域限制 ...

正式开始 [!CAUTION] 抢占型实例在高峰期可能会进行回收，不要跑生产业务 [!NOTE] 下文都是以 阿里云国内版 演示的，注意在国内版按量付费业务需要账户内可用余额要 >=100 CNY。国际版无限制，但是要海外手机号+海外卡，有可能还需要KYC 下载Alpine镜像 由于我们主要的成本在硬盘上面，所以呢为了极致压缩空间，我们需要一个非常小巧的Linux镜像，以便我们可以用1G的 ESSD 云盘来安装。如果你也是极致玩家，仅用1G盘装系统，那么一定就要用我下面给你的Alpine镜像 如果你财大气粗，不在乎，或者说想跑一些正常业务，想用Debian或Ubuntu，那就10G起步，也不需要自定义镜像了 Alpine 60M镜像链接 https://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/alpine-virt-3.23.2-x86_64.iso 将镜像上传至阿里云OSS 由于我们需要自定义镜像，但是镜像又必须要通过OSS提供，所以我们需要临时性的创建一个OSS Bucket实例，来上传我们的ISO镜像。在实例成功创建后，我们可以将其删除，以避免不必要的扣费 首先，来到 OSS管理控制台 ，创建一个 Bucket，地域一定要选中国香港 ，并且上传ISO，最后，复制URL备用 导入镜像 前往 云服务器管理控制台 ，选择右上角的 导入镜像 注意需要授权ECS访问OSS业务 然后正常填写，取消勾选“导入后执行检测” ，先不要点下一步 接下来勾选配置云盘属性，并且将 云盘容量设置为1GB ，确认无误，导入 创建ECS抢占型实例 前往 云服务器管理控制台 ，创建 中国香港 实例，注意红框区域要保持一致 另外，对于 网络及可用区 ，香港一共有 B、C、D 三个区，D区比B、C区贵不少，可以都开开测个速，留下最好的 开通CDT 前往 云数据传输 将升级状态全部变为已升级即可 创建&绑定弹性公网IP并且挂上CDT 因为弹性公网IP可以绑定CDT的每月200G免费流量，并且在绑定实例后，弹性公网IP将不会再扣费。如果后续删机的时候不要忘记释放弹性公网IP，否则会一直扣费 进入 专有网络管理控制台 如图选择，然后购买即可（这里显示的费用是纯持有不绑定的费用，一旦绑定就不计费了） 接下来绑定弹性公网IP（因为我绑定过了，所以是解绑） 接下来在这里绑定CDT，带宽最高可以拉到 2000Mbps，但是不推荐，一般300M够用了 配置Alpine 如果你安装了Alpine，默认是需要VNC进入手动配置系统的。如果是公共镜像，则已经可以用了，但不要忘了保证系统纯净 进入 云服务器管理控制台 选择你刚买的ECS，接下来点击 远程连接 ，展开更多，选择 通过VNC远程连接 接下来就是愉快的敲命令环节~ （方括号内为默认值，你可以输入新值回车覆盖也可以直接回车应用默认值） ...

前言 首先，EdgeOne是来的最早的，于25年7月就开始测试了，而ESA是10月才开放的。 虽然EdgeOne在早期需要兑换码换免费套餐，而兑换码从早期的发推特然后找官方领码，再到Discord群组每天固定时间发码，最后到测速分享直接拿兑换码，门槛逐渐放低，功能逐渐齐全。 而ESA由于是后来者，直接给每个阿里云账户发了一个免费的ESA套餐，如果你有多站点接入的需求，也可以通过拉人头来得到更多的免费套餐。 就当前（26年1月）来说，两家的体验大差不差，但是EdgeOne和ESA的底层逻辑是有点区别的。 底层逻辑对比 EdgeOne这个项目，特别是Page，在24年就已经初具雏形并且能够像那些大厂如Cloudflare Page，Github Page，Vercel等静态托管平台一样使用了，但是当时一是腾讯是悄咪咪上的，二是节点实在是太烂了，只有海外新加坡节点，也不支持国内节点。 而ESA大概率是从老的DCDN和云函数FC改过来的，控制台就已经露出鸡脚了。 规则引擎与WAF ESA的很多东西直接是照抄Cloudflare的，比如： 并且还将每条规则（嵌套子规则也算一条）全部砍了一刀，免费套餐仅支持5条规则。 EdgeOne 的优势 反观EdgeOne，它没有照抄Cloudflare，而是自己写了一套规则引擎，所有类型的规则都在一处地方配置，并且可以互相联动。 甚至你还可以对不合法请求在L7给空。（不推荐，规则引擎的假拦截也算正常请求） 优先级陷阱 并且要注意一点，虽然你可以在规则引擎里伪装一个WAF拦截，但是在EdgeOne中，流量会先经由规则引擎，再经过WAF，也就是如果你在WAF写了个非CN拦截，然后在规则引擎里写个非CN给空，海外IP访问只能看到空响应，看不到拦截页面，流量也照记（难绷）。 ESA 的策略 而ESA这边，WAF的优先级始终是最高的，流量会先被WAF网关审查，通过后才应用规则，但是免费套餐不支持在WAF中设置地域级别的拦截（难绷）。 曲线救国方案 但是有个曲线救国的方案，就是先写个规则将流量全拦截，然后再写个白名单规则，将可信流量绕过该规则。 回源配置 再接着就是因为ESA照抄Cloudflare，所以创建加速站点的时候默认是HTTP走80，HTTPS走443回源，如果你要更改回源的端口，还需要浪费一个回源规则。 而EdgeOne可以在创建站点的时候直接就设置回源端口以及回源Host。 SSL 证书签发 再到SSL签发，首先两家都支持默认的CNAME签发，也就是你把域名解析到我这，我帮你签SSL，但是EdgeOne的CNAME签发是每一个站点单独签一次。 而ESA是统一管理，你给我个DCV，我直接给你签一个泛域名，之后你就用去吧。 规则隔离与互通 然后就是最重磅的，EdgeOne独属的左右脑互搏时刻。 在EdgeOne CDN和EdgeOne Page中，他俩的规则竟然不是互通的，CDN业务走CDN的规则，Page的规则走Page的规则，也行吧，他想做干湿分离，我配两套没问题。 功能阉割 但是！阉割是什么意思，为什么CDN可以写地域判断，Page就只能写IP？ 那么也没有什么让Page吃上CDN规则的方法呢？有的，兄弟有的（但是这样会在控制台看到双倍流量，如果你的Page纯静态，可以写个全缓存缓解一下）。 Page 服务对比 接着到Page部分。 EdgeOne的Page你可以直接看作是Cloudflare Page的本地化，甚至突破了核心代码，直接可以在Page里面跑Nodejs服务，要知道，Cloudflare Page也只有一个V8环境（Umami也可以！SSR函数小于等于128MB即可）并且可以托管海量大和多的文件。 而ESA Page非常像云函数FC改过来的，虽然也支持函数吧，但没有完整的Nodejs环境，甚至最近WebSocket也被砍了（关闭后就打不开了），并且托管的文件数以及单文件大小如下限制。 速度与限速 最后就是速度相关，根据多方数据以及自测，两个CDN都会在长时间的单IP上下行请求逐渐将速率削减至大约 500KB/s，但如果只是正常业务使用，短时间的突发速率都可以飙到50MB/s左右（但不能长期），所以这俩CDN都不适合反向代理对象存储以及大文件分发，如果有类似业务需求还是老实用Cloudflare，CF是不限速的。 ...

前言 原本这篇内容更适合写进仓库的 README，因为它本质上就是一个简洁的自部署教程。不过在实际整理时，我发现如果强行拆成 GitHub Pages + Cloudflare Worker 的前后端分离方案，反而会增加不少额外工作。实际上，这个项目只需要一个 Cloudflare Worker 就能跑起来，所以干脆单独写成一篇文章，方便说明整体思路。 项目原理 这个项目和上一篇短链项目的思路比较接近，不过整体做得更精简一些。 首先，这个项目把前后端逻辑合并到了同一套体系里。前端基本不做复杂校验，主要校验工作都放在后端处理，这样就不用在两个项目之间来回维护规则。 由于前端部分非常简单，只有两个 HTML 页面（一个用于创建短链，一个用于跳转），因此合并后也不会显得臃肿。 另外，这个项目不再依赖 Cloudflare 服务端提供的 301/302 重定向规则，因此也绕开了 2000 条静态重定向的数量限制。它的做法是：当 CDN 请求静态资源命中 404 时，回退到 404.html，再由其中的 JavaScript 负责查询短链规则并执行跳转，思路上有些类似 Nginx 的伪静态。 如果某个 pathname 没有命中任何规则，也会统一落到默认回退源，这样就能兼容类似 https://2x.nz/posts/pin/ --> https://blog.acofork.com/posts/pin/ 这样的场景。 创建短链的逻辑和上一个项目也比较相似：由 Worker 代理访问 GitHub，修改对应的 JS 文件并新增一条短链规则，然后推送到仓库。提交完成后会自动触发 Cloudflare Worker 的重新构建，稍等片刻后，新路径就能正常跳转。 最后，这个项目还支持有效期。实现方式也很直接：前端在创建短链时把过期时间一并传给后端，后端将其写入规则文件，再借助 GitHub Action 定时巡检并清理过期短链。 在哪搞个短链 我的 2x.nz 是在 https://porkbun.com 购买的，价格大概是一年一百元左右。其他后缀也可以考虑，比如 .im、.mk。 正式搭建你的短链服务 首先，Fork仓库 afoim/Static_Redirect_Group 接下来，先修改一些硬编码内容。由于 Cloudflare Worker 在处理静态资源时不能直接使用环境变量，因此部分信息是直接写在 HTML 里的。你可以在所有 HTML 文件中搜索 afoim 并替换成自己的内容；如果你愿意，也可以额外增加一层配置，并在构建阶段注入这些值。 ...

需分流的网站 博客本体，主站 https://blog.acofork.com Umami，用于在网站插入一个JS来进行访客统计以及展示访客信息 https://umami.acofork.com/share/CdkXbGgZr6ECKOyK 静态随机图，用于置顶文章Cover和整个网站的背景图 https://pic1.acofork.com 其他： https://acofork.com , https://www.acofork.com 这些都是要 301 重定向到 https://blog.acofork.com 的域名，我们也需要为其配置分流 各CDN SSL申请方案 EdgeOne 由于NS直接在EdgeOne，故直接申请 ESA 使用DCV委派 Cloudflare 使用HTTP验证，由于ACME验证节点在国外，所以它只会看到CNAME到Cloudflare的记录，从而签发SSL 针对重定向的域名，由于默认所有请求都会被重定向到新域，ACME自然无法验证，所以我们需要写一条排除规则，让ACME验证路径直接返回200 OK，其余的路径再重定向 源站类型 静态型 国内使用对应CDN的Page业务，海外使用Cloudflare Worker。至于为什么不将 blog.acofork.com 也放在EdgeOne Page，一是因为EdgeOne CDN和Page的WAF规则是分开的，而Page业务的WAF规则不是很好做海外封锁，二是因为EO在之前被打的时候将这个子域封了。而ESA Page可以很简单做到海外封禁 动态型 国内使用IPv6回源（用户 - IPv4 - EO/ESA CDN - IPv6 - 源站）。至于为什么不用ESA，是因为ESA CDN回源非标端口需要像Cloudflare一样写一条回源规则，占用免费规则集5条中的其中之一 海外采用Cloudflare Tunnel（用户 - IPv4 - CF CDN - 内部连接 - 源站） 浏览器客户端实现监看当前访问节点 利用浏览器JavaScript发送HEAD请求拿取对端响应头Server字段并回显（若跨域则需要设置 Access-Control-Expose-Headers 响应头，值为 server 注意事项 ESA Page对超多资源和大文件支持很差。例如静态随机图项目无法部署到ESA Page（超出了2000个静态资产） ESA CDN针对于回源非标端口和Cloudflare一样要通过写回源规则实现，很浪费规则，推荐使用EdgeOne CDN，可以随意指定回源端口 如果你要做分流业务，必须将域名NS托管在国内的DNS解析服务商，因为Cloudflare不支持域名分流解析，并且请将默认解析给CF，将境内解析给国内节点，不要反着来 分流的原理是DNS看查询的源IP，如果是国内则返回国内节点，海外则返回海外。也就是说你的出口IP决定访问的节点，若你开梯子（如美国），就算你在国内，访问到的也是海外节点 DCV委派只能写一条，如果你的NS在EO，可以写DCV给ESA，而Cloudflare使用HTTP验证，这一切都将是一劳永逸，全自动化的 Cloudflare SaaS 在接入外部域名时，非常建议选择 HTTP验证来签发SSL，下文会详细说明该验证模式的好处。我们都知道，Cloudflare SaaS 在创建的时候，对于申请SSL默认选项是 TXT验证，但是该方式并不好，我们都知道，使用TXT验证的确可以签发证书，但在3月后（上一个SSL证书过期后），我们需要及时更新TXT记录来重新申领新的SSL证书，但是HTTP验证就不是这样了，Cloudflare CDN会自动在边缘节点放上HTTP验证的文件，并且Cloudflare可以随时更改，这样，你就不需要在申领新SSL的时候做任何事情了，一切都由Cloudflare自动实现 Cloudflare SaaS接入外部域名后，对于该外部域名是可以享有所有Cloudflare单域名下服务（也包括Cloudflare Worker，参见： Cloudflare Worker 优选）。也可以配置规则等业务，你最终访问的是哪个域名就写哪个主机名，不要写回退源的主机名，除非你想让该规则仅在直接访问回退源时生效 ...

相关视频： 全解： https://www.bilibili.com/video/BV1QpSoBqERj SaaS原理：https://www.bilibili.com/video/BV1A5rpBqENh/ Worker/Pages优选：https://www.bilibili.com/video/BV1KNmtB6EU7/ R2优选：https://www.bilibili.com/video/BV115KLzSEiv/ Tunnel优选：https://www.bilibili.com/video/BV1WGMAznEBd/ 自建优选：https://www.bilibili.com/video/BV1H38vzoEcq/https://www.bilibili.com/video/BV1zpgBz7EHK/ [!tip] 所有优选一个域名即可，无需两个域名。如： s.2x.nz 和 s-s.2x.nz 即可完成优选 未优选 已优选 什么是优选？ 简单来说，优选就是选择一个国内访问速度更快的Cloudflare节点。 Cloudflare官方分配给我们的IP，在国内访问时延迟往往较高，甚至可能出现无法访问的情况。而通过优选，我们可以手动将域名解析到那些国内访问更快的Cloudflare IP，从而显著提升网站的访问速度和可用性。 从上面的对比图可以看到，优选过的网站响应速度有很大提升，出口IP也变多了。这能让你的网站可用性大大提高，并且加载速度显著变快。 要实现优选，我们需要做到两点：自己控制路由规则 和 自己控制DNS解析。通过Cloudflare SaaS或Worker路由，我们可以同时实现这两点，下面会详细讲解。 优选原理 首先我们要知道CDN是如何通过不同域名给不同内容的。 我们可以将其抽象为2层：规则层和解析层。当我们普通的在Cloudflare添加一条开启了小黄云的解析，Cloudflare会为我们做两件事： 帮我们写一条DNS解析指向Cloudflare 在Cloudflare创建一条路由规则 如果你想要优选，实际上你是要手动更改这个DNS解析，使其指向一个更快的Cloudflare节点。 但是，一旦你将小黄云关闭，路由规则也会被删除，再访问就会显示DNS直接指向IP——这就没法用了。 而SaaS和Worker路由的出现改变了这一切。 使用SaaS后，Cloudflare不再帮你做这两件事了，这两件事你都可以自己做了： 你可以自己写一条SaaS规则（规则层） 你可以自己写一条CNAME解析到优选节点（解析层） 使用Worker路由同理，你创建Worker路由规则后，DNS解析就可以随便指向任何优选节点了。 这就是为什么经由SaaS或Worker路由的流量可以做优选的原因。 选择优选域名 优选的核心就是选择一个国内访问速度更快的Cloudflare节点IP或域名。 传统优选域名 常用的社区优选域名：https://cf.090227.xyz 这些优选域名通常是通过扫描Cloudflare官方IP段，找出国内延迟最低的IP整理而成。 Cloudflare Byoip 优选 还在用传统优选？来看看Cloudflare Byoip！ 什么是Byoip？ Cloudflare Byoip（Bring Your Own IP），即如果用户自己拥有一个IP、IP段，可以将其托管给Cloudflare，并使其受益于Cloudflare全球网络的加速与安全。 人话讲就是，有一些IP不直接隶属于Cloudflare，但是我们CNAME到这个IP后仍然可以正常访问到我们部署在Cloudflare上的服务。这些IP可能并不是Anycast，但是国内延迟可能会明显优于Cloudflare的官方IP段。 如何找到Cloudflare Byoip？ 可以前往 AS209242 Cloudflare London, LLC details | Ipregistry 尝试使用ITDog强制绑定IP访问你的Cloudflare服务，不返回403即可。 我这里返回404是正常的，因为 r2.afo.im 直接连接到Cloudflare R2对象存储，直接访问就是404 ...

[!warning] 由于被DDOS，已经不再做分流监控，故本文诸多链接失效 正式开始 视频： https://www.bilibili.com/video/BV14dqwBVEa5/ 比如说我的博客 https://blog.acofork.com 它在国外的节点是 Cloudflare Page ，而在国内的节点是 阿里云 ESA Pages/EdgeOne Pages 我使用的方案是在国内自托管一个 Uptime Kuma 服务，而在海外使用一些大厂的云监控，如 BetterStack UptimeRobot 等等，并且让他们互相监控 对于大厂的监控，我们不必做防护，但对于你自托管的监控，推荐套 Cloudflare Tunnel ，防止被DDoS 国内监控： https://kuma.2x.nz 海外监控： https://vps.2x.nz 进阶：利用自定义HTTP请求头Host字段实现单节点分流域名的监控 如果你有个分流域名，正常来说我们需要两个监测源模拟国内和海外用户访问，但真的需要这么麻烦吗… 原理 CDN上托管了那么多的网站，那它是如何识别每个用户需要访问哪个网站的呢？ 针对 HTTPS ，CDN 会检查SSL握手报文中的 Server_Name 字段。而针对 HTTP ，CDN 会检查请求头中的 Host 字段 也就是说，对于海外CDN是否存活，我们可以通过直接访问CDN节点，如： http://blog.acofork.com.a1.initww.com 并携带上 Host 头指定为 blog.acofork.com ，从而强制指定节点访问业务网站，不走分流 那么如果CDN开启了强制HTTPS呢？那就关掉 常用CDN节点 Cloudflare：你自己的优选域名，如 http://cdn.2x.nz Github： http://pages.github.com 配置方法 部署一个Uptime Kuma（或者其他服务，监测源必须在国内。因为EO，ESA我们要做拦截海外策略） 如图写监测项目，直接使用HTTP协议监测CDN节点，并且携带Host头，将重定向设为0，只要返回 200 就算存活（为了减轻站点压力，建议使用HEAD请求） Demo https://status.acofork.com