2026 年的机器人检测诊断 Cloudflare、DataDome 和 Akamai 环境下的爬虫故障

一个月前还能正常运行的爬虫，开始返回 403、挑战页面，或者数据缺失的 HTTP 200 响应。人们首先怀疑的通常是 Cloudflare、DataDome 或 Akamai 新推出的反机器人更新，有时这种判断确实没错。但同样常见的原因是页面模板改了、会话 Cookie 过期了、多出了一次新的重定向，或者某个工作进程池悄悄把并发翻了一倍。

在轮换代理或重建浏览器指纹之前，先弄清楚故障究竟发生在哪里。这一点在 2026 年比以往更加重要，因为检测越来越不局限于单个请求：会话行为、浏览器完整性，以及客户端在一段时间内如何在网站中移动，都可能决定下一个请求是被放行还是被挑战。

本文介绍这三家厂商在 2026 年实际公开记录了哪些变化、每项变化对抓取管道意味着什么，以及一套诊断故障、有选择地升级并衡量恢复效果的实用方法。代码位于 ScraperHub/what-changed-in-cloudflare-datadome-and-akamai-bot-detection-in-2026，这是一个用 Python 编写的诊断框架，用于对响应进行分类并报告可用结果。它不会破解挑战，也不会更改请求身份，本文中的任何内容同样不会这样做。

2026 年机器人检测发生了哪些变化

相关进展中没有哪一项是某种全新的指纹或某个强制性挑战。它们改变的是决策在 何时 做出、决策依据 哪些 证据，以及网站运营方 如何 对待不同类型的自动化流量。

这些是有文档记录的公告和发布，并不能证明每个受保护的网站都在运行它们。其中几项能力在发布时没有公开的正式可用日期。

Cloudflare：检测在第一个请求之后仍在继续

Precursor于7月推出，在整个会话期间评估浏览器信号和行为信号。Cloudflare 的 文档 说明，不断演进的评估会更新存储在 cf_clearance Cookie 中的会话状态，而该状态可能被降级或作废。对爬虫而言，通过第一次挑战已不再是稳定的结果：在启用了 Precursor 的区域上，后续请求可能改变判定。

可用性需要按区域逐一核实。官方 发布更新日志 提到会向所有客户推出，而公告则将 Precursor 定位为 Enterprise Bot Management 的一部分，在今年晚些时候正式可用之前免费提供。

Adaptive Intelligence 随后于8月31日推出。其模型基于实时流量持续重新训练，Enterprise Bot Management 客户可通过 Auto Update Machine Learning 启用它，这使得定期发布带编号的模型版本不再那么具有标志性意义。公告将一次性、短生命周期的规则描述为尚待推出的组件，因此应将其视为计划中的功能，而非已上线的功能。

与此同时，Cloudflare 将 AI 爬虫策略拆分为独立的 Search、Agent 和 Training 控制项。自9月15日起 新区域会获得推荐预设，对依赖广告收入的网站更为严格，运营方可以随时更改。这些是运营方的选择，并非禁止所有自动化请求，而且 Bot Preference Sync 可以将所选偏好写入 robots.txt.

DataDome：挑战完整性与浏览器证据

DataDome 的 基于虚拟机的混淆 将 Device Check 和 Slider 的逻辑编译为字节码，由浏览器内的自定义解释器运行。其主要作用是让挑战更难被逆向工程和低成本重放，而不是新增一类网络指纹。

其 Proof of Browser 技术文章 介绍了结合渲染、WebGL、DOM 变更和时序的检查。这些是厂商自述的机制，本文和配套仓库都没有对其检测效果做基准测试。其 Device Check 文档 说明了检测结果如何触发挑战。

DataDome 还推出了 Agent Trust 方案（5月5日），此前的 Web Bot Auth 支持 则已于1月上线。身份证据可以来自签名认证或其他可信机制。照搬某个知名爬虫的用户代理，既不能确立身份，也不能获得许可。

最后，3.0 版本的 DataDome Apache, Nginx, Cloudflare Worker 和 Fastly 模块更改了路径处理和静态资源排除逻辑。这些是集成层面的变更，取决于每个运营方是否升级，并不是新推出的 TLS 或 HTTP/2 检测器。

Akamai：自适应验证与更细粒度的机器人策略

3月，Akamai 宣布了 Content Protector 的增强功能，其中包括原生应用保护和 Advanced Validation Framework。当被动分析无法得出结论时，AVF 可以请求更多设备或行为数据，并可选择启用交互式挑战。公告没有给出公开的正式可用日期。

