Cloudflare 与 DataDome：采集响应中的信号

采集时收到 Cloudflare 或 DataDome 响应，只能观察一次访问决策的结果，不能获得背后所有信号的报告。首先需要区分挑战响应、请求的内容、源站错误和集成故障。BotBrowser 文档提供浏览器与请求头控制方式，无法提供任一厂商的内部决策状态，也不保证请求获准。经过授权的数据采集任务应先分类响应，再通过网站批准的支持渠道，把未解决的访问问题交给网站所有者。

观看视频

这段英文视频说明如何区分采集中的 Cloudflare 挑战页、普通 HTTP 403 和意外的 HTML 文档，并说明为什么隐藏的评分或 DataDome 决策需要运营方关联的记录。视频音频为英文。

摘要

• Cloudflare 文档规定 Challenge Page 使用 cf-mitigated: challenge，即使请求其他资源类型，响应仍为 text/html。
• 通用 HTTP 403 不能识别厂商、规则或浏览器信号。
• Cloudflare 机器人评分与 DataDome 服务端集成决策的观察边界不同于浏览器响应。
• 响应分类、访问许可、应用成功与拒绝原因需要分别记录。
• 保留脱敏的请求关联记录，请获授权的网站运营者检查日志。

目录

• 观看视频
• Cloudflare 评分与配置的动作
• 数据任务中的挑战响应
• DataDome 集成背后的决策
• 响应与后续动作对照表
• 关联请求而不收集秘密
• 浏览器控制与访问边界
• 实践结论

Cloudflare 评分与配置的动作

Cloudflare 机器人评分文档定义了 1 到 99 的分值。1 表示 Cloudflare 相当确信请求来自自动化；99 表示相当确信请求来自真人。这是厂商定义的分类端点，不是公开的百分比换算关系。分值不是客户端永久的身份证明，外部客户端也不应根据收到的页面给自己分配评分。

同一文档说明，网站运营者可在 WAF 自定义规则中使用评分来阻止、挑战或放行请求，也可在 Workers 中使用。因此，分类和动作是不同的问题：运营者配置的策略把可用信息转成具体响应。细粒度评分需要文档规定的 Enterprise Bot Management 权益。看到挑战并不能证明网站使用了该产品等级或某条基于评分的规则。

Cloudflare 将启发式方法、机器学习和 JavaScript 检测列入检测机制。这些公开说明没有列出每个浏览器值对某次拒绝的贡献。自动化检测概览区分了浏览器暴露的属性与更广泛的请求背景。改动属性不能证明厂商改变了分类，更不能证明网站授予了许可。

比较请求时，应限制因果推断的范围。响应变化可能同时伴随应用路径、会话状态或所有者规则的变化。没有获授权运营者提供的对应记录，就不能把某个检测输入单独认定为原因。先记录请求及可见结果；不可见的评分应保持未知。

Cloudflare 评分与日志分析进一步讨论运营者侧的评分证据。评分记录应关联到对应请求，不能借用同一浏览器另一次导航的分值。文档请求和之后的数据请求可能得到不同决策。有意义的比较是已识别事务与它自己的记录，而不是假定整个标签页有一个统一判定。

数据任务中的挑战响应

Cloudflare Challenge Page 响应文档规定了明确的客户端标记：cf-mitigated 的值为 challenge。文档还说明，无论请求什么资源类型，挑战响应的内容类型都是 text/html。因此，通常返回 JSON 的数据端点可能返回 HTML 挑战，而非请求的数据。将响应体交给 JSON 解析器前，应先检查可用的响应元数据。

仅凭意外的 HTML 响应体不足以归因。应用登录页、源站错误模板或中间服务页面同样可能是 HTML。标记可用时，优先使用文档规定的标记，同时区分网络工具观察到的头部与页面 JavaScript 能读取的头部。文档中的 fetch 示例展示了检查方式，不意味着每次跨源请求都能读取所有响应头。

如果确认响应是文档定义的 Challenge Page，应停止依赖它的提取步骤。随后出现的解析失败是下游后果，不能证明网站的数据结构发生了变化。按层诊断采集阻断说明了传输、HTTP 和文档处理故障为何需要分别记录。挑战响应不应在监控系统中悄悄变成空结果集。

