让 CoreDash bot 顺利通过 CDN 或防火墙

在 CDN 或防火墙中放行两个 CoreDash bot

CoreDash 会通过两个 bot 访问你的网站：cRUM audit 和 uptime check。要充分发挥 CoreDash 的作用，CDN 或防火墙必须同时放行这两者。有时某些防护设置会拦截它们。本文介绍如何在 Cloudflare 和 AWS WAF 中配置一条规则，同时放行这两个 bot。

这两个 bot 各自的作用：

• cRUM audit。 在 CoreDash 菜单的 cRUM (beta) 下选择页面后，CoreDash 会像普通访客一样，在其 audit 服务器的 Chrome 中加载该页面，并指出拖慢速度的具体原因。它的 user agent 是 CoreDash/1.0 (audit; +https://www.coredash.app/bot)。
• uptime check。 CoreDash 每 30 分钟从自身服务器请求一次受监控的站点，并在站点宕机时发出通知。其发送的 user agent 为 CoreDash/1.0 (uptime; +https://www.coredash.app/bot)。

user agent 是浏览器或 bot 在每次请求时附带的自身身份标识。CoreDash 的两个 bot 均以 CoreDash/ 开头，规则只需匹配该前缀即可。

audit 或 uptime check 被拦截时的表现

防火墙或 CDN 检测到来自数据中心的访问，且 user agent 并非普通浏览器，就会将其判定为不可信 bot，并返回错误码或质询页面。两个 bot 对此的表现各有不同。

若 cRUM audit 被拦截，任务会直接终止并提示“Audit failed”，下方附带具体错误。另一种情况是 audit 照常运行，但测试的其实是拦截页：此时 Page load filmstrip 中显示的不是你的页面，而是质询或错误页，审计报告里的所有数值也全部属于该拦截页。

uptime 监控的状态会显示为 Blocked，其提示“A firewall blocks the checker”会列出检查收到的状态码以及拦截开始的时间。CoreDash 不会将受阻的检查计入停机时间，因此拦截不会拉低可用率数值。但在所有检查都被拦截的情况下，请求根本无法触达你的站点，监控也就无法在站点真正发生故障时发出通知。

当 Cloudflare 对每次 uptime check 均返回 403 时，example-shop.com 的监控页面。

防火墙如何识别 CoreDash

你只需在防火墙或 CDN 中为 CoreDash 添加一条例外规则，最常见的做法是匹配 user agent：一条针对 CoreDash/ 的规则即可同时放行 audit 和 uptime check。使用项目的 bot token 则更为严密，因为只有你自有项目的 bot 才会携带该 token。基于 CoreDash IP 地址放行仅作为兜底手段：当 CoreDash 增加或迁移服务器时 IP 就会变动，你必须自行手动维护 IP 规则。

具体需要为哪项设置添加例外，可查看防火墙日志。下一节会介绍 Cloudflare 日志的查看方式。如果使用 AWS WAF，请直接跳到下方的“在 AWS WAF 中放行 CoreDash（置于 Bot Control 之上）”一节。

排查 Cloudflare 中拦截 CoreDash 的功能

在 Cloudflare 中进入对应域名，前往 Security › Analytics，切换到 Events 标签页。在 Sampled logs 下，找到带有 CoreDash user agent 的请求。如果是高流量站点，点击 Filter，将字段选为 User agent，并填入完整的 user agent 值：uptime check 填入 CoreDash/1.0 (uptime; +https://www.coredash.app/bot)，audit 填入 CoreDash/1.0 (audit; +https://www.coredash.app/bot)。

点击该请求展开详情。Service 一行标明了具体拦截它的 Cloudflare 功能。

在 example-shop.com 上，Browser Integrity Check 拦截了此次 uptime check。

Service 行的内容决定了对应的解决方式：

• Bot fight mode：这是 Cloudflare Free 计划的 bot 防护功能，自定义规则无法对其配置例外。请直接跳到下文关于 Bot Fight Mode 的章节。
• 其他任何功能（如截图中的 Browser integrity check、托管规则或 Super Bot Fight Mode）：按下方步骤创建一条 Skip 规则即可。

在 Cloudflare 中配置 Skip 规则放行 CoreDash

Skip 规则会指示 Cloudflare 对携带 CoreDash user agent 的请求跳过指定的功能检查。该规则能同时覆盖 audit 和 uptime check，且适用于 Cloudflare 的所有计划。

1. 前往 Security › Security rules。在 Custom rules 下，点击 Create rule。

创建第一条自定义规则前的 example-shop.com Security rules 页面。

2. 将规则命名为 CoreDash。在“When incoming requests match”下方，点击“Edit expression”，在打开的文本框中粘贴以下内容：

   http.user_agent contains "CoreDash/"

点击“Edit expression”后的规则名称与表达式。CoreDash 后面的斜杠必须保留。

3. 在“Then take action”下选择 Skip，并选择 Cloudflare 对 CoreDash 跳过的检查项目。在“WAF components to skip”中，勾选“All managed rules”和“All Super Bot Fight Mode Rules”。点击展开“More components to skip”，同样勾选“Browser Integrity Check”。保持“Log matching requests”开启，以便后续在 Events 中查看规则生效记录。

操作选择 Skip，并勾选上述三个选项。

4. 点击 Deploy。如果域名下已有其他自定义规则，Cloudflare 会询问放置顺序：将其排在首位。

若此前没有其他自定义规则，无需调整顺序，直接点击 Deploy 即可。

5. 确认 CoreDash 已成功放行。下一次 audit 或 uptime check 到达后，Cloudflare 的 Events 会记录该请求，操作显示为 Skip。在 CoreDash 中检查你使用的 bot（或两者都查）。

针对 cRUM audit：在 cRUM (beta) 下重新选择该页面，或者刷新打开该页面的浏览器标签页，即可触发新的 audit。一旦成功放行，Page load filmstrip 就会逐帧展示真实页面在 Chrome 中的加载过程。

完成的 audit，帧图上标有 TTFB、FCP、LCP 和 CLS。

uptime check 无需手动操作：CoreDash 会在整点和半点自动检查，因此在 30 分钟内监控状态就会恢复为 Up，新的柱状条也会变绿。

example-shop.com 已恢复 Up 状态：此前有 38 次检查返回 403，规则生效后的每次检查均返回 200。

使用 CoreDash bot token 配置更安全的 Cloudflare 规则

任何人都可以伪造以 CoreDash/ 开头的 user agent，因此冒充 CoreDash 的恶意 bot 也能穿透 Skip 规则。项目的 bot token 是一串私密凭证：每次 audit 和 uptime check 都会在名为 X-CoreDash-Bot 的请求头中附带它。基于该 token 配置的规则只会放行你自有项目的 bot。

获取方式：在 CoreDash 中打开 Project settings，进入“CoreDash bot token”标签页（仅项目所有者有权访问）。如果监控状态为 Blocked，通知中的“View your CoreDash bot token”链接也能直接跳转过去。点击“Copy Cloudflare rule”，即可复制包含你专属 token 的完整表达式。

点击“Copy Cloudflare rule”会将包含 token 的表达式复制到剪贴板。

如果你之前已创建了 Skip 规则，进入 Security › Security rules 打开该 CoreDash 规则。将表达式中的 user agent 那一行替换为刚才复制的内容并保存。操作和已勾选的选项保持不变。如果尚未创建规则，按照上述 Skip 规则的步骤操作，在第 2 步中直接粘贴 token 表达式即可。

该 token 仅会发送给你项目自有的站点及其子域名。如果监控或 audit 的是其他域名的页面，请求中不会包含 token，因此那些域名仍需保留 user agent 规则。如果 token 不慎泄露，点击“Make a new token”即可。旧 token 会立即失效，生成后需尽快将新 token 更新到 Cloudflare 规则中。

Cloudflare Free 计划中的 Bot Fight Mode

如果 Events 中的 Service 一行显示为 Bot fight mode，请参考本节内容。

一次 CoreDash uptime check，Action 显示为 Managed Challenge，Service 为 Bot fight mode。

Bot Fight Mode 会对运行在云服务器上的简易 bot 发起质询，而在 Cloudflare 看来，CoreDash 的两个 bot 正属于此类。Cloudflare 官方文档指出，Skip 和 Allow 规则对其无效。因此处理方式只有两种：要么将其关闭，要么保持开启并放行 CoreDash 的 IP 地址。

关闭 Bot Fight Mode

前往 Security › Settings，按 Bot traffic 筛选。找到“Bot fight mode”所在行并关闭其开关。Cloudflare 随后将停止对全站此类简易 bot 发起质询。如果你仍希望保留这种防护，Pro 计划提供了 Super Bot Fight Mode，该功能支持 Skip 规则。关闭开关后，同样需要按照上文创建 Skip 规则，以免 CoreDash 随后被 Browser Integrity Check 或托管规则拦截。

Bot fight mode 的开关位于 Status 列中。截图中已处于关闭状态。

保持 Bot Fight Mode 开启并放行 CoreDash 的 IP 地址

开始之前请注意：这些地址并非固定不变。你填写的 IP access rules 是静态的，而最新的地址列表始终维护在 app.coredash.app/bot/ips.json。如果日后 CoreDash 再次被拦截，请先对照该列表核对你的规则。

IP access rule 允许特定 IP 地址绕过防火墙规则；一旦请求优先匹配了此类规则，Bot Fight Mode 就不会对其进行质询。前往 Security › Security rules，在 IP access rules 下点击 Create rule。如果 Cloudflare 建议将其创建为自定义规则，选择“No, go to IP access rules”。输入 51.195.222.219，操作选择 Allow，范围选择“This website”，点击 Create。每个地址创建一条规则：uptime check 对应 51.195.222.219 和 51.195.222.220，cRUM audit 对应 135.125.202.210。

每个 CoreDash 地址配置一条 IP access rule，针对当前网站（This website）设为 Allow。

完成任一修复后，按照 Skip 规则第 5 步的方法，验证 CoreDash 是否能正常通行。

在 AWS WAF 中放行 CoreDash（置于 Bot Control 之上）

在 AWS WAF 中，拦截 CoreDash 的通常是 Bot Control（AWS 提供的防 bot 托管规则组）。解决方法是为 CoreDash user agent 配置一条 Allow 规则并将其置于 Bot Control 之上，单凭这一条规则就能同时放行 audit 和 uptime check。此处的 AWS 截图来自专为本文搭建的 acme-aws.com 演示环境。

1. 在 AWS WAF 控制台中，打开站点的 web ACL（保护站点的规则集），进入 Sampled requests 标签页。点击某条请求的 URI 查看其请求头：CoreDash 请求的 user agent 以 CoreDash/ 开头。“Rule inside rule group”一列标明了拦截它的具体规则。

Bot Control 规则 SignalNonBrowserUserAgent 拦截了 acme-aws.com 上的 CoreDash uptime check。

2. 在 web ACL 页面中，点击 Add rules › “Add my own rules and rule groups”打开 Rule builder（新版 AWS 控制台中称为 Custom rule）。参照截图填写：创建名为 CoreDash 的常规规则（Regular rule），检查 user-agent 请求头，并 Allow 所有以 CoreDash/ 开头的请求。然后向下滚动表单并点击“Add rule”。

CoreDash 规则：Single header 为 user-agent，Starts with string CoreDash/，操作为 Allow。

3. AWS 随后会打开“Set rule priority”。选中 CoreDash，点击“Move up”直至其排在最顶端，然后点击 Save。AWS 自上而下执行规则，匹配到 Allow 规则的请求不会继续向下匹配，因此 Bot Control 根本不会处理 CoreDash 请求。

CoreDash 置顶，位于 Bot Control 规则组上方。

4. 验证 CoreDash 是否已顺利放行。在 Sampled requests 中，最新的 CoreDash 请求现在应该显示匹配了 CoreDash 规则，操作为 Allow。

acme-aws.com 上最新的 CoreDash 检查已命中 CoreDash 规则并成功放行。

在 CoreDash 中，按照 Cloudflare Skip 规则第 5 步的方法检查你使用的 bot：发起新 audit 后，Page load filmstrip 会展示你的真实页面；下一次 uptime check 之后，监控状态也会恢复为 Up。

与 Cloudflare 一样，使用项目的 bot token 能让该规则更加安全。具体原理及哪些站点会附带 token，参见上文关于 Cloudflare token 的部分。若要将 AWS 规则切换为基于 token 匹配：

1. 在 CoreDash 中打开 Project settings，进入“CoreDash bot token”标签页，点击“Copy token”。
2. 在 AWS WAF 中，重新打开 web ACL 下的 CoreDash 规则（即上方 Rule builder 截图中的表单）。
3. 将请求头字段名称从 user-agent 改为 x-coredash-bot。AWS 读取请求头时不区分大小写，因此它指的就是 X-CoreDash-Bot 请求头。
4. 将匹配类型设为“Exactly matches string”，将你的 token 作为匹配字符串粘贴进去，然后保存规则。

CDN 后方的源站检查超时

本节仅针对 uptime check，且仅适用于在配置监控时于 Advanced 下填写了 Origin IP 的情况。配置后，CoreDash 会绕过 CDN 直接检查你的服务器。某些服务器只接受来自 CDN 自身地址的请求。此时监控会变为 Down 并提示“The origin check fails: Connect timeout”，而普通访客却仍能正常从 CDN 获取页面。

CDN 仍在正常响应缓存页面，但针对服务器本身的检查发生了超时。

基于 user agent 或 token 的规则对此无济于事：这类服务器在读取任何请求头之前，就已经直接根据来源丢弃了请求。因此，必须通过 IP 地址让服务器识别 CoreDash。请在服务器防火墙中放行两个 uptime 地址：51.195.222.219 和 51.195.222.220，或联系主机提供商处理。如果后续源站检查再次发生超时，请先查看最新地址列表：IP 地址可能有所变动。

CoreDash 依然被拦截

如果监控依然显示 Blocked 或 audit 仍旧报错，请重新打开日志并点击最新的 CoreDash 请求：Cloudflare 查看 Events，AWS 查看 Sampled requests。其中记录的名称就是当前拦截 CoreDash 的功能。常见原因如下：

• 拦截功能与之前不同。例如关闭 Bot Fight Mode 后，请求转而被 Browser integrity check 拦截。此时同样需要配置 Skip 规则。
• 规则未激活，或在 AWS 中未置顶。在 Cloudflare 中，Custom rules 下的 CoreDash 规则状态应为 Active；AWS 则要求将其排在“Set rule priority”的最上方。
• 规则内容与步骤要求不一致。Cloudflare 要求使用 contains 且 CoreDash/ 必须带有末尾斜杠；AWS 要求检查请求头 user-agent，且匹配方式为“Starts with string”。
• 被你自建的其他 Cloudflare 规则拦截（例如拦截特定国家/地区的规则）。Skip 规则不会跳过自定义规则，因此需要修改该规则将 CoreDash 排除在外。Events 中会标明请求来自哪个国家或地区。
• 开启了 Under Attack Mode。该模式会质询包括 CoreDash 在内的所有访客，直到你将其关闭。
• 请求显示放行，或者日志中根本没有 CoreDash 请求。这说明在 Cloudflare 或 AWS 前后还存在其他防火墙，例如主机商的防火墙或服务器本身的规则。请在相应层级同样放行 CoreDash/ user agent。

问题仍未解决？联系 CoreDash，并附上监控或受测页面的 URL 以及被拦截的时间。

关于两个 bot 发送的具体内容及设计原理，可参阅 CoreDash bot 详情页。了解更多监控相关内容：uptime 监控，脚本调用可参考 Uptime API。