这次咱们来看一个和很多站长、开发者和自动化脚本维护者都直接相关的场景Cloudflare 防护与 computer use 类自动化请求之间的冲突。如果你维护过爬虫、RPA 或浏览器自动化 Agent大概率见过 Cloudflare 的拦截提示——打开页面后出现 “Were sorry... but your computer or network may be sending automated queries.”意思是当前计算机或网络发出的请求带有自动化特征已经被安全策略拦下。对站长来说这是 Cloudflare 在边缘层识别并处理机器人流量对自动化开发者来说这就是一个需要认真排查的硬性问题。从 Cloudflare 后台看这类能力集中在 Security → Bots 菜单下。Bots Management 的策略可以由管理员自行调整比如从严格模式改为放行更多已知爬虫或者反过来把未验证的自动化请求全部拒绝。很多人第一次看到这个菜单时容易懵因为里面选项不少Bot Fight Mode、Super Bot Fight Mode、跳过规则、托管挑战、质询动作等。它们之间是什么关系、配置错了会怎样这正是本文要展开的部分。本文会覆盖以下内容Cloudflare Bots 管理核心能力、适用场景和合规边界、后台配置流程、用 curl 和 Python 做功能验证、通过 Cloudflare API 管理防护策略、批量任务中如何避免误伤以及遇到拦截提示时的排查思路。适合网站运营者、自动化脚本开发者、AI Agent 接入方阅读。1. Cloudflare Bots 管理核心能力速览能力项说明产品类型CDN / 边缘安全防护 / Bot 流量管理主要功能Bot 检测、人机验证 Turnstile、速率限制、WAF 自定义规则后台入口控制台 Security → Bots具体以实际后台为准策略模式Bot Fight Mode、Super Bot Fight Mode、Bots Management 自定义规则防护动作允许 / 质询 / 托管挑战 / 拦截 / 仅记录平台支持Cloudflare 控制台、Cloudflare APIAPI 接入支持需 Zone ID 和 API Token批量任务适合通过 API 批量管理规则、批量观察安全事件GPU/显存不适用边缘节点执行不消耗本地算力从上面的表格能看出Cloudflare 的 Bot 防护和本地部署的 AI 工具不同它不依赖你本机的 CPU 和显存而是在请求到达源站之前由 Cloudflare 边缘节点先做一层判定。这个判定会综合请求的 IP 信誉、UA、TLS 指纹、行为频率、浏览器环境完整性等信息最终决定放行、弹验证码、质询还是直接拦截。对普通访问者来说看到 Turnstile 验证码或者“请确认你是人类”的页面就是 Cloudflare 防护在起作用。对自动化请求来说往往等不到验证码页面而是直接在 HTTP 层拿到 403 或 “Were sorry” 提示。理解这个区别是后面排查一切问题的基础。2. 适用场景与使用边界Cloudflare Bots 管理主要解决三类问题。第一类是网站资源保护接口被脚本刷、登录接口被爆破、内容被高频抓取这些都会占用源站带宽和计算资源通过 Bot 检测可以把明显的自动化流量挡在源站之外。第二类是业务风控增强比如注册页面、评论区、签到接口用 Turnstile 人机验证确认对面是真人而不是程序脚本。第三类是流量治理把已知的搜索引擎爬虫和正常的第三方服务放行把来源不明的批量请求拦截保证核心业务可用性。不过这套能力有明确的使用边界。如果你是自动化请求的开发者遇到 Cloudflare 拦截时需要优先判断这个站点是否明确允许自动化访问是否提供了官方 API你是否有合法授权或测试账号如果答案是“没有授权”那么更稳妥的做法是停止请求而不是试图绕过验证码或伪装浏览器特征去继续访问。Cloudflare 的检测体系本身也在不断演进靠改 UA、加 Cookie、伪造 TLS 指纹来对抗防护既不稳定也可能触碰法律和平台规则的风险。computer use 类工具也要特别注意。这类工具通常会启动一个真实浏览器通过模拟鼠标键盘操作访问网站乍一看和普通用户很像。但 Cloudflare 的托管挑战往往包含浏览器环境完整性检测如果页面在 JavaScript 层面判定当前环境不可信就会持续给出 challenge整个过程可能卡在验证页无法继续。这不是简单的请求头问题而是产品设计层面的访问边界站点方没有授权无人值守自动化访问时你应当通过正规渠道申请 API 或联系管理员而不是让 Agent 反复重试挑战。3. 环境准备与前置条件3.1 Cloudflare 账号侧准备要配置 Bots 管理首先需要满足几个前置条件。一个可用的 Cloudflare 账号一个已经接入 Cloudflare 的域名且 DNS 状态显示为 Active。域名接入完成后Cloudflare 会成为该域名的边缘代理所有 HTTP/HTTPS 请求先经过 Cloudflare 再回源。若域名还在 Pending 状态说明 NS 还没切换完成此时部分安全功能不可用。建议准备一个有权限访问 Security 菜单的账号。如果是团队项目最好不要直接使用管理员主账号登录后台操作而是创建一个成员角色或者直接使用 API Token 完成后续配置。API Token 的权限建议按最小化原则授予只需要 Bots、WAF、Zone Settings 相关权限避免把整个账号的写权限暴露给 CI 系统或同事。3.2 本地工具链准备本地环境不需要特殊硬件纯云端服务不需要 GPU。需要准备的是# 检查 curl 是否可用 curl --version # 检查 Python 环境 python3 --version pip3 --version如果要做请求观察建议安装 requests 或 httpxpip3 install requests httpx浏览器方面准备 Chrome 或 Edge 的 DevTools 即可。需要观察的元素包括请求响应头、Cookie 生成过程、是否有 Turnstile iframe 加载。另外准备一个文本文件记录测试用域名、Zone ID、API Token方便后续命令直接引用。4. Cloudflare 后台 Bots 管理配置流程4.1 Security → Bots 入口登录 Cloudflare 控制台选择域名在左侧菜单找到 Security然后进入 Bots。不同套餐下看到的选项不同但大体包含三个层次Bot Fight Mode、Super Bot Fight Mode、Bots Management 自定义规则。如果套餐不支持某项功能后台会显示升级提示或用灰色按钮标明不可用。实际配置前先确认目标是要全站开启严格拦截还是只对特定路径启用防护建议第一次配置不要直接上“拦截”动作先用“质询”或“仅记录”观察数据确认规则命中合理后再收紧。4.2 选择防护模式Bot Fight Mode 是最基础的开关适合免费版用户快速启动防护。开启后Cloudflare 会拦截明显恶意的爬虫和已知攻击源同时给可疑请求返回挑战页。这个模式配置简单但可调节空间小适合对安全要求不高的个人站点。Super Bot Fight Mode 提供了更细的控制。它可以区分“已验证的爬虫”比如 Googlebot、“未验证的爬虫”和“人类用户”分别设置不同的动作。常见的配置方案是流量类型建议动作已知合法爬虫允许未验证爬虫托管挑战明显恶意请求拦截内部监控或可信 IP跳过防护Bots Management 自定义规则更适合精细化运营。你可以基于请求路径、ASN、IP 范围、Bot 分数等维度编写规则。例如只对/api/路径开启严格挑战或者对外部 IP 段的请求提高拦截阈值。规则配置完成后建议先在“仅记录”状态下运行一段时间观察 Security Events 中的命中情况再切换为实际动作。4.3 Turnstile 人机验证接入Turnstile 是 Cloudflare 的人机验证组件用于替代传统验证码用户不需要点击图片或输入字母就能在后台完成验证。在控制台左侧菜单找到 Turnstile创建站点后会拿到 Site Key 和 Secret Key。前端接入时在页面中引入 Turnstile 脚本并放置一个占位 divscript srchttps://challenges.cloudflare.com/turnstile/v0/api.js async defer/script div classcf-turnstile>curl -X POST https://challenges.cloudflare.com/turnstile/v0/siteverify \ -H Content-Type: application/x-www-form-urlencoded \ --data secret你的密钥response前端返回的token这一步适合加在登录、注册、评论、留言等容易被机器人刷的接口前。接入之后即使是看起来正常的浏览器自动化请求只要没有通过 Turnstile 的验证就无法提交表单。4.4 自定义规则与跳过规则自定义规则需要谨慎设计。比较常见的一个误区是开启 Bot Fight Mode 后自己公司的客服系统或运维脚本也被拦截了。解决办法是配置“跳过”规则把可信的 IP 段或内部 UA 加入白名单。注意跳过规则的范围要尽量小避免把网段设置得过宽反而放行了真实攻击流量。另一个常见场景是 API 场景。如果站点本身面向第三方开发者提供公开 API那么不加区分地拦截所有自动化流量会破坏业务。此时应该做区分允许带合法 API Key 的请求对无 Key 或异常频率的请求执行挑战或限速。5. 功能测试与效果验证5.1 站长视角验证配置完 Bots 管理后需要验证防护是否真的生效。最简单的方法是先用 curl 请求一个测试页面观察返回结果。以自有测试域名为例curl -I -A Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 \ https://your-test-domain.com注意将your-test-domain.com替换成自己的域名。执行后可以先看状态码和响应头。如果开启了 Bot Fight Mode 或自定义规则恶意 UA 或异常请求会被返回 403或在响应头中出现server: cloudflare、cf-mitigated等标记。实际表现取决于规则动作一次请求结果不应作为长期判断依据需要结合日志持续观察。接下来进入后台的 Security Events查看被命中的请求记录。重点看三块内容命中了哪条规则、请求来源 IP 和 UA、请求频率是不是异常。如果配置了“仅记录”动作这里会显示规则触发但未拦截方便你判断阈值是否合理。5.2 请求方视角观察作为自动化请求的一方遇到拦截时不要反复重试先检查响应特征。用 Python 请求一个测试站点检查当前请求是否被 Cloudflare 接管import requests response requests.get( https://your-test-domain.com, headers{ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36 }, timeout15 ) print(status:, response.status_code) print(server:, response.headers.get(server)) print(cf-mitigated:, response.headers.get(cf-mitigated)) print(url:, response.url)如果server字段包含cloudflare说明请求已经走了 Cloudflare 边缘节点。如果响应被重定向到挑战页或返回 403说明当前请求被认为带有自动化风险。此时应该降低请求频率、修正 UA、检查是否需要先完成 Turnstile 验证。若站点提供公开文档或 API优先改用官方接入方式。5.3 结果判断标准验证是否成功的标准很简单站点侧正常用户能通过恶意请求被拦截自动化请求侧授权访问能成功未授权访问被正确拒绝。如果出现“正常用户也被拦截”的情况说明规则设置过严或跳过规则缺失需要调整。如果出现“明显是恶意批量请求却没被拦截”的情况说明防护模式没开全或者规则表达式覆盖不到。建议把 Security Events 的数据和业务日志做对比找到误报和漏报的平衡点。6. Cloudflare API 接入与批量策略管理6.1 API 认证与基础信息获取Cloudflare 的 API 统一使用https://api.cloudflare.com/client/v4作为基础地址认证方式推荐使用 API Token。在后台创建 Token 时选择 Zone 相关权限并把适用范围限定到目标域名。先验证 Token 是否可用查询 Zone 信息curl -X GET https://api.cloudflare.com/client/v4/zones?nameyour-test-domain.com \ -H Authorization: Bearer ${CF_API_TOKEN} \ -H Content-Type: application/json返回值中的id就是 Zone ID后面的规则配置命令会用到。6.2 通过 API 添加防护规则通过 API 管理规则的好处是方便批量操作也方便把策略纳入代码仓库进行版本管理。下面给出一个通用的 WAF 自定义规则创建模板用于对 Bot 分数低于阈值的请求执行挑战。实际字段和执行动作需要以 Cloudflare 官方 API 文档为准不同套餐可用字段可能不同。curl -X POST \ https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/phases/http_request_firewall_custom/entrypoint/rules \ -H Authorization: Bearer ${CF_API_TOKEN} \ -H Content-Type: application/json \ --data { rules: [ { expression: (cf.bot_management.score lt 30), action: challenge, description: challenge low bot score requests } ] }这里的${ZONE_ID}和${CF_API_TOKEN}需要替换成实际值。cf.bot_management.score lt 30是示意表达式代表 Bot 分数低于 30 的请求会收到挑战。实际可用的算子、字段和动作要参考官方文档确认配置前最好在后台用模拟请求预览一遍。补充一点API 配置和后台配置是同一套规则体系。通过 API 创建规则后在后台相应页面也能看到对应条目。批量管理时建议先写一个脚本遍历规则列表统一加前缀或描述标记方便后续回溯。6.3 批量任务与重试策略如果需要在多个域名或 Zone 上执行相同配置循环调用 API 即可。下面的 Python 示例展示批量更新时的基本框架import os import requests api_token os.environ[CF_API_TOKEN] zone_ids { a.example.com: zone_id_a, b.example.com: zone_id_b, } headers { Authorization: fBearer {api_token}, Content-Type: application/json, } for zone_name, zone_id in zone_ids.items(): url fhttps://api.cloudflare.com/client/v4/zones/{zone_id}/settings/security_level payload {value: high} try: response requests.patch(url, headersheaders, jsonpayload, timeout30) print(zone_name, response.status_code) except requests.RequestException as exc: print(zone_name, error, exc)批量任务要注意频率和重试。Cloudflare API 有速率限制如果并发过高会收到 429。建议每个请求之间做短延迟并对失败的任务设置指数退避重试。更稳妥的方式是先小批量执行确认返回结构符合预期后再全量推进。所有 API 调用都要记录请求 ID 和返回体方便排查问题。7. 安全策略对站点与自动化请求的影响7.1 边缘防护带来的性能收益Cloudflare 的 Bot 检测和 WAF 规则运行在边缘节点请求在到达源站之前就会被处理因此大部分恶意流量不会占用源站 Web 服务进程和数据库连接。对于个人站点或中小业务而言开启 Bots 管理最直接的效果是日志里的垃圾请求变少、CPU 负载下降、后端接口可用率提升。这个收益不需要扩容服务器就能拿到是性价比很高的安全投入。不过要提醒的是防护规则本身也会消耗 Cloudflare 边缘节点的配额所以免费版能使用的功能相对基础自定义规则数量也有限。如果需要大量自定义托管规则还是要结合套餐成本来评估。7.2 误判和可用性损失安全策略是一把双刃剑配置过严会带来严重的可用性损失。一个真实高频的坑是站长发现在某些地区打不开页面后台一看用户请求被一条过于宽泛的 WAF 规则拦截了。另一个常见问题是手机 App 客户端发起的请求因为没有浏览器特征被 Bot 检测判为低分而进入挑战页用户直接无法登录。降低误判的通用思路是分阶段上线。第一阶段用“仅记录”观察规则命中数量第二阶段改成“质询”让人工确认验证流程能正常通过最后才切换成“拦截”。每次变更后观察至少一个业务周期对比拦截率、订单量、接口成功率等指标变化。7.3 computer use 场景下的边界从这个角度看computer use 类自动化工具访问受保护站点时会遇到更特殊的局面它启动的是真实浏览器能够执行 JavaScript也具备渲染页面能力但它本质上仍然没有真人参与。Cloudflare 如果检测到浏览器环境异常、访问模式过于规律、或行为路径不符合人类特征仍然会下发托管挑战。当工具卡在 Turnstile 页面时建议不要尝试通过隐藏浏览器特征来“骗过”检测。一个更合规的路径是联系目标站点申请 API 或测试账号或者使用站点方明确提供的白名单机制。如果目标站点没有提供任何自动化接入方式那么默认按不允许自动化访问来处理这是最稳妥的判断。8. 常见问题与排查方法问题现象可能原因排查方式解决思路访问提示 Were sorry... but your computer or network may be sending automated queries请求被识别为自动化流量被 Bot 防护拦截检查响应头是否有 cf-mitigated 或 403后台 Security Events 查看命中记录降低请求频率、修正 UA若是自己的站点在 Bots 规则中放行或跳过对应请求正常用户也出现人机验证防护模式过严或 IP 被误判为低信誉查看用户 IP 是否来自 IDC 或代理段检查挑战通过率调整为“仅记录”观察配置跳过规则将网内用户 IP 加入白名单Turnstile 验证不通过页面 JS 加载异常、无头浏览器环境特征明显打开浏览器 DevTools 查看 console 报错确认 iframe 是否加载使用完整浏览器环境测试检查前端网站密钥是否正确自家运维脚本访问被拦截自定义规则中 UA 或 IP 条件覆盖了运维来源在 Security Events 中找到对应请求确认命中的规则增加跳过规则按运维 IP 或自定义 Header 放行请求返回 429触发了速率限制规则查看响应头中的 Retry-After 字段和后端日志降低并发频率增加指数退避重试API 调用返回 403API Token 权限不足或 WAF 规则拦截检查 Token 权限范围确认规则命中记录调整 Token 权限检查请求是否符合放行条件批量任务大批量失败请求频率过高触发防护查看失败响应的状态码和规则命中详情增加任务间隔限制并发数按批次重试后台看不到 Security Events 数据账号权限不足或套餐不支持对应日志留存确认账号角色、套餐版本提升权限或升级套餐用 API 拉取日志作为补充9. 最佳实践与使用建议站点运营方的建议是第一优先级上线新安全策略前先用“仅记录”观察数据不要一次性开启严格拦截。把搜索引擎爬虫、支付回调、内部监控等可信流量提前加入白名单。人机验证优先选择 Turnstile而不是传统图片验证码体验更好且维护成本低。每条自定义规则都要写清楚描述方便三个月后回溯。自动化请求方的建议是请求前先确认站点是否有公开 API优先使用官方接口而不是抓取页面。如果只能通过网页访问请将频率控制在极低水平并配置友好的 UA在 User-Agent 中注明联系方式或用途。遇到 Cloudflare 挑战页时立刻停止重试检查合规性而不是去研究如何绕过。computer use 类工具开发者的建议是在 Agent 中增加“遇到验证码时自动暂停并通知用户”的逻辑而不是让程序反复刷新尝试。自动化执行前明确告知使用者该站点可能不接受无人值守访问让使用者在授权范围内操作。人脸、声音、网页素材等内容涉及版权或肖像权时必须有明确授权链本文涉及到的所有网络访问也应在合法授权范围内进行。日志和数据留存同样重要。无论配置规则还是调用 API都建议把请求 ID、状态码、响应时间、命中规则记录下来。后续调优策略时这些数据是判断误报和漏报的唯一依据。没有日志做支撑安全策略调整就变成了拍脑袋。10. 总结与下一步Cloudflare Bots 管理对站长和自动化开发者来说价值点在于它能在边缘层快速识别并隔离自动化流量减少源站压力同时也给自动化请求方提供了一个清晰的判断信号——站点是否允许程序化访问。从配置上看核心动作是选好防护模式、搭好 Turnstile、编写可控的自定义规则并通过 Security Events 持续观察。如果你是新接触这套体系的站长建议先开启基础防护配置一两条只针对敏感路径的规则把 Turnstile 接到登录接口跑一周再从数据中决定是否收紧。如果你是自动化脚本开发者建议先把第 8 节的排查表保存下来遇到拦截时对照检查优先确认授权边界再谈技术和性能问题。最容易踩的坑有两处一是开局就把防护拉到最严格导致正常用户被挑战页卡住二是把绕过防护当作自动化开发的正常环节最终既不稳定也存在合规风险。下一步如果你需要批量管理多个域名可以继续研究 Cloudflare API 和 Rulesets 的完整字段定义把这套配置纳入代码仓库做到可审计、可回滚。