Akamai 还将其 AI 机器人流量拆分为 更细粒度的类别：Training Crawlers、Search Crawlers 以及 Fetchers and Agents，并在 Web Security Analytics中提供了相应的筛选器。它们让运营方获得更精细的控制，但并不规定默认操作。

本文查阅的资料 没有公开依据 能证明 Akamai 推出了新的核心 Bot Manager 模型、新的 _abck 格式或新的住宅代理检测器（均指 2026 年内）。同样的审慎也适用于其他领域的常见技术：TLS 指纹、浏览器指纹和 IP 信誉依然重要，但它们的存在并不是 2026 年的新公告。

先诊断故障，再修改爬虫

从一个保存下来的失败响应开始。记录它的时间戳、请求的 URL 和最终 URL、响应头和响应体、爬虫版本、出口位置、会话标识（如适用）以及并发数，并将其与一份已知正常的抓取记录进行比较。缺少这些维度，把一次故障归因于某个厂商的发布基本上就是猜测。

首先排除常见的应用层故障：

1. 标记或解析器漂移： 预期的元素是否仍存在于原始 HTML 中？
2. JavaScript 渲染： 数据是否只有在客户端执行之后，或在之后的某个网络响应中才出现？
3. 身份验证： 请求是否被重定向到登录页、丢失了某个 Cookie，或遇到了过期的 CSRF 令牌？
4. 流量模式： 工作进程数量、请求速率或出口位置是否发生了变化？
5. 重定向和变体： 规范 URL、语言区域、设备版本或内容类型是否发生了变化？

然后对响应本身进行分类，而不是对解析器抛出的异常进行分类。

厂商标记可以缩小排查范围，但单凭它们并不能可靠地归因。Cloudflare 的文档记录了 cf-mitigated: challenge；单独一个 cf-ray 请求头并不能说明请求被拦截，因为每个经过代理的响应都带有它。DataDome 的 Cookie 或挑战端点能提供更多背景信息，而与 Akamai 相关的 Cookie 名称，例如 _abck 和 bm_sz 并不能证明任何具体的防护决策。

将获取判定与内容成功分开看待

借助 Crawling API 可以清楚地观察到这一区别。cb_status 是 Crawlbase 对响应的判定，包括其自身的拦截检查和内容检查。original_status 通常是目标网站发送的状态码。最终的 url 会暴露重定向；使用 format=json 时，这些字段会与响应体以及 domain_complexity 定价等级一同返回。向 https://example.com/ 发出的请求在2026年10月7日返回了：

{
  "original_status": 200,
  "pc_status": 200,
  "cb_status": 200,
  "url": "https://example.com/",
  "domain_complexity": "standard"
}

这些状态码都不能说明产品标题、价格或任何其他业务字段是有效的。稳健的管道会将这些字段的显式校验作为第三层。

配套仓库的分类器位于 final/bot_diag/classify.py，它把这一区别具体化了：

# final/bot_diag/classify.py
def classify_response(
    status: int | None,
    body: str,
    headers: Mapping[str, str] | None = None,
    expected_fields: Sequence[str] | None = None,
) -> str:
    header_map = _header_map(headers)
    text = body or ""
    lowered = text.lower()
    if _is_cloudflare_challenge(lowered, header_map) or _is_datadome_challenge(lowered, header_map):
        return LABEL_CHALLENGED
    is_blocked = (
        _is_akamai_block(text, lowered)
        or _is_cloudflare_block(lowered, header_map)
        or _is_datadome_block(status, lowered, header_map)
        or (status in {401, 403, 429} and bool(text.strip()))
    )
    if is_blocked:
        return LABEL_BLOCKED
    return _content_label(status, text, expected_fields)

这是一段摘录，不是可独立运行的代码片段：导入、标签和辅助函数都位于包中的其他位置。它返回四种标签之一，分别是 blocked, challenged, invalid_content 和 ok。字段校验器刻意保持精简，只支持简单的 JSON 和 HTML 模式，而非生产级的数据模式，因此在将其用于你的数据之前，请先阅读 第 3 步 及其测试夹具。

一个实用的扩展是不只校验字段是否存在，还要校验字段类型、合理范围、跨字段一致性和新鲜度。这样可以发现文章 静默响应投毒中所述的故障：抓取在技术上成功，返回的值却不可用或具有误导性。

按故障类别选择恢复方式

不同的故障需要不同的干预措施。盲目轮换和无条件重试会让证据更难解读，还会增加负载和成本。

请求与会话一致性。 所声明的浏览器身份必须与其传输层、请求头、Cookie 历史和导航顺序保持一致。仅仅更换用户代理或出口 IP，对浏览器完整性检查或会话级评估几乎没有帮助。如果工作流依赖已登录或有状态的导航，请保持出口稳定。

