Cloudflare 的 Bot 管理功能在保护站点时经常会出现一种让开发者困惑的现象站点正常打开没问题但自己的脚本、接口测试工具或内部监控请求却返回 403并且页面提示your computer or network may be sending automated queries。这条信息并不是源站写死的错误而是 Cloudflare 在安全链路里判断该请求“疑似自动化”后触发的拦截页面。如果不理解 Bot 管理的判断逻辑很容易陷入“明明加了白名单还是被拦”的循环。这篇文章会从 Cloudflare 后台的Security - Bots入手讲清楚这条报错的来源、Bot 管理模式的作用、合法自动化请求被误拦截时的排查路径以及如何在不降低安全水位的前提下配置放行策略。内容主要面向使用 Cloudflare 托管 CDN/WAF 的运维人员和后端开发也会补充一段关于 AI Agent 和computer use类流量识别的扩展思考。1. 先理解这条报错和 Bot 管理之间的关系1.1 报错页面背后的拦截链条当浏览器访问一个接入 Cloudflare 的站点时请求会先经过 Cloudflare 的边缘节点。边缘节点会完成 DNS 解析、缓存判断、安全规则匹配再把允许通过的请求转发给源站。这个链路里Bot 管理只是其中一个环节但它会在请求到达源站之前提前做出“拦截、挑战、放行”的决定。your computer or network may be sending automated queries这个页面通常出现在 Cloudflare 边缘节点已经判定请求具有高风险自动化特征之后。页面内容可能因为站点语言、自定义规则或套餐不同而略有差异但响应状态码通常是403 Forbidden。真正需要注意的并不是这段提示文案而是响应头里携带的CF-Ray。这个 ID 是整个世界边缘节点的请求编号后续查 Security Events 时它就是定位请求的入口。很多团队排查时会直接去源站 Nginx 日志里找 403结果发现源站根本没有收到请求。原因在于 Cloudflare 是在边缘层直接阻断的源站日志里自然没有任何痕迹。理解这条链路是排查误拦截问题的第一步。1.2 免费计划与付费计划里 Bot 管理的差异Cloudflare 的 Bot 管理能力并不是所有套餐完全一样的。免费套餐通常可以开启基础版 Bot Fight Mode付费套餐会提供 Super Bot Fight Mode更高级的套餐才有完整的 Bot Management 和机器人得分接口。这里不讨论具体价格但需要明确一个原则不同套餐能看到的菜单、字段和配置项是不同的。常见差异主要体现在这几个方面能力项基础版进阶版完整版Bot Fight Mode支持支持支持Super Bot Fight Mode部分支持支持支持自定义爬虫放行有限支持支持机器人得分 API不支持部分支持支持自定义规则里的 bot 字段有限有限完整正因为存在套餐差异网上很多教程写的字段在自己控制台里并不存在。落地配置前应该先进入Security - Bots看实际界面里有哪些开关再决定用哪种方案。1.3 为什么 “computer use” 流量会被单独讨论computer use是当下 AI Agent 领域的说法指的是让模型像人一样操作浏览器、点击按钮、填写表单、读取页面内容的一类自动化能力。这类流量和传统爬虫不同它可能使用无头浏览器也可能带完整的用户代理和 Cookie甚至能绕过部分基于 UA 的识别规则。Cloudflare 在做安全判断时会综合请求的 TLS 指纹、HTTP 行为、IP 历史信誉、浏览器环境完整度等信号而不是只看一个 User-Agent。computer use类流量如果被识别为高自动化风险就会出现和普通脚本一样被拦截的情况。对站点管理员来说关键问题是这些自动化流量到底是恶意爬虫还是自己团队使用的合规 AI 测试工具。不同的答案决定了后续配置Challenge还是Allow。2. 进入 Cloudflare 后台之前先对齐环境和权限2.1 需要哪些后台权限和菜单入口修改 Cloudflare 安全策略需要账户权限不是所有账号都能操作。通常至少需要域名级别的Admin或Super Administrator权限Read-only账号只能查看日志无法修改规则。进入后台的路径是登录 Cloudflare 控制台。选择目标域名。在左侧菜单里找到Security。进入Bots或WAF。不同版本控制台界面会调整但核心逻辑一致。Security - Bots负责机器人防护模式Security - WAF负责自定义规则和托管规则集。排错时经常需要在两个页面之间来回切换。生产环境建议使用独立的操作账号并用 Cloudflare 的身份接入能力做二次认证。避免直接在根用户下修改规则否则一旦配置错误回滚时很难分辨是哪一次操作导致的。2.2 用最小请求确认当前被拦截的真实原因在后台翻规则之前应该先构造一个最小请求把当前的拦截现象稳定复现出来。最小请求可以是curl -sI https://example.com/api/health如果返回403继续加参数看响应体curl -sI -A Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36 https://example.com/api/health这个步骤的目的是确认拦截是不是由 User-Agent 引起的。如果带浏览器 UA 后请求正常说明规则很可能对 UA 做了判断如果带浏览器 UA 也返回 403那就要继续检查 IP 信誉、ASN 或 WAF 规则。需要注意403只是一个状态码无法直接告诉你来源。必须结合响应头和页面内容判断响应头里有没有CF-Ray有则说明请求到达过 Cloudflare 边缘。响应体里有没有cf-error或 Cloudflare 固定文案。响应头里有没有server: cloudflare。如果这些特征都不存在很可能是源站自身返回的 403和 Cloudflare 无关。2.3 学会从响应头和响应体里取证据排错阶段收集证据越完整后续看 Security Events 就越省事。推荐保存以下信息curl -s -D - https://example.com/api/health -o /tmp/body.txt cat /tmp/body.txt | head -n 50然后记录CF-Ray用于关联日志。CF-Cache-Status判断是否命中缓存。CF-Worker判断是否被 Worker 改动过响应。server判断响应来自 Cloudflare 还是源站。响应体中的拦截文案用于与 Cloudflare 内置页面做比对。把这些信息统一保存到一个临时文件里后续在Security Events里按RayID或IP搜索时就能快速定位到触发规则。3. 按现象倒推被拦截时应该查哪一层3.1 第一步判断 403 来自 Cloudflare 还是源站出现 403 时最忌讳直接去源站改 Nginx 配置。正确顺序是先从外到内判断请求到底在哪一层被拒绝。可以用一个很直接的命令curl -sI https://example.com/api/health | grep -i server\|cf-ray\|cf-cache-status输出里如果看到server: cloudflare说明响应来自 Cloudflare 边缘。再配合CF-Ray就能确认请求确实经过了边缘层且被边缘安全策略处理过。如果看到server: nginx或server: openresty那么 403 大概率来自源站。这时再去查源站访问日志重点看对应时间戳、URI 和客户端 IP。还有一种情况是请求根本没有进入 Cloudflare而是被本地 hosts、代理或网络出口给挡了。建议先确认目标域名解析到的 IP 是 Cloudflare 的 IP 段再继续排查。3.2 第二步从安全事件里找到匹配的规则当确认 403 来自 Cloudflare 时下一步就是打开Security - Events或Security - Analytics按时间范围过滤被拦截的请求。在事件列表里重点看以下字段字段含义Ray ID请求的唯一标识IP客户端出口 IPCountry请求来源国家或地区Action实际动作Allow / Block / Challenge / Managed ChallengeRule ID命中的规则 IDService触发安全模块例如 WAF / BotsUser-Agent请求携带的 UA如果Service显示Bots说明是 Bot 管理模块触发的拦截。如果显示WAF则要检查是托管规则还是自定义规则。通常一次拦截可能同时命中多个规则事件列表里会显示出最终的决策动作。3.3 第三步区分真实用户、验证过的爬虫和不可信自动化流量Cloudflare 在判断 Bot 时会把请求分为几类真实用户、已验证爬虫、疑似自动化、确定自动化。这个分类会直接映射到不同的动作上。真实用户行为特征完整浏览器环境通过验证通常可以正常访问。已验证爬虫如 Googlebot、BingbotCloudflare 会校验反向 DNS 和 IP只要源站允许搜索爬虫通常建议放行。疑似自动化自动化特征明显但不完全确定适合使用 Managed Challenge 或验证码。确定自动化风险高可以直接 Block。排错时与其对所有自动化请求一刀切放行不如先在日志里确认自己的脚本属于哪一类。如果是自己的监控探活脚本不需要完整浏览器环境就单独配置放行如果是搜索引擎爬虫要用 Cloudflare 的 verified bot 机制处理而不是简单按 UA 放行。4. 在 Security - Bots 和 WAF 中配置放行策略4.1 调整 Bot 管理模式什么时候该改什么时候不该改Security - Bots页面里最常见的两种模式是 Bot Fight Mode 和 Super Bot Fight Mode。Bot Fight Mode 是一个总开关。开启后Cloudflare 会自动识别并挑战自动化流量。它的配置成本低但缺点是规则粒度不够细容易误伤合法的 API 调用。Super Bot Fight Mode 提供了更多选项通常可以设置对已知爬虫允许、挑战或阻止。对未知爬虫允许、挑战或阻止。对无头浏览器允许、挑战或阻止。对非浏览器流量允许、挑战或阻止。生产环境不建议直接关闭 Bot 防护更稳妥的做法是只调整“已知爬虫”或“不确定流量”的策略。如果某个监控脚本被拦截先把动作从Block改成Challenge再验证脚本是否收到挑战页面。通常脚本无法完成 JS Challenge所以最终仍然会被拦截。这时就需要使用自定义 WAF 规则对特定路径和来源做精准放行。4.2 用 WAF 自定义规则放行合法 API 路径WAF 自定义规则是解决误拦截的主要手段。它比总开关更灵活可以按请求路径、来源 IP、ASN、Cookie、Header 等条件组合。例如线上有一个内网监控系统每 30 秒访问一次/api/v1/health但请求被 Bot 管理拦截。可以先创建一个 WAF 自定义规则(http.request.uri.path eq /api/v1/health and cf.client.bot)动作选择Skip并勾选跳过 Bot 管理模块。在 Cloudflare 自定义规则里Skip动作可以指定跳过哪些安全模块。常见做法是只跳过Bot Management不跳过 WAF 托管规则避免请求再次被其他规则拦截。为了更加收敛可以加上 IP 或 ASN 条件(http.request.uri.path eq /api/v1/health and ip.src.in {192.0.2.10} and cf.client.bot)这样只有特定监控 IP 访问健康检查接口时才放行其余自动化流量照常挑战。4.3 使用 IP/ASN/Verified Bots 列表控制放行范围如果放行条件无法只靠路径表达可以创建 IP 访问规则或 IP 列表。在Security - WAF - Tools里可以按 IP、IP 段或 ASN 创建临时访问规则。这种方式适合快速验证但生产环境不建议用大量单条 IP 规则维护成本高还容易出错。更推荐的做法是使用Lists功能在Manage Lists中创建自定义列表。列表里填入需要放行的出口 IP、ASN 或国家。在 WAF 自定义规则中引入该列表。表达式示例(any(ip.src in $allowlist_monitoring) and http.request.uri.path eq /api/v1/health)对搜索引擎爬虫有单独的处理方式。Cloudflare 会维护一份 verified bots 数据比如 Googlebot、Bingbot 的验证结果。如果希望放行这些爬虫可以在 Super Bot Fight Mode 里把 Known Bots 设置为 Allow。这样即使源站日志里看到大量爬虫请求也不会因为误拦截导致站点在搜索引擎里收录下降。4.4 生产环境建议使用更可靠的身份标识基于 IP 和 UA 的放行规则并不可靠。监控脚本所在的出口 IP 可能变化UA 可以伪造而一个被攻破的云主机也可能带上合法 UA。生产环境建议把“放行某个路径”升级为“验证请求是否来自可信客户端”。可靠方案包括在请求 Header 中加入自定义 Token例如X-Monitor-Token然后源站和 Cloudflare 规则都校验该值。使用 mTLS 客户端证书在 Cloudflare 边缘校验证书后再转发到源站。使用 Cloudflare Access 保护 API 端点所有监控请求先完成身份认证。自定义 Token 方式可以写进 WAF 自定义规则(http.request.uri.path eq /api/v1/health and http.request.headers[x-monitor-token] eq your-token-value)这种方式比只按 IP 放行更安全因为即使攻击者看到请求路径也拿不到合法 Token。Token 应该单独存放不能硬编码到前端页面。5. 配置后如何验证效果并持续观察5.1 用 curl 分场景验证规则配置完成后不能只看一次请求是否通过就结束。建议用不同场景做最小验证。场景一正常浏览器访问curl -sI -A Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36 https://example.com/预期结果返回 200且CF-Cache-Status可能是HIT或DYNAMIC。场景二未加头的自动化请求curl -sI https://example.com/api/v1/health预期结果仍然被 Cloudflare 拦截或挑战这证明 Bot 管理没有被整体关闭。场景三带合法 Token 的监控请求curl -sI -H X-Monitor-Token: your-token-value https://example.com/api/v1/health预期结果返回 200之后在 Security Events 里可以看到请求匹配到了 Allow 规则。如果场景三仍被拦截优先检查规则表达式的优先级。Cloudflare 的规则顺序会影响结果某些规则可能在自定义规则之前直接 Block。这时需要调整规则顺序或者把自定义规则放在更前面。5.2 观察 Security Events 和 Analytics 日志验证完一次后还要观察一段时间内是否出现新误拦。推荐把以下两个页面作为日常巡检入口Security - Events看被拦截和放行请求的实时记录。Analytics - Security看拦截总量的趋势确认配置后没有出现异常下降或异常上升。有一个比较容易忽略的点Skip规则可能让请求跳过 Bot 管理但请求仍然会被其他安全模块命中比如 WAF 托管规则或速率限制规则。所以配置放行后如果请求还是 403要继续看Security Events里 Action 是否为Managed Challenge或Block以及 Service 是否是Rate Limiting或其他模块。5.3 发布前检查清单无论改动多小配置前都应该过一遍检查清单是否备份了当前规则列表和表达式。是否确认预算放行的路径不会暴露敏感数据。是否确认 Token 没有写在公共代码仓库里。是否验证了正常浏览器访问不受影响。是否验证了恶意请求仍然会被拦截。是否设置了告警或定期巡检防止规则被意外删除。是否记录了规则变更时间、操作人和原因。清单的目的不是流程繁琐而是防止“一次 curl 通了就上生产”的侥幸行为。检查项通过标准浏览器访问返回 200无挑战页面监控请求携带 Token 后返回 200未携带 Token 的自动化请求被拦截或挑战Security Events能看到对应放行记录规则范围只对特定路径或来源生效6. 常见误拦截场景和最佳实践6.1 三张速查表现象、原因、处理实际排错时可以按以下表格快速定位。现象常见原因处理思路所有自动化请求都返回 403Bot Fight Mode 开启且无放行规则先看 Security Events确认是否命中 Bots 模块带浏览器 UA 后正常不带 UA 被拦UA 被作为判断信号不要盲目放行考虑对特定脚本路径配置 Token源站日志看不到请求但 Cloudflare 有事件请求被边缘拦截按 CF-Ray 在 Security Events 里查询配置了 Skip 规则仍被拦命中其他安全模块或规则顺序不对检查 Service 字段和规则顺序只对一个 IP 放行却失败IPv6 出口地址变化使用 ASN 或 Token 方式爬虫被拦导致 SEO 下降搜索引擎爬虫被当作恶意 Bot使用 Verified Bots 放行机制安全模块常见动作排错入口Bot Fight ModeBlock / ChallengeSecurity - BotsWAF 自定义规则Skip / Block / ChallengeSecurity - WAF - Custom RulesWAF 托管规则Block / Managed ChallengeSecurity - WAF - Managed RulesRate LimitingBlock / Managed ChallengeSecurity - WAF - Rate Limiting RulesIP Access RulesBlock / AllowSecurity - WAF - Tools日志关键字段说明Ray ID请求唯一 ID用于日志关联Client IP客户端出口 IPUser Agent请求 UAAction最终处理动作Service命中模块Rule ID命中规则 ID6.2 最常见的 5 个配置坑第一个坑为了尽快解决问题直接关闭 Bot Fight Mode。这个操作虽然能让自己的脚本立刻恢复访问但也会让恶意爬虫和扫描流量直接到达源站。生产环境尤其是 API 服务不建议这样做。第二个坑用 UA 放行所有 Googlebot。攻击者完全可以伪造Googlebot的 UA。Cloudflare 有 verified bot 校验机制应该优先使用它而不是在规则里写http.user_agent contains Googlebot。第三个坑只验证一次就结束。假设放行规则只在特定时间段生效但源站监控系统在白天和晚上的出口 IP 不同规则只覆盖了其中一个 IP 段结果半夜告警再次出现。验证时至少覆盖不同 IP、不同 UA、不同时间段。第四个坑忽略规则顺序。Cloudflare 的 WAF 规则可能会按顺序评估早出现的 Block 规则会优先于后面的 Skip 规则。如果自定义规则放在最后还是被挡应该调整规则顺序或者把 Skip 条件合并到前面的规则里。第五个坑Token 写在明文日志或公共代码库里。一旦 Token 泄露攻击者可以直接伪装成监控请求。Token 应该用环境变量传递并且定期轮换。6.3 针对 AI 爬虫和 computer use 趋势的扩展思考AI Agent 和computer use类工具正在改变自动化流量的形态。传统攻击者可能只发几个 HTTP 请求而 AI 爬虫可能会像真实用户一样浏览多个页面、点击按钮、读取信息行为模式更接近真人。对运营者来说这种趋势带来的挑战是如何区分“有价值的数据访问者”和“批量采集的机器流量”。Cloudflare 的 Bot Management 在设计上已经包含了行为分析和异常检测而不是单纯依赖 UA。对于使用 AI 自动化工具做合规测试的团队建议开发环境提前申请专属测试路径避免与生产路径混在一起。在 Cloudflare 规则里单独标记这类请求例如加固定 Header。重要接口增加身份认证而不是依赖 IP 白名单。定期分析 Security Analytics观察 AI 爬虫的访问占比和拦截率。最终要建立的不是“把所有自动化请求都拦住”的策略而是“让可信自动化流量低成本访问让不可信流量付出足够高的验证成本”的策略。这样既能保护接口也不会因为误伤导致开发效率下降。配置 Cloudflare 的 Bot 管理本质上是在安全水位、业务可用性和运维效率之间做权衡能够用日志和规则把这种权衡说明白的团队才是真正把这个功能用好了。