网站所有者需要回答的是：该访问路径是否获准，配置动作是否符合预期。自动解答浏览器挑战、修改挑战代码或反复调整客户端属性，都不属于这一诊断任务。已有账户 Cookie 时也一样：客户端状态不能证明请求操作持续获得许可。

导航发生重定向时，应保留响应链。最终 HTTP 200 可能只是请求路径改变后到达的登录文档。应同时记录最终 URL、允许保留的重定向历史及内容类型，不保留签名查询参数值。否则，将解析器原本请求的端点与另一个最终文档比较，会把应用路由变化误认为检测结果。如果意外目标不在授权范围内，不要仅为补齐记录而继续访问。

DataDome 集成背后的决策

DataDome 请求验证集成文档描述了服务端模块调用其 API 并应用决策的过程。前提条件包括能访问请求头和最终用户 IP；文档还建议在支持时收集传入请求的 TLS 指纹信息。这些都是集成输入。公开列表不披露特定请求的决策权重，也不能证明每次部署都会收集所有可选输入。

文档区分了 API 决策和网站最终返回给客户端的响应。集成会将获准请求转发给后端，挑战决策则按规定的映射返回 API 提供的响应。访问网站的浏览器不一定收到这段内部 API 交互。不要把客户端的 HTTP 200 直接解释成 DataDome 内部的放行决策：应用实际返回的内容或授权结果可能不同。

DataDome 还描述了该集成在缺少决策头时的 fail-open 路径。这是面向模块实现者的指导，不是让客户端将缺少可见响应头解释为许可。客户端元数据缺失可能只是观察边界造成的，不能证明模块发生了 fail-open、正常运行或确实存在。

文档要求处理上游与下游头部映射，并警告不要向最终用户暴露内部指针头。经过授权的事件调查应向运营者索取适用的决策和脱敏关联结果，而不是为分类响应索取内部配置或收集会话令牌。这样可以避免把服务端实现细节当作公开的客户端检测 API。

集成返回意外文档时，运营者可将映射后的响应状态、响应体类型和下游头部，与客户端实际观察结果比较。归咎于浏览器 API 前，应先核对这层映射。

响应与后续动作对照表

下表适用于已经获得授权的任务。各行描述的是文档规定的条件和含义不明确的观察，不是对厂商保护目标的实测结果。应使用最具体的可用证据；缺少必要标记或运营者记录时，保留不确定性。

可用观察	有证据支持的分类	下一步获准动作	不能推出的结论
cf-mitigated: challenge	文档规定的 Cloudflare Challenge Page 标记	停止解析数据，向运营者确认预期访问路径	某个机器人评分或浏览器属性导致了挑战
没有特定标记的 HTTP 403	在所观察的响应边界上访问被拒绝	用获准的边缘与源站日志关联请求	决策一定来自 DataDome 或 Cloudflare
HTTP 200 但返回意外 HTML	响应不适用于预期的 JSON 数据步骤	检查内容类型、可用标记和应用结果	数据采集成功或厂商内部已经放行
运营者关联到的 DataDome 集成决策	该请求在模块中记录的决策	比较模块动作、返回响应及获准应用路径	客户端可读取每个内部 API 字段
没有可读决策元数据	不足以归因到特定厂商	保留脱敏记录，请运营者关联	没有保护或发生了 fail-open

表格将 HTTP 状态与应用成功分开处理。采集到的页面可能是错误文档；有效响应也未必包含该账户获准访问的数据。采集会话状态分析说明了为什么保留 Cookie 容器并不能解决这个问题。无法分类本身就是调查结果，不应强行转成检测成功或失败的结论。

提取输出与事件输出需要分开。端点在应用约定要求 JSON 时返回 text/html，应保留已分类的任务错误，而不是发布空价格表或删除之前采集的记录。这是消费端的数据处理选择，不是新的厂商检测主张。只有运营者解决访问或集成问题后，才通过应用批准的恢复流程重启数据管道。

关联请求而不收集秘密

对于自己运营的网站，可保留请求路径、带时钟基准的请求时间、HTTP 状态、内容类型和允许记录的关联标识。Cloudflare 的头部文档将 Cf-Ray 描述为可辅助关联的请求标识。它不是机器人评分或许可令牌。报告应说明标识在哪里被观察到，以及查询了哪个运营者日志；仅看到标识不能证明源站处理过请求。