浏览器执行。 当你需要的字段依赖 JavaScript 时再进行渲染。渲染成本更高、速度更慢：在 Crawling API 上，JavaScript 请求按标准费率的两倍计费。渲染并不等于获得了访问目标网站的许可，也不是通用的挑战解决方案。关于运维层面的取舍，请参阅 无头浏览器与抓取 API 的对比.

重试与升级。 对临时性故障进行有上限的退避重试。修正无效的 URL 和选择器，而不是原样重试。对于已确认的拦截，应展开调查，而不是用同样的请求反复冲击。在 Crawling API 上，以下是你最常遇到的状态码以及首先应采取的措施：

失败的调用还会返回 HTTP 状态码 520。这是状态行，而不是 cb_status，因此务必根据响应中的 cb_status 来决定分支。仓库中的 升级步骤 以 520 和 525 作为 JavaScript 升级的触发条件，并添加了 page_wait=2000 和 ajax_wait。复用之前，请先将其与上表对照：遇到 503 或意外的 207，就进行升级；同时将 705 和 706 视为应当放慢速度的信号。这些等待参数有助于处理延迟渲染的内容，但并不能补救失败的挑战。

身份与策略。 对于具名的合法智能体，签名身份和注册可能比模仿任意浏览器流量更合适。Cloudflare Web Bot Auth、DataDome Agent Trust 以及 Akamai 与智能体相关的控制项都属于这一层。经过验证的身份仍然不能保证获得授权。

托管式获取。 Crawlbase 的 Crawling API 适合请求式集成；现有的代理兼容客户端可以直接使用 Smart AI Proxy 接入；而 Enterprise Crawler 则适合排队的批量任务和数据交付。托管基础设施让你无需自行运行浏览器集群和代理池，但支持的目标网站、延迟、额度消耗和失败率仍需实际测量。

用配套项目评估恢复效果

配套 仓库 需要 Python 3.10+，并在 steps/ 下提供六个循序渐进的脚本，另有一个 bot_diag 包，位于 final/目录下。它是一个诊断框架，而 不是针对任何厂商的实时绕过基准测试。 其流程如下：

1. 先使用 Normal token 发起一个 Crawling API 请求，并带上 format=json.
2. 检查 cb_status, original_status、最终 URL 和内容。
3. 对响应进行分类，并校验必需字段。
4. 仅在故障策略确有需要时才重试或升级。
5. 将每个 URL 的一条结果保存到 CSV，并汇总可用结果和重试开销。
6. 按域名展示在 Smart AI Proxy 与 Crawling API 之间的选择。

运行可复现的基线

克隆仓库，安装依赖，然后从无需 token 的合成数据路径开始。在 final 目录中运行：

python -m bot_diag evaluate urls.example.txt --fields price,title --dry-run

进行实时运行时，请设置 CRAWLBASE_TOKEN 以及用于 JavaScript 升级的 CRAWLBASE_JS_TOKEN 环境变量，提供一份你有权抓取的 URL 列表，然后运行：

python -m bot_diag evaluate urls.txt --fields price,title \
  --concurrency 4 --max-retries 2 --out sample_results.csv

评估器将并发上限设为八。它会报告基于输入 URL 计算的 ok 比率、按请求尝试计算的最近秩 p50 和 p95 延迟，以及重试开销。延迟数据不包含重试退避的休眠时间，而 CSV 中每个 URL 只有一行汇总记录，而不是每次尝试一行。将这些数字与生产任务的实际耗时进行比较时，这两点都很重要。

要进行有意义的比较，请在具有代表性的页面类型中抽取大约 100 到 200 个 URL，对每种获取方式应用相同的校验规则，并在不止一天内重复测试。按域名、页面类别、地理位置和渲染模式对结果进行细分。合成测试夹具只能检验程序流程；只有经授权的实时样本才能衡量目标网站的可靠性。

有针对性地为失败域名调整路由

仓库中的 路由示例 按规范化后的主机名统计观察到的挑战次数。低于默认阈值三次时，它继续使用 Smart AI Proxy；达到或超过该阈值时，则将该域名切换到 Crawling API：

# final/bot_diag/routing.py
def route_domain(
    domain: str,
    challenge_counts: Mapping[str, int],
    *,
    threshold: int = DEFAULT_CHALLENGE_THRESHOLD,
) -> str:
    """Return ``api`` after ``threshold`` challenges, otherwise ``proxy``.

    ``proxy`` means the caller's existing HTTP client should keep using
    ``smartproxy.crawlbase.com:8013``. ``api`` means that domain should move
    to the Crawling API. Counts must already be keyed by ``domain_key``.
    """
    if threshold < 1:
        raise ValueError("threshold must be at least 1")
    key = domain_key(domain)
    if challenge_counts.get(key, 0) >= threshold:
        return API
    return PROXY

第 6 步 只会打印决策结果，它 不会 打开代理连接，也不会自动进行故障切换。Smart AI Proxy 的 HTTPS 端点是 smartproxy.crawlbase.com:8013 并采用基于令牌的代理认证，相关的 Smart AI Proxy 文档 介绍了其 CrawlbaseAPI-Parameters 请求头，包括 JavaScript 选项。在该示例中，Crawling API 的升级使用单独的 JavaScript token。

真正的路由服务还需要会过期的计数器、可观测性、熔断机制，以及回到更便宜路由的路径。没有这些，短短三次挑战就会让一个主机名的流量永久切换。

按每个可用结果衡量成本，而不是按每个 HTTP 200

当同一组经过验证的 URL 样本分别通过两种方式运行之后，请将可靠性和总运营成本放在一起比较。

url_completion_rate    = urls_with_valid_final_result / input_urls
attempt_success_rate   = successful_attempts / all_fetch_attempts
cost_per_usable_result = total_allocated_cost / validated_results

分母不同是有意为之。URL 完成率衡量的是任务完成了多少；尝试成功率衡量的是获取路径的效率。不要把两者并列，并都称为“成功率”。

统计代理和计算支出、托管服务商的额度、重试开销、浏览器基础设施和工程维护成本，同时避免重复计算托管费率中已包含的部分。在 Crawlbase 上，只有成功的调用才会计费：目标网站返回的 200、404、410 和重定向、空的 200 响应体（cb_status 207），以及你主动设为成功的任何状态码（通过 custom_success_codes）。拦截和内部故障均不收费。domain_complexity 是定价等级，会对每个计费请求进行倍乘，因此请以账户用量和 Crawlbase 定价 为准查看实际消耗，而不要根据请求数量估算。

在可预测的目标网站上，或在必须完全控制浏览器时，自管客户端可能更经济。当维护特定域名的变通方案开始占用大量工程时间时，托管式获取就更有吸引力。两种方式都不能免去校验返回数据的必要。

结论

2026 年的重要变化集中在 持续性证据、浏览器完整性和更精细的运营方策略。它们都没有让旧的故障模式退出舞台：失效的选择器、过期的会话、失控的并发以及不完整的渲染。

把抓取可靠性当作一个可观测的系统来对待：保留原始响应，将获取判定与目标网站的响应分开，保守地对故障进行分类，有选择地升级，并以经过验证的数据来评判结果。本文的 配套仓库 是实践这一工作流的起点。如果你的抓取基础设施正在成为维护瓶颈，不妨 用 Crawlbase 运行同一批具有代表性的 URL 并在调整架构之前，比较每个可用结果的成本。

主要参考资料

• Cloudflare： Precursor, Precursor 文档, Adaptive Intelligence, AI 流量控制, 混合用途 AI 爬虫策略
• DataDome： 基于虚拟机的混淆, Proof of Browser, Agent Trust, Device Check
• Akamai： Content Protector 增强功能, AI 机器人流量类别, Web Security Analytics 更新

常见问题（FAQ）

为什么爬虫通过了挑战，之后却失败了？

在采用会话级评估的网站上，后续活动可能改变信任判定。在认定第一次挑战是唯一的防护点之前，请先比较请求顺序、Cookie、会话连续性、速率和出口行为。

HTTP 200 是否意味着抓取成功？

不是。它只确认了某一层上有响应返回。挑战页面、空壳页面、被重定向的页面，或看似合理但实际错误的数据，都可能伴随 200 一起返回。在将某个 URL 标记为完成之前，请校验字段及其含义。

住宅代理对现代机器人检测仍然有用吗？

它们有助于解决 IP 信誉和地理访问问题，但解决不了缺失浏览器执行或会话信号不一致的问题。激进的逐请求轮换反而可能让有状态的工作流更不连贯。

哪些 Crawling API 响应会计费？

只有成功的响应，即 cb_status 为 200 的响应（包括目标网站返回的 404、410 和重定向）、空的 200 响应体（报告为 cb_status 207），以及你主动设为成功的状态码（通过 custom_success_codes）。503、704、705 和 706 等拦截以及内部故障都不计费。

Crawlbase 能否保证访问受 Cloudflare、DataDome 或 Akamai 保护的网站？

没有任何服务商能保证覆盖所有目标网站和配置。正确的测试方式是使用一组可重复、经授权的 URL 样本，进行字段级校验，并统计延迟和额度消耗，而不是看单次请求是否成功。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。