事件记录应区分客户端观察与运营者调查结果。客户端可记录 cf-mitigated: challenge；获授权的运营者可补充对应规则或关联的集成决策。没有运营者记录时，原因仍未确认。多次浏览器运行都返回相同状态，也不能补足缺失的内部证据。

应说明生成记录的观察工具。页面跨源 fetch 可读取的字段可能不同于获授权网络工具可见的字段。页面不能读取某个头时，应记录为该边界不可读，而不是网络响应中不存在。网站所有者可查服务器日志或获准工具，无需仅为满足采集脚本而修改跨源策略。工具可见性限制是证据边界，不是厂商判定。

保留或分享响应样本前，应脱敏 Cookie、授权头、带签名的挑战 URL 和账户数据。允许收集时，只保存分类文档所需的响应体片段。即使状态是 403，响应体也可能包含秘密。事件记录需要足够的背景来复现获授权的故障，不需要可重用的账户会话或无关用户的完整指纹。

信息可用时，应记录响应来自新网络事务还是应用控制的缓存。运营者修改集成后，保存的 HTML 错误仍可能继续显示。把它的旧 Cf-Ray 与当前时间关联，会让调查指向错误请求。保留最初观察时间及响应来源；仅凭页面截图不能证明应用发起了新请求。

跨请求和路径的工作量限制应始终绑定同一应用目的。拒绝响应不是提高并发、轮换地址或重放令牌的指令。完成分类后，有用的下一步是采用运营者批准的访问方法，或停止任务。这为调查提供明确终点，不假定每次拒绝都能在浏览器侧修复。

浏览器控制与访问边界

BotBrowser 自定义头部文档提供设置、读取、更新和删除已配置请求头的控制方式。这些控制作用于浏览器配置，不是设置厂商服务端决策的通道。把响应标记复制进请求，也不会重现生成该标记的可信过程。检查配置时，应明确每个头部的方向。

对于自有应用的测试夹具，这些控制有助于检查预期的应用头是否到达获准目标。自定义 HTTP 头部指南介绍了该浏览器配置边界。夹具结果只能说明夹具观察到什么，不能衡量 Cloudflare 或 DataDome 是否接受请求、评分是否变化或内部检测输入是什么。这里不主张做过此类厂商运行时实验。

浏览器、服务集成与应用分别贡献不同部分的记录。另一家在边缘做类似判定的管理规则组组合方式不同，AWS WAF Bot Control：客户端到底看到什么逐条读了那个结构。BotBrowser 不提供代理容量，不授予厂商许可，也不代表受保护服务作访问决策。拒绝属于预期策略时，应保留为停止条件。网站所有者识别出集成缺陷时，应修复获授权的集成，而不是把浏览器值当作身份证明。

常见问题

Cloudflare 挑战会揭示机器人评分吗？

文档规定的标记识别 Challenge Page。配置动作和评分需要运营者的相关记录；客户端响应不提供评分换算关系。

缺少 DataDome 头部能证明 fail-open 吗？

不能。服务端集成与客户端响应的可见范围不同。归因到该路径前，运营者必须检查真实的模块决策。

成功的 HTTP 响应仍会导致提取失败吗？

会。除了状态，还要检查返回文档和应用结果。预期 JSON 却返回 HTML，不能记录成成功的空数据结果。

自定义请求头能设置厂商决策吗？

浏览器配置变化不等于可信的厂商决策。头部控制适用于自有应用声明的需求，不能据此宣称取得授权。

来源

• Cloudflare：机器人评分
• Cloudflare：检测 Challenge Page 响应
• Cloudflare：HTTP 请求头
• DataDome：验证请求
• BotBrowser：自定义 HTTP 头部

实践结论

提取前先分类响应：可用时使用文档规定的挑战标记，区分 HTTP 状态与应用成功，在获授权运营者提供关联证据前，不确定内部评分或原因。保留最少的脱敏记录，停止被拒绝的任务，并使用网站批准的访问路径。浏览器配置是该流程的输入，不是继续访问的许可。