就在八年前的今天，我们推出了 1.1.1.1 公共 DNS 解析器，初衷是打造全球最快、也最注重隐私的解析器。我们深知，对于处理“互联网电话簿”的服务而言，信任高于一切。因此，在推出之时，我们就做出了一项独特的承诺，公开证实我们确实按照既定方针处理个人数据。2020 年，我们聘请了一家独立公司来审查我们的工作，而非仅仅要求用户轻信我们的片面之词。当时我们还表示，未来将继续开展此类审查工作。此外，我们也呼吁其他服务提供商效仿此举；然而据我们所知，迄今为止，尚无其他主要的公共 DNS 解析服务商接受过针对其 DNS 隐私实践的独立审查。

在 2020 年进行审查时，1.1.1.1 解析器上线尚不足两年。当时开展审查的目的，是为了证明我们的系统确实兑现了关于 1.1.1.1 解析器运作机制的所有承诺——甚至包括那些与个人数据或用户隐私无直接关联的承诺。

自那时起，Cloudflare 的技术栈在规模与复杂性方面均实现了显著增长。例如，我们构建了一个全新的平台，为 1.1.1.1 解析器及其他 DNS 系统提供底层支持。因此，我们认为有必要再次对我们的系统，尤其是 1.1.1.1 解析器的隐私承诺，进行一次严谨且独立的全面审查。

今天，我们正式发布由同一家“四大”会计师事务所针对我们进行的最新一轮隐私审查结果。这份独立的审查报告现已发布至我们的合规页面供大家查阅。

2024 年结束后，我们随即启动了一项全面的工作流程，着手收集并整理提交给独立审计师的各类佐证材料。此次审查工作历时数月，期间 Cloudflare 内部的多个团队通力协作，提供了大量证据以证明我们的隐私控制措施已切实落地并有效运行。独立审计师完成审查工作后，我们很高兴能在此分享最终的审查报告。该报告证实了我们已切实履行各项承诺：我们的系统在隐私保护方面，确实如我们所承诺的那般安全可靠。最重要的是，我们针对 1.1.1.1 解析器的核心隐私保障保持不变，并通过独立审查得到了验证：

• Cloudflare 不会将公共解析器用户的个人数据出售或分享给第三方，也不会使用公共解析器的个人数据向任何用户定向投放广告。

• Cloudflare 仅会保留或使用查询的内容本身，而不会保留或使用能够识别查询者身份的信息。

• 源 IP 地址经过匿名化处理，并在 25 小时内删除。

此外，我们还希望就两点保持透明。第一：如我们在 2020 年发布的上一次审查结果博客中所解释的，随机抽样的网络数据包（最多占全部流量的 0.05%，包括 1.1.1.1 公共解析器用户的查询 IP 地址）仅用于网络故障排查和攻击缓解目的。

第二，本次审查的范围仅限于我们的隐私承诺。早在 2020 年，我们首次审查不仅涵盖隐私承诺，还包括我们对匿名交易和调试日志数据（即“公共解析器日志”）处理方式的说明，这些数据原本用于公共解析器的正常运营及研究目的。随着时间的推移，我们对这些数据的使用方式发生了一些变化，例如利用这些数据来支持 Cloudflare Radar（该产品发布于我们首次针对 1.1.1.1 进行审查之后）；尽管这种变化改变了我们对日志的处理方式，但并未对个人信息或个人隐私产生任何影响。

正如我们在 6 年前的首次审查中所指出的那样：我们从未试图知晓个人用户在互联网上的具体活动，并且我们已采取相应的技术措施，以确保我们无法获取此类信息。在 Cloudflare，我们坚信“隐私”应当成为一种默认设置。通过主动接受这些独立审查，我们希望能为整个行业树立一个标杆。我们相信，每一位用户，无论是直接上网浏览，还是通过 AI 智能体代其访问网络，都应拥有一个不追踪其行踪的互联网环境。此外，Cloudflare 坚定不移地履行我们在《隐私政策》中所作的承诺：我们绝不会将从 1.1.1.1 解析器 DNS 查询中收集到的任何信息，与 Cloudflare 内部的其他数据或任何第三方数据进行合并，从而以任何方式识别出具体的最终用户身份。

一如既往，感谢您信赖 1.1.1.1，将其作为您通往互联网的门户。有关 1.1.1.1 解析器隐私审查的详细信息以及我们会计师的报告，您可以在 Cloudflare 的“认证与合规资源”页面上查阅。请访问 https://developers.cloudflare.com/1.1.1.1/，深入了解如何开始使用这款全球最快、隐私优先的 DNS 解析器。

Cloudforce One 在过去一年里将数以万亿计的网络信号转化为可落地的情报，发现威胁形势发生了根本性演变：暴力入侵的时代正渐行渐远。取而代之的是一种高信任攻击模式，这种模式优先考虑不惜一切代价取得成果。为了给防御人员配备战略路线图以应对这个新时代的各种挑战，我们今天发布了首份《2026 年 Cloudflare 威胁形势报告》。本报告将介绍企业所需的情报，以应对不断涌现的工业化网络威胁。

Cloudforce One 观察到攻击者的心理发生了更广泛的转变。要理解这些方法是如何成功的，我们必须探究其背后的原因：有效性度量 (MOE)。

2026 年，现代攻击者不再追求“复杂性”（即：复杂、昂贵的一次性攻击），转而追求吞吐量。MOE 是攻击者用于决定下一步攻击目标的指标。它是对投入与实际成效比的冷酷计算。

• 既然窃取的会话令牌（身份信息）具有更高的 MOE，为什么还要使用昂贵的 zero-day 漏洞利用？

• 既然声誉护盾 (LotX) 提供免费、几乎无法追踪且交付率高的基础设施，为什么还要构建自定义服务器？

• 既然 AI 可以自动发现连接最敏感数据的连接纽带信息，为什么还要手动编写代码？

2026 年，最危险的威胁行为者并不是拥有最先进代码的人，而是能够将情报与技术整合到一个单一、连续的系统，并在最短时间内完成使命的人。

2026 年的威胁形势呈现出八个主要趋势，均由 MOE 驱动：

1. AI 自动化执行攻击者的高速操作。威胁行为者利用生成式 AI 进行实时网络映射、漏洞利用开发和制作深度伪造内容，使低技能行为者也能够发起高影响力攻击。

2. 政府支持的预先部署削弱了关键基础设施的韧性。包括 Salt Typhoon 和 Linen Typhoon 在内的中国威胁行为者正优先攻击北美电信、商业、政府和 IT 服务行业，以巩固其在北美的影响力，从而获得长期的地缘政治优势。

3. 权限过高的 SaaS 集成扩大了攻击影响范围。正如 GRUB1 漏洞入侵 Salesloft 的案例所示，第三方 API 集成的网络连接纽带导致单个被入侵的 API 能够引发连锁反应，进而影响数百个不同的企业环境。

4. 攻击者利用可信赖的云工具作为武器，掩盖攻击。威胁行为者积极瞄准各种合法的 SaaS、IaaS 和 PaaS 工具，例如 Google Calendar、Dropbox 和 GitHub，以掩盖正常的企业活动中的恶意行为。

5. 深度伪造身份正将敌对特工渗透至西方企业薪酬体系内部。朝鲜已将远程 IT 员工计划付诸实施，利用深度伪造技术和欺诈性身份将国家支持的特工直接安插到西方公司的薪酬体系中，以从事间谍活动和非法牟利。

6. 令牌窃取导致多因素身份验证失效。通过将 LummaC2 等信息窃取程序作为武器来收集活跃的会话令牌，攻击者可以绕过传统的多因素身份验证，直接进行身份验证后的各项操作。

7. 中继盲区导致内部品牌仿冒成为可能。网络钓鱼即服务机器人利用邮件服务器未能重新验证发件人身份的盲区，将高信任度品牌的仿冒邮件直接发送至用户收件箱。

8. 超大规模攻击耗尽基础设施容量。由 Aisuru 等大型僵尸网络提供支持的超大规模分布式拒绝服务 (DDoS) 攻击不断刷新纪录，显著缩短人工响应的时间窗口。

现在，我们来深入探讨 Cloudflare 发现的一个高 MOE 策略：利用云工具作为武器。攻击者不再使用已知的恶意服务器，而是利用 Google Drive、Microsoft Teams 和 Amazon S3 等合法云生态系统来掩盖其命令与控制 (C2) 流量。这称为“离地攻击”（或“一切即服务”）：攻击者伪装成可信赖的提供商，使其恶意活动几乎与正常的企业流量无法区分。

威胁行为者还利用 SaaS 平台来托管、发起、重定向或扩大攻击。例如，Amazon SES 和 SendGrid 等专为合法批量发送电子邮件而设计的服务经常被用于发起复杂的网络钓鱼和恶意软件分发活动。

尽管利用云资源是一种成熟的攻击手段，但 2025 年的调查显示，国家级攻击组织的策略正加速走向成熟：攻击者从单纯的基础设施滥用转向普遍的离地攻击。我们预测，2026 年，威胁行为者会将这些技术标准化，作为其作战手册中的战略目标。

以下是一些威胁行为者组织、其总部所在地及其采用的攻击方法示例。

确立 MOE 需要的不仅仅是高层次观察。为了真实揭示 2026 年的威胁形势，本报告详细介绍了 Cloudforce One 如何独特地综合利用内部专业知识与全球遥测数据，充分挖掘传统安全模型遗漏的洞见。

我们的方法多种多样。例如：

• 作为 AI 提供支持的防御措施研究的一部分，我们让 AI 编码智能体负责进行自我漏洞分析，利用该智能体发现其自身的安全漏洞。这种“内部测试”方法发现了 CVE-2026-22813 (9.4 CVSS) 漏洞，这是 Markdown 渲染管道中的一个严重缺陷，可能会导致未经身份验证的远程代码执行。

• 我们对网络钓鱼即服务 (PhaaS) 的深入研究表明，准入门槛已不复存在。分析师观察到，攻击者利用高信誉域名（Google Drive、Azure 等）绕过安全过滤。电子邮件遥测发现了一个身份验证漏洞，也就是将近 46% 的分析电子邮件未通过 DMARC 验证（它是一种电子邮件身份验证协议），这揭示了 PhaaS 机器人正在迅速利用这个巨大的攻击面。

• 我们追踪了从隐蔽的漏洞利用到企图发起断网攻击的转变，发现 DDoS 攻击的基准流量达到 31.4 Tbps。我们的遥测数据还显示，在过去 3 个月内，63% 的登录凭证来自其他地方已泄露的账户凭证，并且 94% 的登录尝试源自机器人。

在这项研究的每一个阶段，Cloudforce One 充分利用了我们庞大的全球遥测数据和前沿威胁情报，将看似孤立的事件联系起来。无论我们是在内部测试使用自有 AI 智能体来防范 zero-day 漏洞利用，还是追踪那些利用数百万台已被感染的机器人主机，通过隧道技术和住宅代理发起的攻击，这种统一的可见性能让我们看到单个遭受钓鱼网络攻击的凭证与超大规模分布式拒绝服务攻击之间的联系。

识别这些关联仅仅只是第一步。当威胁以机器速度移动时，以人为中心的防御措施不再是有效的屏障。为了应对“系统发起的进攻”，整个行业的防御人员必须转为采用自主防御模型，才能将攻击者的 MOE 降至零。

这种向自主防御的转变需要超越手动检查清单和碎片化警报的局限。企业必须利用实时可见性和自动化响应功能，强化其网络的连接纽带。在这个新时代，防御目标不仅仅是构建更坚固的防御墙，而是确保系统即使是在无人监测的情况下也能比攻击者更快地做出反应。

为了支持这种转变，我们今天正式推出威胁事件平台重大升级：从简单的数据访问，升级为面向安全运营中心的完全自动化、可视化指挥中心。

借助 Cloudforce 无以伦比的威胁情报可见性和 Cloudforce One 研究人员的专业知识，我们提供您所需的情报，以防范工业化网络威胁。如需查看完整数据集、深入了解案例研究和战术建议，请阅读完整版《2026 年 Cloudflare 威胁形势报告》。

如果您有兴趣进一步了解 Cloudflare 威胁情报、托管防御或事件响应产品，请联系 Cloudforce One 专家。

一些细微的配置错误、被忽略的防火墙事件或请求异常单独来看似乎无害。然而，当这些微小迹象汇聚在一起时，可能会演变成被称为“有害组合”的安全事件。攻击者利用这些漏洞，发现并叠加许多细微问题（例如 Web 应用程序中遗留的调试标志，或未经身份验证的应用程序路径），以入侵系统或窃取数据。

Cloudflare 网络会观测对客户技术栈的请求，因此，在有害组合形成过程中，能够对这些迹象加以识别。在这篇博文中，我们将介绍 Cloudflare 如何从应用程序安全数据中发现这些迹象。我们将讨论最常见的有害组合类型及其带来的危险漏洞。我们还将详细介绍如何利用这些情报来识别并解决技术栈中的弱点。 

可以采用几种不同的方式来定义“有害组合”，但我们将在本文中提供一种基于自身数据集的实用方法来定义。大多数网络攻击最终通过自动化来实现规模化；攻击者发现可行的漏洞利用后，通常会将其编写成脚本并植入机器人，以此来发起攻击。通过分析机器人流量、特定应用程序路径、请求异常和错误配置的交集，我们可以发现潜在的安全漏洞。我们利用这个框架来分析每秒数百万个请求。

虽然 Web 应用防火墙 (WAF)、机器人检测和 API 保护等单点防御措施已经发展到能够整合行为模式和声誉信号，但它们仍然主要侧重于评估单个请求的风险。相比之下，Cloudflare 看待“有害组合”检测的视角则转向更广泛的意图，通过分析围绕多个信号的上下文交集来识别正在酝酿之中的攻击事件。

^{基于上下文的有害组合检测}

这种视角转变至关重要，因为许多真实的攻击事件没有明显的漏洞利用恶意有效负载、没有无害的签名，也没有直接表明这是一次“攻击”的单一事件。因此，下文中，我们将结合以下上下文构建几种潜在的有毒组合：

• 机器人信号

• 应用程序路径，尤其是各种敏感路径：管理、调试、指标、搜索、支付流程

• 异常情况包括：意外的 http 代码、地理位置跳转、身份不匹配、ID 频繁变更、速率限制规避（多个分布式 IP 地址执行相同操作）、请求或成功率激增 

• 漏洞或配置错误：缺少会话 cookie 或身份认证标头、可预测的标识符

我们查看了 Cloudflare 24 小时数据，以了解这些模式在热门应用程序技术栈中实际出现的频率。如下表所示，我们分析的主机中约有 11% 的主机易受此类有害组合的攻击，但易受攻击的 WordPress 网站导致分析失真。如果排除 WordPress 网站，则只有 0.25% 的主机显示了可利用的有毒组合的迹象。虽然这个比例极少，但它们代表容易容易遭到入侵的主机。

为了理解数据，我们将一次攻击过程划分为三个阶段：

• 估算已探测的主机：这是“广撒网”的阶段。它会计算针对特定敏感路径（例如 /wp-admin）的 HTTP 请求所对应的唯一主机。

• 估算按有害组合筛选的主机：在这个阶段，我们将主机清单缩小到符合我们定义的有害组合标准的特定主机。

• 估算可访问的主机：成功响应了漏洞利用尝试的唯一主机，这是攻击的“确凿证据”。简单的 200 OK 响应（例如，通过附加 ?debug=true 触发的响应）可能是误报。我们对路径进行了验证，以过滤各种原因引起的干扰：即使状态代码为 200 也需要凭据的已验证路径；掩盖真实漏洞利用路径的重定向；以及为无法访问的路径提供成功代码的源配置错误。

在下几节中，我们将深入探讨这些具体发现及其背后的逻辑驱动因素。提供的检测查询是必要的，但如果不进行可访问性测试，则不足以得出确切的结果；因为检测结果可能是误报。在某些情况下，Cloudflare Log Explorer 支持对未采样的 Cloudflare 日志执行这些查询。

表 1.有害组合摘要

我们观察到自动化工具扫描了常见的管理员登录页面，例如 WordPress 管理面板 (/wp-admin)、数据库管理器，以及服务器仪表板。Cloudflare Log Explorer 中执行的模板化查询版本如下所示：

SELECT
  clientRequestHTTPHost,
  COUNT(*) AS request_count
FROM
  http_requests 
WHERE
  timestamp >= '{{START_DATE}}'
  AND timestamp <= '{{END_DATE}}'
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '{{PATH_PATTERN}}' //e.g. '%/wp-admin/%'
  AND NOT match( extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$') // comment this line for Cloudflare Log Explorer
  AND botScore < {{BOT_THRESHOLD}} // we used botScore < 30
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

可公开访问的管理面板可能会让攻击者能够发起暴力破解攻击。如果成功，攻击者可能通过将面板添加到僵尸网络来进一步入侵主机，而僵尸网络会探测其他网站是否存在类似的漏洞。此外，这种有毒组合可能会导致：

• 漏洞利用扫描：攻击者会识别您正在运行的特定软件版本（例如 Tomcat 或 WordPress），并针对已知漏洞 (CVE) 发起有针对性的漏洞利用攻击。

• 用户枚举：许多管理面板会意外泄露有效的用户名，这有助于攻击者精心策划更具有说服力的网络钓鱼或登录攻击。

机器人自动化与暴露的管理接口的有害组合，例如：/wp-admin/、/admin/、/administrator/、/actuator/*、/_search/、/phpmyadmin/、/manager/html/ 和 /app/kibana/。

1. 实施 Zero Trust 访问。 

2. 如果由于任何原因端点必须保持公开，请部署一个质询平台，以增加机器人的访问难度。

3. 实施 IP 允许列表：使用 WAF 或服务器配置，确保只能通过贵公司 VPN 或特定办公室 IP 地址才能访问管理路径。

4. 隐藏管理路径：如果贵公司的平台允许，则重命名默认的管理 URL（例如，将 /wp-admin 更改为难以猜测的唯一字符串）。

5. 部署地理位置屏蔽：如果管理员仅从特定国家/地区执行操作，请屏蔽这些区域以外流向这些敏感路径的流量。

6. 强制执行多因素身份验证 (MFA)：确保每个管理入口点都需要验证第二个因素；仅依靠密码不足以阻止专用爬网程序。

我们发现了一些 API 端点，互联网上的任何用户无需密码或登录即可访问（请参阅 OWASP: API2:2023 - 失效的身份验证）。更糟糕的是，它识别记录的方式（使用简单、可预测的 ID 号，请参阅 OWASP: API1:2023 - 失效的对象级授权）让任何用户都可以轻松地“计算”您的数据库数量，从而使攻击者无需直接访问您的网站即可枚举并“抓取”业务记录。

SELECT
  uniqExact(clientRequestHTTPHost) AS unique_host_count
FROM  http_requests
WHERE timestamp >= '2026-02-13'
  AND timestamp <= '2026-02-14'
  AND edgeResponseStatus = 200
  AND bmScore < 30
  AND (
       match(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'),  '^[0-9]{3,10}$')
    OR match(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)'), '^[0-9]{3,10}$')
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'))  BETWEEN 3 AND 8
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)')) BETWEEN 3 AND 8
  )

这是一个“零利用”漏洞，也就是说，攻击者无需是黑客即可窃取您的数据；他们只需更改 Web 链接中的某个数字即可。这会导致：

• 大规模数据泄露：大规模抓取您的整个客户数据集。

• 二次攻击：被盗数据用于针对性网络钓鱼或帐户接管。

• 监管风险：因泄露敏感的个人可识别信息 (PII)，可能严重违反隐私条例 (GDPR/CCPA) 的规定。

• 欺诈：竞争对手或恶意行为者可能获取您的业务量和客户群信息。

缺少安全控制措施与针对特定 API 端点的自动化攻击的有害组合。

查询核实了机器人分数和可预测的标识符，同时也在与查询匹配的流量样本中测试了高基数、稳定的响应大小和缺少身份验证等信号。

1. 强制执行身份验证：立即要求受影响端点提供有效的会话或 API 密钥。禁止匿名访问包含个人可识别信息或商业机密的数据。

2. 实施授权（IDOR 检查）：确保后端核实已执行身份验证的用户是否确实拥有查看其请求的 tid 的权限。

3. 使用 UUID：将可预测的连续整数 ID 替换为长随机字符串 (UUID)，使用户无法通过计算“猜中”标识符。

4. 部署 API Shield：启用 Cloudflare API Shield，它提供架构验证（用于阻止意外输入）和 BOLA 检测等功能。

我们发现了攻击者将 debug=true 附加到网络路径来泄露系统详细信息的证据。Cloudflare Log Explorer 中执行的模板化查询版本如下所示：

SELECT
  clientRequestHTTPHost,
  COUNT(rayId) AS request_count
FROM
  http_requests
WHERE
  timestamp >= '{{START_TIMESTAMP}}'
  AND timestamp < '{{END_TIMESTAMP}}'
  AND edgeResponseStatus = 200
  AND clientRequestQuery LIKE '%debug=false%'
  AND botScore < {{BOT_THRESHOLD}}
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

虽然这不会立即窃取数据，但它为攻击者提供了您的内部基础设施的高清地图。这种“侦察”模式会显著提高攻击者下一次攻击的成功率，因为他们能够看到：

• 隐藏的数据字段：不应向用户显示的敏感内部信息。

• 技术栈详细信息：特定的软件版本和服务器类型，让攻击者能够查找这些版本的已知漏洞。

• 逻辑提示：准确阐述代码工作原理的错误消息或技术栈跟踪，帮助攻击者找到破解代码的方法。

自动探测与针对多个主机和应用程序路径的错误配置诊断标志的有害组合。

查询检查了机器人分数和带有调试参数的路径，同时也在与查询匹配的流量样本中测试了重复的探测、响应大小和模式泄露等信号。

1. 禁用生产环境中的调试：确保在生产部署配置中将所有“debug”或“development”环境变量严格设置为 false。

2. 在边缘过滤参数：使用 WAF 或 API 网关，在已知的调试参数（例如 ?debug=、?test=、?trace=）到达应用程序服务器之前将其剔除。

3. 清理错误响应：配置 Web 服务器（Nginx、Apache 等）以显示通用错误页面，而不是显示详细的技术栈跟踪或内部系统消息。

4. 审核 firebase/DB 规则：如果使用 Firebase 或类似的 NoSQL 数据库，请确保通过严格的安全规则限制对 /.json 路径的访问，以防止公共用户转储整个数据库模式或数据。

我们发现了“运行状况检查”和监测仪表板对整个互联网可见。具体而言，/actuator/metrics 等路径会响应任何提问的用户。Cloudflare Log Explorer 中执行的模板化查询版本如下所示：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // an example
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

为什么这个问题很严重？

虽然这些端点通常不会直接泄露客户密码，但却为复杂攻击提供了“蓝图”。暴露这些端点会导致：

• 战略时机选择：攻击者可以实时监测您的 CPU 和内存使用情况，在系统已经不堪重负的情况下发动拒绝服务 (DoS) 攻击。

• 基础设施映射：这些日志通常会泄露内部服务的名称、依赖项和版本号，帮助攻击者找到已知的漏洞并加以利用。

• 漏洞利用链接：有关线程计数和环境提示的信息，可用于绕过安全层或提升网络权限。

访问控制配置错误与针对 Asset/Path: /actuator/metrics, /actuator/prometheus, and /health 的自动化侦察的有害组合。

1. 通过 WAF 限制访问：立即创建防火墙规则，以阻止任何包含 /actuator/ 或 /prometheus 的路径的外部流量请求。

2. 绑定到本地主机：重新配置应用程序框架，使其仅在 localhost (127.0.0.1) 或私有管理网络上为这些监测端点提供服务。

3. 强制执行基本身份验证：如果必须通过 Web 访问这些端点，请确保它们受到强身份验证（至少是复杂的基本身份验证或 mTLS）的保护。

4. 禁用不必要的端点：在 Spring Boot 或类似框架中，禁用并非生产环境监测所必需的“Actuator”功能。

通常仅供内部使用的搜索端点（例如 Elasticsearch 或 OpenSearch）现在对公众完全开放。模板化查询如下所示：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/\_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$')
GROUP BY
  clientRequestHTTPHost

这是一个非常严重的漏洞，因为它无需任何技术技能即可利用，但造成的破坏却相当严重：

• 大规模数据窃取：攻击者可以“转储”整个索引，在几分钟内窃取数百万条记录。

• 内部侦察：通过查看“索引”（您存储内容的列表），攻击者可以识别网络中的其他高价值目标。

• 数据破坏：根据配置的不同，攻击者不仅会读取数据，而且还可能修改或删除整个搜索索引，从而导致大规模服务中断。

我们看到了错误配置的暴露与针对  /_search, /_cat/indices, and /_cluster/health 的自动化流量和数据枚举的有害组合。

查询检查了机器人分数和路径，同时也在与查询匹配的流量样本中测试了重复的查询模式、响应大小和模式泄露等信号。 

1. 限制网络访问：立即更新防火墙/安全组，以确保只能从特定的内部 IP 地址访问搜索端口（例如 9200、9300）和路径。

2. 启用身份验证：为搜索集群启用“安全”功能（例如 Shield 或 Search Guard），要求每一次 API 调用都提供有效凭据。

3. WAF 拦截：部署 WAF 规则以立即阻止来自公共互联网的任何包含 /_search、/_cat 或 /_cluster 的请求。

4. 审核数据丢失：检查数据库日志，以了解来自未知 IP 的大量“Scroll”或“Search”查询，从而确定究竟泄露了多少数据。

我们已经识别了攻击者发送的恶意请求，具体而言是旨在欺骗数据库的 SQL 注入。Cloudflare Log Explorer 中执行的模板化查询版本如下所示：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

这是数据泄露的“隐蔽途径”。由于系统返回了成功状态代码 (HTTP 200)，因此，这些攻击通常与合法流量混合在一起。如果不加以处理，攻击者可以：

• 优化方法：通过反复试验，找到能够绕过过滤器的确切恶意有效负载。

• 外泄数据：使数据库内容缓慢地外流，或泄露 URL 中传递的敏感信息（例如 API 密钥）。

• 保持隐蔽：大多数自动化警报会查找“已被拒绝”的攻击尝试；“成功的”漏洞利用在海量的日志记录中更难发现。

我们看到了针对许多应用程序路径的自动化机器人信号、异常情况以及应用层漏洞的有害组合。

1. 立即进行虚拟修补：更新 WAF 规则，以专门阻止已识别的 SQL 模式（例如，基于时间的探测）。

2. 清理输入：检查此路径的后端代码，确保其使用预处理语句或参数化查询。

3. 补救密钥泄露：将所有敏感数据从 URL 参数移至请求正文或标头。轮换任何标记为“已泄露”的密钥。

4. 审计日志：检查数据库日志，查找“HTTP 200”响应的时间范围，以确认是否成功提取了任何数据。

信用卡测试和信用卡盗刷是最常见的欺诈手段之一。攻击者可能从暗网上购买大量信用卡。然后，为了验证有多少张卡仍然有效，他们可能会在网站上通过进行小额交易来测试这些卡。一旦验证成功，他们可能会使用这些信用卡在热门购物网站上购买商品，例如礼品卡。

在支付流程（/payment、/checkout、/cart）中，我们发现一天之中的某些时段，机器人每小时的请求量或每小时的支付成功率比过去 30 天的每小时基线值高出 3 个标准差。这可能与信用卡测试有关，攻击者试图验证大量被盗的信用卡。当然，营销活动也可能导致请求量激增，而支付服务中断则可能导致成功率骤降。

在没有营销活动、支付服务中断或其他因素影响的情况下，支付成功率下降与请求量激增同时发生，这可能意味着机器人正在进行大规模的信用卡测试。

我们针对 /payment、/checkout、/cart 使用了机器人信号与异常情况组合：

对支付路径上所有机器人分数低于 30 的请求，使用 30 天支付路径的每小时请求量基准作为每小时速率限制。  

在支付流程（/payment、/checkout、/cart）中，我们发现一天之中的某些时段，来自人类（或假冒真人的机器人）的每小时请求量或每小时支付成功率比过去 30 天的每小时基线值高出 3 个标准差。这可能与信用卡盗刷有关，攻击者（可能是真人用户或假冒真人的机器人）尝试使用有效但被盗的信用卡购买商品。当然，营销活动也可能导致请求量和成功率激增，因此，来自特定 IP 地址的典型支付请求形式的额外上下文是必不可少的信息，如图所示。

在没有营销活动、支付服务中断或其他因素影响的情况下，支付成功率激增与请求量激增以及每个 IP 地址的高密度请求同时出现，这可能意味着真人用户（或假冒真人的机器人）正在进行欺诈性购买。这种情况下的每一笔成功交易都可能导致直接的收入损失或潜在的退款。

我们针对 /payment、/checkout、/cart 使用了机器人信号与异常情况组合：

基于身份的速率限制：利用 IP 密度，对支付端点上机器人分数 ≥ 30 的请求实施速率限制。

监测成功率：当支付端点上机器人分数 >=30 的“真人”流量成功率比其 30 天基线值高出 3 个标准差时，发出警报。

提出质询：如果某个高机器人分数请求（可能是真人）在 10 分钟内访问支付流程超过 3 次，则触发质询以降低其访问频率。

目前我们正在努力将这些“有害组合”检测结果直接集成到安全见解仪表板中，以便用户能够即时查看和了解此类风险。我们的路线图包括构建 AI 辅助的修复路径，届时仪表板不仅会显示有害组合，还会提出具体的 WAF 规则或 API Shield 配置，以消除此类组合带来的威胁。

我们诚邀您体验 Cloudflare 安全见解中新增的“有害组合”检测功能。单击此处即可加入候补名单。

^{Turnstile 小部件，数百万个网站的常见情况}

我们说很大一部分互联网流量都离不开 Cloudflare 平台，这是真心的。Cloudflare Turnstile 小部件和质询页面每天的服务次数高达 76.7 亿次。这不是笔误。数十亿次。这可能是互联网上最常见的用户界面。

而这也伴随着巨大的责任。

设计一款吸引数十亿用户关注的产品，不仅充满挑战，而且需要采用截然不同的方法。每一个像素、每一个单词、每一次交互都必须满足不同用户的需求：这些用户可能是日本乡村的祖母、圣保罗的青少年、柏林的视障开发人员，以及拉各斯忙碌的高管。同时服务所有这些用户。在他们感到沮丧的时候。

今天，我们将分享重新设计 Cloudflare Turnstile 和质询页面的故事。这个故事分为三个部分，由三人讲述：一是影响决策的设计流程和研究 (Leo)；二是以空前规模部署变更的工程挑战工程难题 (Ana)；三是这对数十亿用户的可衡量的影响 (Marina)。

首先，介绍我们如何从设计角度解决这个问题。

说实话，没人喜欢系统要求证明自己是真人用户。您知道您是真人。我知道自己是真人。似乎唯一不相信这一点的是那个挡在您与您尝试访问的网站之间的小部件。最好的情况下，这只是一个小小的不便。最坏的情况下会发生什么呢？您可能气得想把电脑扔出窗外。我们都经历过这种情绪。没有人会责怪您。

^{Turnstile 集成到登录流程}

鉴于世界开始逐渐接受看似不可避免的 AI 革命，安全验证需求只会与日俱增。Cloudflare 发现，机器人攻击显著增加。为此，企业正在加大投资来部署安全措施。这意味着，更多最终用户需要更频繁地接受更多质询。

数据说明了一切：

2023 年：每天 21.4 亿次

2024 年：每天 30 亿次

2025 年：每天 53.5 亿次

也就是说，安全检查次数平均同比增长 58.1%。安全检查增多，则意味着最终用户感到沮丧的可能性更大。集成这些验证系统来保护自身及其客户的公司越多，用户在某个场景获得糟糕体验的可能性就越高。

我们意识到，是时候认真审视我们的旗舰产品并扪心自问：对于获得这种体验的数十亿用户而言，我们是否做了正确的事？我们是否履行了帮助构建更好的互联网的使命，不仅是更安全，而且是更人性化的互联网？

我们发现，答案是：我们可以做得更好。

在重新设计任何产品之前，我们需要了解现有的产品。首先，我们对 Turnstile 与质询页面的每一种状态、每一个错误消息和每一个交互进行了全面审核。

我们发现，情况并不理想。

^{Turnstile 小部件中的状态不一致。多种状态，没有统一的方法}

各种不一致非常明显。我们没有采用统一的方法来应对众多不同的错误场景。一些提示消息过于冗长且技术性过强（例如“您的设备时钟设置错误”或“此质询页面被中间服务器意外缓存且不再可用”）。另一些消息则过于模糊，毫无帮助（例如“已超时”）。视觉语言形式各异：不同的布局、不同的层次结构、不同的语气。

我们还仔细检查了在线收到的反馈，包括社交媒体、支持工单、社区论坛，我们认真阅读了所有内容。用户的沮丧之情显而易见，而很多问题原本可以避免。

以我们的反馈机制为例。我们为用户提供了反馈选项，例如“小部件有时故障”与“小部件总是故障”。但两者之间到底有何实质区别呢？用户应该怎样判断小部件的故障频率呢？我们要求用户在他们最沮丧的时刻解读模棱两可的选项。留下的解读空间越大，反馈的实用性越低；在各种社交频道上看到的用户沮丧体验也越多。

^{之前的反馈界面：“小部件有时故障”与“小部件总是故障”有什么区别？}

质询页面（当检测到可疑活动或网站所有者启用了更高级安全设置时，显示的整页安全阻止提示）也存在类似的问题。有些状态令人困惑。有些状态使用了过多技术术语。许多提示未能在用户最需要的时候提供可执行的指导。

^{质询页面上的状态不一致。多种状态，没有统一的方法}

这次审核我们感到惭愧。但它也让我们清楚地了解了需要重点关注的方向。

为了改善体验，我们首先需要了解用户可能选择的每一条路径。什么是理想路径？是否存在理想路径？哪些路径会导致用户越来越沮丧？

^{绘制完整的用户旅程图：从初次遇到各种错误场景开始，并进行情绪跟踪}

这需要真正的跨职能合作。我们与像 Ana 这样的工程师紧密合作，她了解各种极端情况的技术细节；也与产品团队的 Marina 合作，她不仅了解产品的工作原理，还了解用户的产品使用感受，包括我们在网上看到的爱与恨。

Cloudflare 拥有一些最优秀的机器人防护专家。但智慧与清晰不是一回事。技术复杂性与用户易用性之间存在微妙的平衡。只有当这两者完美融合时，我们才能以真正易于用户理解的方式传达信息。

关键在于：信息必须对所有用户有效。任何年龄的人。任何身心能力的人。任何文化背景的人。任何技术水平的人。这就是规模化设计的真正含义：不能忽视极端情况，因为在如此规模上，它们已不再是极端情况。

用户体验设计中最具影响力的书籍之一是 Steve Krug 撰写的《Don't Make Me Think》。核心原则非常简单：用户试图解读、理解或解码界面的每一刻，都会产生一次摩擦。而摩擦，尤其是在令人沮丧的时刻，会导致用户放弃。

我们通过审核发现，要求用户考虑的太多。在不同状态下，不同的信息占据了用户界面的相同空间。缺乏一致的视觉层次。在 Turnstile 中遇到错误状态的用户，可能会发现此类信息的位置与其在质询页面上找到的信息位置完全不同。

我们做出了一个基本的决策：采用统一的信息架构。

^{视觉图显示了统一的信息架构，在 Turnstile 小部件与质询页面中保持一致的结构}

如今，Turnstile 与质询页面都遵循相同的结构模式。相同的视觉层次。相同的操作、说明文本和文档链接位置。

这是否限制了我们的设计方案？当然。我们不得不拒绝许多不符合该框架的创意。但限制并不是优秀设计的敌对面，反而往往是优秀设计的最佳伙伴。通过限制设计方案，我们可以更深入地研究真正重要的细节。

对用户来说，好处显而易见：他们无需重新学习用户界面中每个部分的含义。错误状态看起来是一致的。帮助链接始终位于同一位置。一旦理解了一种状态，就会理解所有状态。这可以最大限度地降低认知负担，正是安全验证过程中应有的水平。

在重新设计数十亿用户会看到的界面时，您如何承担自身责任？测试。海量测试。

我们招募了来自 8 个不同国家/地区的 8 位参与者，刻意寻求参与者的年龄、数字素养和文化背景方面的多样化。我们并不是为了寻找精通技术的早期采用者，而是希望了解重新设计后的界面如何适用于每一位用户。

我们的方法非常严谨：参与者既体验了现有功能，也体验了改进方案，但他们并不知道哪个是“旧版”，哪个是“新版”。我们通平衡了两种方案的呈现方式，以消除偏见。我们不仅测试了新创意，还挑战了最初关于哪些方面需要改进的假设。

^{A/B 测试中测试的两个不同 Turnstile 版本}

一种假设：我们是否应该与竞争对手保持一致？大多数验证码提供商在所有状态下都会显示“我是真人”。我们使用不同的内容，首先显示“验证您是真人”，然后“正在验证…”，然后“成功”！

是否使事情过于复杂化？我们进行了直接对比测试。

我们的方法以压倒性优势胜出。对于交互状态，“验证您是真人”获得了 5 分（满分 8 分），而“我是真人”只得了 3 分。对于验证状态，差距更加显著，7.5 分对比 0.5 分。用户想要知道正在发生什么，而不仅仅是被告知发生了什么。

^{用户测试结果：用户非常喜欢我们的方法，而不是竞争对手的设计风格}

这个实验最终没有作为一项功能发布，但它非常有价值。它让我们确信，我们并不是为了标新立异而与众不同。有些方面已经做得很好。

研究发现，我们在四个方面未能满足用户需求：

提供帮助，而不是繁琐的流程。当用户遇到错误时，我们提供了“发送反馈”选项。在测试过程中，他们感到困惑不解。“我应该把反馈发送给谁？网站？Cloudflare？我的互联网服务提供商？”更重要的是，我们发现了一个根本的问题：在用户感到极度沮丧时，他们并不想提交报告，而是希望解决问题。我们将“发送反馈”替换为“故障排除”，这个简洁的词语承诺采取行动，而不是启动繁琐的流程。

^{有问题的“发送反馈”提示词：用户不知道向谁发送反馈}

提醒注意，而不是发送警报。我们使用了大量红色背景，用于提示错误。测试中“不假思索”的反应：参与者认为自己操作失败，感到有心无力。即使是可以通过重试解决的简单问题，用户也会往最坏的方面想，然后放弃。饱和度极高的红色并没有传达“这里有一些问题需要解决”的信息。它传达的信息是：“你操作失败，且无能为力。”解决方案：仅图标使用红色，文本或背景切勿使用红色。

^{演变过程：从使用红色显示不清晰的错误状态描述，到使用中性色文本进行更清晰、简洁的错误信息沟通。}

简洁易读，而不是冗长难懂。我们尝试保持透彻周全，从技术细节详细解释错误。结果却适得其反。非技术用户觉得难以理解。技术用户根本不需要这些解释。每个人都试图在小部件的狭小空间内阅读这些内容。我们得到的教训是：少即是多，尤其是在空间有限、压力大的情况下。

人人可用。我们通过审核发现，某些页面使用了 10px 字体。灰色文本虽然在技术方面符合 AA 级标准（普通文本至少 4.5:1，大文本至少 3:1），但实际阅读起来却比较困难。如果服务对象是整个互联网用户，“技术上符合标准”是远远不够的。

我们制定了明确的目标：满足 WCAG 2.2 AAA 级标准，这是最高且最严苛的 Web 无障碍访问合规要求，旨在让包括重度残障人士在内的最广泛的用户群体均可访问网站内容。在整个重新设计过程中，当视觉一致性与可读性发生冲突时，我们始终优先考虑可读性。每一次都是如此。

这不仅仅局限于视觉功能方面。我们的设计面向屏幕阅读器用户、仅使用键盘导航的用户，以及色觉障碍人士，这超越了自动化合规工具的检测范围。

无障碍访问设计不仅要考虑各种障碍人士的需求，而且还涉及到语言。简洁的英语内容，翻译成德语后可能显得冗长。言简意赅的西班牙语内容，翻译成日语后可能模糊不清。支持 40 多种语言迫使我们进行彻底的简化。现在，相同的“无法连接到网站/故障排除”模型消息，适用于英语、保加利亚语、丹麦语、德语、希腊语、日语、印尼语、俄语、斯洛伐克语、斯洛文尼亚语、塞尔维亚语、菲律宾语等多种语言。

^{重新设计的错误状态，支持 12 种语言；即使文本长度不同，布局也保持一致}

所以，我们最终发布的成品是什么？

首先，我们介绍一下哪些部分没有改动。合适的路径（“验证您是真人”→“正在验证...”→“成功！”）测试结果非常好。用户了解每个阶段发生的情况。我们之前担心每种状态的不同内容可能会使消息过于复杂，但实际上，这反而成为了我们的竞争优势。

^{合适的路径：验证您是真人→正在验证→成功！这些状态测试良好，基本保持不变}

但对于需要改进的状态，我们根据所有反馈进行了重大修改。

我们大幅减少了处于错误状态的文本数量。现在，我们不再提供冗长的解释说明，例如“您的设备时钟设置错误”或“此质询页面被中间服务器意外缓存且不再可用”，而是显示：

1. 清晰、简单的状态名称（例如：“设备时间不正确”）

2. 醒目的“故障排除”链接

仅此而已。详细的指南现在位于一个专门的模态框屏幕，该屏幕支持用户根据需要打开，让其拥有足够的空间来真正阅读并按照故障排除步骤进行操作。

^{故障排除模态框：在用户需要时提供详细的指南，且不会使小部件显得杂乱无章}

故障排除模态框会提供上下文信息（“当您的设备时钟或日历设置不准确时，会发生此错误。若要完成网站的安全验证流程，您的设备必须设置为您所在时区的正确日期和时间。”）、编号列举的尝试步骤、文档链接，以及（仅在用户尝试解决问题后）向 Cloudflare 提交反馈的选项。首先获取帮助，然后提交反馈。

现在，每种状态的对比度和可读性均符合 WCAG 2.2 AAA 级标准。字体大小已设定最小值。交互元素清晰可聚焦，并且可供屏幕阅读器正确朗读。

无论用户遇到的是紧凑的 Turnstile 小部件，还是完整的质询页面，信息架构现在都保持一致。相同的层次结构。相同的布局。相同的心理模型。

如今，质询页面采用简洁的设计结构：顶部是网站名称和收藏夹图标，下方是清晰的状态信息（例如“验证成功”或“您的浏览器版本过旧”），以及可操作的指导说明。不再有密密麻麻的橙色或红色文字。不再有晦涩难懂、缺乏上下文的技术术语。

^{重新设计的质询页面提供清晰的故障排除说明。}

每一则消息均已在 40 多种支持的语言中进行了测试。我们的流程包含三层验证：

1. 设计团队进行初步的设计审核

2. 由合格供应商提供的专业翻译

3. 由 Cloudflare 母语员工进行最终检查

这不仅关乎翻译的准确性，也是为了确保视觉设计在不同语言的内容长度存在显著差异的情况下依然有效。

最终成果是安全验证体验更清晰、更易用、更流畅，而且至关重要的是，同样安全。我们没有为改善体验而牺牲安全保护。我们证明了良好的设计与高安全性并不冲突。

^{左侧是重新设计的 Turnstile 小部件，右侧是重新设计的质询页面}

但是，设计体验只是成功的一半。将其分发给数十亿用户？这正是 Ana 的用武之地。

有人可能会说，作为前端工程师最困难的部分是将 div 元素居中。实际上，真正的挑战往往隐藏在更深层次，尤其是在深入接触平台原语的情况下。使用原生 API 构建互联网基础设施的关键部分，会迫使人以不同的视角思考 UI 开发、权衡取舍以及长期可维护性。

在我们的案例中，我们使用 Rust 处理 Turnstile 小部件和质询页面的 UI。这项决策带来了跨平台的安全性和一致性方面的显著优势，但也增加了前端的复杂性。许多前端工程师已经习惯了采用符合人体工程学的 React 等现代框架，在这些框架中，常见的 UI 交互几乎都是免费。使用 Rust 意味着即使是简单的交互，也需要使用更低级别的构建（例如 document.getElementById、createElement 和 appendChild。

此外，与基于 JavaScript 的框架相比，编译时间和严格的检查自然会减缓 UI 的快速迭代。由于工具生态系统仍在不断演变，调试也变得更加复杂。这些限制促使我们在 UI 开发过程中更加慎重、深思熟虑，最终也更加严谨。

那些最初看似微小的视觉调整，例如内边距调整或对齐方式更改，很快就暴露了一个更大的难题：如何进行内容国际化。

翻译完成后，我们必须确保内容在 38 种语言和 16 种不同的 UI 状态下仍然可读且可用。仅文本长度的变化就需要做出谨慎的设计决策。有些译文的长度可能比英文长 30% 到 300%。像“Stuck?”这样的简短英文字符串，它的印尼语版本会变成“Tidak bisa melanjutkan?”，德语版本会变成“Es geht nicht weiter?”，这会极大地改变布局要求。

支持从右到左显示的语言，这又增添了一层技术复杂性。支持阿拉伯语、波斯语或法尔西语，以及希伯来语，不仅仅只是翻转文本方向那么简单。整个布局必须镜像显示，包括对齐方式、导航模式、方向图标和动画流程。许多元素的设计理念隐含从左到右显示的假设，因此，我们必须重新审视这些元素，使其真正实现双向显示。

有序列表也需要特别注意。并非所有文化都使用西方的 1、2、3 编号系统，硬编码数字序列会让界面显得格格不入或不正确。我们采用了符合本地规范的编号系统和完全可翻译的列表格式，确保每种语言中的排序都自然流畅且符合文化习惯。

随着我们开始在反馈报告中列出行动要点，正确性变得愈发重要。需要正确渲染所需的每个操作，触发正确的流程，以及在各种状态、语言和极端情况下表现一致。

为了实现这一目标，我们投入了大量资源进行测试。单元测试帮助我们独立验证逻辑，而端到端测试则确保新的状态和语言在实际场景中能够按预期正常运行。这种测试基础让我们有信心安全地进行迭代，防止回归，并确保反馈报告对用户来说始终可靠且实用。

最初的一系列技术限制，最终转化为构建更强大、更具包容性且经过充分测试的 UI 系统的契机。处理减少抽象层级和更深入了解浏览器底层原语的过程，迫使我们重新思考了设计元素假设，改进了内容国际化策略，以及提高了整体质量标准。

最终成果不仅是一个有效的解决方案，更是一个值得信赖的解决方案。正是这种信任让我们能够不断改进，即使是在将 div 元素居中显示是最简单的设计优化的情况下。

我们认真对待为数十亿用户进行设计的艰巨责任。在如此庞大的规模下，利用可衡量的数据来了解设计方案的实际影响至关重要。在准备推出这些变更的过程中，我们重点关注五个关键指标，以判断我们是否真正成功地让互联网上最常见的用户界面更加人性化。

我们的主要目标是质询完成率：它是指已发出的质询成功完成的百分比。通过弃用“中间缓存”之类的技术术语，转而使用“设备时间不正确”等简单易懂、可操作的标签，我们预计质询完成率将显著提升。更高的质询完成率并不意味着我们对机器人的验证更宽松；而是意味着我们将消除那些无意中导致合法真人用户出错的障碍。

用户在质询页面上花费的每一秒，都让他们无法获得真正所需的信息。我们的研究表明，用户看到一大堆红色文字时，往往会因为选择太多而不知所措。凭借全新的简洁易读、中性色设计，我们将跟踪完成时间，以确保用户能够在几秒钟内识别并解决问题，而不是花费几分钟。

过去，我们使用大量“饱和红色”引起了用户的强烈抵触情绪：他们认为自己操作失败，于是直接放弃。如今，我们仅保留图标使用红色并采用统一的信息架构，旨在降低放弃率。我们希望用户能够主动单击“故障排除”，而不是感到无能为力而放弃。

从产品角度来看，一项重大改进是我们推出了新的故障排除模态框。通过直接在小部件内提供清晰、编号的步骤，我们将自助服务支持功能集成到用户界面中。我们预计，这将显著降低客户和内部团队的支持工单数量。

我们知道，极少人喜欢接受安全质询，但不应因质询内容令人困惑而遭致厌恶。我们将监测社区论坛、反馈报告和社交频道的社交情绪，以了解用户对话是否会从“这个小部件坏了”转变为“我遇到了问题，但我已经解决了”。

作为产品经理，我的目标通常是实现无形的安全，最好的质询是用户看不见的质询。但如果必须显示质询，它应该是助手，而不是保安。重新设计证明了 AAA 级无障碍访问与高安全性标准并不冲突，二者是同一事物的两面。通过统一 Turnstile 与质询页面的架构，我们建立了一个基础，使我们能够以前所未有的速度迭代，并以更人性化的方式保护互联网。

此次重新设计是一个基础，而非终点。

我们将继续监测用户如何与新体验进行交互，并致力于根据了解到的情况进行迭代。我们在新设计中内置的反馈机制旨在真正帮助用户进行故障排除，而不仅仅是让他们报告问题，这将为我们提供前所未有的、更丰富的见解。

我们也会密切关注安全态势的演变。随着机器人攻击变得越来越复杂、AI 不断模糊真人行为与自动化行为之间的界限，验证的难度只会越来越大。我们的任务是始终提前防范，在不影响用户体验的前提下，不断提高安全性。

如果您在使用新版 Turnstile 或质询页面时有任何反馈，请随时告知我们。您可以通过 Cloudflare 社区论坛或使用产品内置的反馈机制联系我们。

Cloudflare Radar 已经提供了各种安全见解，从应用层和网络层攻击到恶意电子邮件消息，再到数字证书和互联网路由。

今天我们将推出更多功能。我们将发布 Radar 中几个新增的安全相关数据集和工具：

• 我们将后量子加密 (PQ) 监测范围从客户端扩展到面向源服务器的连接。我们还发布了一款新工具，可帮助您检查网站的后量子加密兼容性。

• Radar 中新增的“密钥透明度”部分将提供一个公共仪表板，显示端到端加密消息服务（例如 WhatsApp）的密钥透明度日志的实时验证状态，以及 Cloudflare 审计人员最后一次签名和验证每个日志的时间。该页面作为一个透明的界面，可供任何用户监测公钥分发的完整性，并访问 API 来独立验证 Cloudflare 审计人员的资质证明。

• 路由安全见解功能持续扩展，新增了关于 ASPA 部署的全球、国家/地区以及网络级别信息。ASPA 是一种新兴标准，可帮助检测和防范 BGP 路由泄漏。

自 2024 年 4 月以来，我们一直在 Cloudflare Radar 上跟踪客户端对后量子加密支持的总体增长情况，记录其全球增长增长情况：从 2024 年初的不足 3% 增长到 2026 年 2 月的超过 60%。2025 年 10 月，我们新增了一项功能，允许用户检查其浏览器是否支持 X25519MLKEM768，这是一种结合了经典 X25519 与 ML-KEM（由 NIST 标准化的、基于格的后量子算法）的混合密钥交换算法。这可以同时抵御经典攻击和量子攻击。

然而，用户到 Cloudflare 连接的后量子加密支持只是问题的一部分，还不是全貌。

对于非 Cloudflare CDN 缓存的内容或无法缓存的内容，Cloudflare 的边缘服务器会与客户的源服务器建立单独的连接来检索这些内容。为了加速向面向源服务器的此类请求过渡到抗量子加密的安全机制，我们之前推出了一个 API，支持客户选择优先使用后量子加密连接。如今，我们在 Radar 中显示源服务器的后量子加密兼容性。

Radar 中新增的源后量子加密支持图显示了支持 X25519MLKEM768 的客户源的比例。这些数据源自 Cloudflare 自动化 TLS 扫描程序，该扫描程序探测与 TLS 1.3 兼容的源服务器，并每天汇总结果。值得注意的是，我们的扫描程序旨在测试源服务器的支持情况，而不是测试其特定偏好。虽然源服务器可能支持后量子密钥交换算法，但其本地 TLS 密钥交换偏好最终将决定加密结果。

虽然主图重点关注后量子安全就绪度，但扫描程序还会评估是否支持经典密钥交换算法。在 Radar Data Explorer 视图中，您还可以查看这些受支持的 TLS 密钥交换算法的完整分布情况。

如上图所示，目前大约 10% 的源服务器可能受益于后量子优先的密钥协议。与 2025 年初的不到 1% 相比，这是一个显著的飞跃，一年多时间里增加了 10 倍。我们预计，随着行业继续迁移，这个数字将稳步增长。这种增长趋势在 2025 年可能会加速，因为许多服务器端 TLS 库（例如 OpenSSL 3.5.0+、GnuTLS 3.8.9+ 和 Go 1.24+）默认启用混合后量子密钥交换，这让平台和服务提供商只需升级其加密库依赖项即可支持后量子连接。

除了 Radar 和 Data Explorer 图表之外，也可以通过 Radar API 获取源服务器就绪数据。

为了进一步帮助互联网过渡到后量子加密，我们还推出了一款工具，用于测试特定主机名是否支持后量子加密。可以在任何可公开访问的网站上运行这些测试，只要网站允许来自 Cloudflare 出口 IP 地址范围的连接。

_{Radar 中用于测试主机名是否支持后量子加密的工具的屏幕截图。}

这款工具提供一个简单的表单，供用户在其中输入主机名（例如 cloudflare.com 或 www.wikipedia.org），然后选择性指定自定义端口（默认是 443，即标准的 HTTPS 端口）。单击“Test”后，结果会显示一个标签，指明后量子加密支持状态以及协商的 TLS 密钥交换算法。如果服务器优先使用后量子加密安全连接，则会出现一个绿色的“PQ”标记，并显示一则消息，确认这是“后量子加密安全”连接。否则，红色标记表示连接“非后量子加密安全”连接，并显示协商的经典算法。

在表面之下，这款工具其实使用了Cloudflare Containers，这是支持与 Workers 一起运行容器工作负载的一项新功能。因为 Workers 运行时无法访问底层 TLS 握手的详细信息，所以 Workers 无法启动 TLS 扫描。因此，我们创建了一个 Go 容器，利用 crypto/tls 包对后量子加密兼容性检查的支持。该容器按需运行并执行实际握手以确定协商的 TLS 密钥交换算法，并通过 Radar API 返回结果。

通过增加这些面向源服务器的见解，与现有面向客户端的见解相得益彰，我们已将所有后量子内容移至 Radar 中的专属部分。 

WhatsApp 和 Signal 等端到端加密 (E2EE) 消息应用程序已成为私密通信的重要工具，拥有数十亿全球用户。这些应用程序使用公钥加密技术确保只有发送方与接收方才能读取消息，甚至即使是消息服务本身也无法读取。不过，这种模式存在一个经常被忽视的漏洞：用户必须信任消息应用程序会为每个联系人分发正确的公钥。

如果攻击者能够在将错误的公钥替换到消息应用程序的数据库中，他们就可以拦截原本发送给其他人的消息消息，而发送方对此毫不知情。

密钥透明度通过创建可审计的、只能附加的公钥日志来化解这一挑战，其概念类似于 TLS 证书的证书透明度。消息应用程序将其用户的公钥发布到透明度日志中，独立的第三方可以验证并确认该日志的构建是否正确且始终如一。2024 年 9 月，Cloudflare 宣布成为 WhatsApp 的密钥透明度审计员，为其提供独立的验证层，以帮助确保这款即时通讯应用程序的数十亿用户公钥分发的完整性。

如今，我们将在 Cloudflare Radar 中的新增密钥透明度部分发布密钥透明度审计数据。本部分将展示 Cloudflare 审计的密钥透明度日志，让研究人员、安全专家和感兴趣的用户能够了解这些关键系统的运行状况和活动。

新页面启动时会显示两个受监测的日志：WhatsApp 和 Facebook Messenger Transport。每个受监测的日志均以卡片形式显示，包含以下信息：

• 状态：指明日志是在线、正在初始化或已禁用。“在线”状态表示日志正在主动发布密钥更新到 Cloudflare 审核的纪元中。（纪元表示在特定时间应用于密钥目录的一组更新。）

• 最新签名的纪元：由消息服务日志发布并经 Cloudflare 确认的最新纪元。单击眼睛图标，用户可以查看 JSON 格式的完整纪元数据，包括纪元编号、时间戳、加密摘要和签名。

• 最新验证的纪元：Cloudflare 已验证的最新纪元。验证流程包括检查透明度日志数据结构从上一个纪元到当前纪元的转换是否代表有效的消息树转换，从而确保日志已正确构建。验证时间戳则指明 Cloudflare 完成审计的时间。

• 根：可审计密钥目录 (AKD) 树的当前根哈希值。此哈希值已加密处理，代表当前纪元密钥目录的完整状态。与纪元字段类似，用户单击即可查看审计员返回的完整 JSON 响应。

页面上显示的数据也可以通过 Key Transparency Auditor API 获取，该 API 提供审计员信息和命名空间的端点。

如果您想自行执行审计证明验证，可以按照我们审计密钥透明度博客文章中的说明进行操作。我们希望这些只是 Radar 的“密钥透明度”部分中发布的众多用例的首批用例。如果贵公司或组织对审计自己的公钥或相关基础设施感兴趣，请单击此处联系我们。

虽然边界网关协议 (BGP) 是互联网路由的骨干支柱，但其设计并无任何内置机制来验证传播路径的效果。长期以来，这种固有的信任导致全球网络容易遭受路由泄漏和劫持攻击，流量意外或恶意地绕过未经授权的网络。

虽然 RPKI 和 路由源授权 (ROAs) 已成功强化了路由来的安全性，但它们无法验证流量在网络之间选择的路径。自治系统提供商授权 (ASPA) 的作用恰好体现在这方面。ASPA 允许自治系统 (AS) 对列出已获授权可以向上游传播其路由的网络记录进行加密签名，从而扩展了 RPKI 的保护范围。通过验证客户到提供商的关系，ASPA 使系统能够自信地检测无效的路径公告并做出相应的反应。

虽然具体的 IETF 标准仍处于草案状态，但运营社群正在快速推进。区域互联网注册管理机构 (RIR)（例如 ARIN 和 RIPE NCC）的门户网站已经支持创建 ASPA 对象，而 OpenBGPD 和 BIRD 等主流路由软件技术栈也提供了验证逻辑。

为了更好地了解这项新兴标准的采用情况，我们在 Cloudflare Radar 的路由部分添加了全面的 RPKI ASPA 支持。通过在全球范围内跟踪这些记录，我们可以了解整个行业在路径验证方面取得的进展有多快速。

我们全新的 ASPA 部署视图让用户可以查看 ASPA 的采用率随时间推移的增长情况，并且能够根据 AS 注册情况，可视化五个区域互联网注册管理机构 (RIR) 的趋势。您可以查看自 2023 年 10 月 1 日以来所有 ASPA 条目的完整历史记录，或放大到特定日期范围，将采用率激增与行业事件（例如 ARIN 和 RIPE NCC 在线仪表板中推出 ASPA 功能）关联起来。

除了聚合趋势之外，我们还推出了精细化、可搜索的实时 ASPA 内容浏览器。此表格视图让用户可以检查 ASPA 记录的当前状态，按 AS 编号、AS 名称搜索，或筛选仅显示提供商或客户 ASN。这让网络运营商能够验证其记录是否已正确发布，并查看其他网络的配置。

我们还将 ASPA 数据直接集成到国家/地区路由页面中。现在，用户可以根据与本地注册的客户 ASN 关联的 ASPA 记录，跟踪不同地点在保护其基础设施方面的进展。

在单独的 AS 页面中，我们更新了“连接”部分。现在，在查看网络连接时，用户可能会看到“ASPA 已验证的提供商”的视觉指指示符。此注释确认存在授权该特定上游连接的 ASPA 记录，从而立即表明路由的完整性和可信度。

对于已经部署 ASPA 的 AS，我们现在会显示已授权的提供商 ASN 的完整列表及其详细信息。除了当前状态之外，Radar 还提供涉及该 AS 的 ASPA 活动的详细时间线。历史记录会区分由 AS 自身（“作为客户”）发起的更改，以及其他人创建的将其指定为提供商的记录（“作为提供商”），让用户能够立即识别何时建立或修改了特定的路由授权。

可见性是更广泛采用新兴路由安全协议（例如 ASPA）至关重要的第一步。通过公开这些数据，我们旨在帮助运营商部署保护措施，并协助研究人员跟踪互联网在构建更安全路由路径方面已取得的进展。对于需要将这些数据集成到自己的工作流程或进行更深入分析的用户，我们也以编程方式公开了这些指标。现在，用户可以利用 Cloudflare Radar API 中新引入的端点，访问 ASPA 内容快照、历史时间序列和详细的变更数据。

互联网安全技术持续发展，新的方法、协议和标准也不断涌现，以确保信息、应用程序和网络安全。Cloudflare Radar 中提供的安全数据和见解也将继续发展。上述新增部分旨在扩展 Cloudflare Radar 中现有的路由安全、透明度和后量子时代见解。

如果您在社交媒体上分享这些新的图表，请务必标记我们：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)。如果您有任何问题、意见或对希望我们在 Radar 中添加的数据有任何建议，您可以通过社交媒体或电子邮件联系我们。

虽然网络社群在验证互联网流量的最终目的地方面已取得重大进展，但确保流量到达目的地的实际路径安全仍然是维护可靠的互联网的关键挑战。为了解决这个问题，业界将采用一种名为自治系统提供商授权 (ASPA) 的新加密标准，用于验证网络流量的整个路径并防止路由泄露。

为了帮助网络社群跟踪这项标准的采用情况，Cloudflare Radar 推出了一项新的 ASPA 部署监测功能。该视图让用户可以观察五个区域互联网注册管理机构 (RIR) 的 ASPA 采用随着时间推移而变化的趋势，并查看自治系统 (AS) 级别的 ASPA 记录及其随着时间推移的变化。

要了解 ASPA 的工作原理，首先要了解互联网目前如何保护流量目的地。

如今，网络使用一种名为资源公钥基础设施 (PKI) 的安全基础设施系统，该系统在过去几年内的部署取得了显著增长。在 RPKI 中，网络发布名为路由源授权 (ROA) 的特定加密记录。ROA 作为可验证的数字身份证，它负责确认自治系统 (AS) 已获得正式授权可以公告特定的 IP 地址。这解决了“源劫持”问题，即：一个网络试图假冒另一个网络。

自治系统提供商授权 (ASPA) 直接建立在此基础之上。ROA 验证目的地，而 ASPA 记录则验证旅程路径。

当数据在互联网上传输时，它会记录所经过的每个网络的运行日志。在 BGP 中，此日志被称为 AS_PATH（自治系统路径）。ASPA 为网络提供了一种方法，使其能够在 RPKI 系统内正式发布其已获授权的上游服务提供商列表。这样一来，任何接收网络均可查看 AS_PATH，检查相关 ASPA 记录，以及验证流量是否仅通过已核准的网络链传输。

ROA 有助于确保流量到达正确的目的地；ASPA 则确保流量通过预期的、已获授权的路径到达目的地。我们来看看实践中的路径评估工作原理。

ASPA 如何判断一条路由是否为绕行路线？它依据互联网的层次结构。

在一个正常运行的互联网路由拓扑中（例如“valley-free” routing），流量传输通常遵循特定的路径：它从客户“向上”传输到大型提供商（例如主流 ISP），可选地跨越另一个大型提供商，然后“下行”至目的地。您可以将其想象成一座“山”的形状：

1. 上行路径：流量从客户开始，并“向上”传输，经过越来越大型的互联网服务提供商 (ISP)，ISP 会付费给其他 ISP 来为其传输流量。

2. 顶端：它到达互联网骨干网线路的顶层，可能会跨越单个对等互连链路。

下行路径：流量通过各个服务提供商“向下”传输，最终到达目标客户。

^{“valley-free” routing 的可视化图。路由将流量向上传播到服务提供商，可选地跨越某个对等互连链路，然后向下传输到客户。}

在这个模型中，路由泄露就像一个山谷或低谷。当流量向下传输到客户，然后意外地尝试向上返回到另一个提供商时，即发生这种泄露。

这种“由下而上”的传输是不利的，因为客户既无意图也无能力在两个大型网络提供商之间传输流量。

ASPA 为网络运营商提供一种加密方式来宣告其已获授权的提供商，从而使接收网络能够验证 AS 路径是否遵循预期的结构。

ASPA 通过检查路由传播两端的“关系链”来验证 AS 路径：

• 检查上行路径：检查从源服务器开始并向前推进。每一次跳跃，它都会质询：“此网络是否已获授权成为下一个提供商？”，直到关系链终止为止。

• 检查下行路径：从 BGP 更新的目的地开始向后推进，执行相同的操作。

如果“上行”路径和“下行”路径在顶端重叠或交汇，则该路由有效。山形结构保持完整。

但是，如果两条有效路径没有交汇，即：中间存在授权缺失或无效的缺口，ASPA 会将此类路径报告为问题路径。这个缺口代表“山谷”或路由泄露。

我们看一下这个场景：网络 (AS65539) 收到了来自客户 (AS65538) 的错误路由。

客户 (AS65538) 尝试将其收到某个提供商 (AS65537) 发送的流量“向上”传输到另一个提供商 (AS65538)，后者充当提供商之间的桥梁。这是一个典型的路由泄露事件。现在我们来了解一下 ASPA 验证流程。

1. 检查上行路径：原始来源 (AS65536) 向提供商授权。（检查通过）。

2. 检查下行路径：从目的地开始，回头倒查。我们看到了客户 (AS65538)。

3. 不匹配：上行路径终止于 AS65537，而下行路径终止于 AS65538。两个路径无法连通。

由于“上行”路径与“下行”路径无法连通，系统将其标记为 ASPA 无效。需要 ASPA 来执行这个路径验证，因为如果 RPKI 中没有已签名的 ASPA 对象，则无法找到哪些网络已获授权可以向另外哪些网络公告哪些前缀。通过为每个 AS 提供商网络列表进行签名，我们可以知道哪些网络应该能够横向传播或向上游传播前缀。

ASPA 可以有效防范伪造源劫持，它是指攻击者通过伪装并公告指向真实源前缀的 BGP 路径来绕过路由源验证 (ROV)。虽然源 AS 仍然正确，但劫持者与受害者之间的关系是伪造的。

ASPA 让受害者网络可以通过加密方式来宣告其实际已获授权的提供商，以此来揭露这种欺骗行为；由于劫持者不在该授权列表中，因此，该路径会被视为无效路径而遭到拒绝，从而有效阻止恶意重定向。

但是，ASPA 无法完全防范伪造源劫持。至少在一种情况下，即使实施 ASPA 验证流程，也无法完全防范此类网络攻击。ASPA 无法处理的伪造源劫持示例是提供商伪造了指向其客户的路径公告。

本质上，服务提供商也可能“伪造”与其他自治系统 (AS) 的对等互连链路，以吸引使用较短 AS_PATH 路径的客户流量，即使是在不存在此类对等互连链路的情况下。ASPA 无法阻止提供商伪造这种路径，因为 ASPA 仅根据提供商信息运行，并且对关于对等互连关系的信息一无所知。

因此，虽然 ASPA 可以有效阻止伪造源劫持路由，但在极少数情况下，它仍然会失效，这些情况值得注意。

如今，在 RIPE 和 ARIN 等注册管理机构中创建网络（或自治系统）的 ASPA 对象是一个简单的流程。您只需要提供您的 AS 编号，以及您向其购买互联网传输服务的服务提供商的 AS 编号。这些是您信任的已获授权的上游网络，它们会将您的 IP 地址公告给更广泛的互联网。反过来，这些也是您授权其向您发送完整路由表的网络，该路由表相当于一张完整的互联网连接地图。

我们希望通过一个简短的示例，展示如何轻松创建 ASPA 对象。

假设我们需要为 AS203898 创建 ASPA 对象，这是 Cloudflare 伦敦办公室互联网使用的 AS。在撰写本文时，伦敦办公室使用了三个互联网服务提供商：AS8220、AS2860 和 AS1273。这意味着我们将为 AS203898 创建一个 ASPA 对象，且这三个服务提供商都在授权列表中。

首先，登录 RIPE RPKI 仪表板并导航到 ASPA 部分：

然后，针对想要创建 ASPA 对象的对象，单击“创建 ASPA”。接着，只需填写该 AS 的提供商即可。

就是这么简单。短暂等待后，即可查询全球 RPKI 生态系统，并找到为我们定义的提供商 AS203898 创建的 ASPA 对象。

ARIN 的操作步骤类似，它是目前唯一支持创建 ASPA 对象的另一个区域互联网注册管理机构 (RIR)。登录 ARIN 在线平台，然后导航到“路由安全”，单击“管理 RPKI”。

接着，单击“创建 ASPA”。在此示例中，我们将为另一个 ASN (AS400095) 创建对象。

大功告成，现在已经为提供商 AS0 的 AS40095 创建了 ASPA 对象。

“AS0”提供商条目在使用时具有特殊意义，它表示自治系统 (AS) 所有者证实其没有有效的上游提供商。根据定义，这意味着，如果每个无传输的 Tier-1 网络确实只有对等互连网络和客户关系，则其最终都应该对仅包含“AS0”的 ASPA 对象签名。

Cloudflare Radar 中添加了新增的 ASPA 部署监测功能。全新的 ASPA 部署视图让用户可以查看 ASPA 的采用率随时间推移的增长情况，并且能够根据 AS 注册情况，可视化五个区域互联网注册管理机构 (RIR) 的趋势。

我们还将 ASPA 数据直接集成到国家/地区以及 ASN 路由页面中。现在，用户可以根据与本地注册的客户 ASN 关联的 ASPA 记录，跟踪不同地点在保护其基础设施方面的进展。

如果放大查看特定的自治系统 (AS)，例如 AS203898，也会发现一些新功能。

可以查看网络上观察到的 BGP 上游提供商是否已获得 ASPA 授权，其 ASPA 对象中包含的完整提供商列表，以及涉及该 AS 的 ASPA 变更时间线。

随着 ASPA 最终成为现实，我们迎来了互联网路径验证的加密技术升级。然而，那些自 RPKI 路由源验证诞生之初就一直予以关注的人都知道，要真正为互联网安全带来显著价值，还有很长的路要走。需要更改 RPKI 中继方 (RP) 包、签名者实施、RPKI 到路由器协议 (RTR) 软件以及 BGP 实施，才能真正使用 ASPA 对象并利用它们验证路径。

除了采用 ASPA 之外，运营商还应按照 RFC9234 中的说明配置 BGP 角色。在 BGP 会话中配置的 BGP 角色将有助于未来路由器上的 ASPA 实施 决定采用哪种算法：upstream 或 downstream。换句话说，BGP 角色赋予我们运营商的以下权力：将预期的 BGP 关系与其他 AS 直接关联到与这些相邻路由的会话。请咨询您的路由供应商，确保他们支持 RFC9234 BGP 角色和 OTC（仅限客户）属性实施。

为了充分利用 ASPA，我们鼓励所有用户为其自治系统 (AS) 创建 ASPA 对象。创建并维护这些 ASPA 对象需要格外小心谨慎。未来，随着网络使用这些记录主动阻止无效路径，忽略合法提供商可能会导致流量下降。然而，管理这种风险与网络目前处理路由源授权 (ROA) 的方式并无二致。ASPA 是互联网路径验证必需的加密升级，我们很高兴推出这项标准！

但这只是问题的一部分。若要真正保护企业网络的未来安全，需要完整的安全访问服务边缘 (SASE)。

今天，我们完善了问题的另一面：Cloudflare One 是首个在安全 Web 网关以及 Zero Trust 和广域网 (WAN) 用例中支持符合现代后量子 (PQ) 加密标准的 SASE 平台。更具体地说，Cloudflare One 现在在所有主要入口和出口提供后量子混合型基于模块晶格的密钥封装机制 (ML-KEM)。

为了完善解决方案，我们增加了对 Cloudflare IPsec（云原生 WAN 即服务）和 Cloudflare One Appliance（用于建立 Cloudflare IPsec 连接的物理或虚拟 WAN 设备）对后量子加密的支持。Cloudflare IPsec 利用 IPsec 协议在客户网络与 Cloudflare 全球网络之间建立加密隧道，并使用 IP Anycast 自动将该隧道路由到最近的 Cloudflare 数据中心。Cloudflare IPsec 简化配置并提供高可用性；如果某个数据中心不可用，流量会自动重新路由到最近的正常运行的数据中心。Cloudflare IPsec 在我们的全球网络规模上运行，且支持跨 WAN 的站点间通信以及出站互联网连接。

随着版本 2026.2.0 的发布，Cloudflare One Appliance 升级版现已正式发布。Cloudflare IPsec 升级版则处于封闭测试阶段，您可以将自己的名字添加到我们的封闭测试列表，通过这种方式来申请访问权限。

量子威胁不是“下一个十年”要考虑的问题。以下是我们的客户当前优先考虑后量子加密技术 (PQC) 的原因：

最后期限日益临近。2024 年底，美国国家标准与技术研究院 (NIST) 发出了明确信号（其他机构也纷纷响应）：使用经典公钥密码技术的时代即将结束。根据 NIST 的规划，2030 年是淘汰 RSA 和椭圆曲线加密 (ECC) 并过渡到强大的量子计算机无法破解的 PQC 的最后期限。随着最后期限的临近，尚未开始迁移的企业将面临不合规和易受攻击的风险。

升级历来都是一个棘手的问题。2030 年似乎看似遥远，但升级加密算法的难度众所周知。历史经验表明，密码技术的弃用淘汰可能需要数十年时间：例如，我们发现 MD5 在被弃用 20 年之后仍然会造成问题。主要的瓶颈在于缺乏加密敏捷性（即：轻松切换加密算法的能力）。将后量子加密直接集成到我们的 SASE 平台，也就是 Cloudflare One 中，不仅会提供内置的加密敏捷性，而且可简化企业提供远程访问和站点间连接的方式。

数据可能已经面临风险。最后，“先收集、后解密”是一种持续存在的现实威胁，它是指攻击者当下收集敏感的网络流量，然后将其存储，直到量子计算机具备足够的能力进行解密。如果您的数据保存期限超过几年（例如财务信息、健康数据、国家机密），除非使用后量子加密进行保护，否则此类数据已经面临风险。

将网络流量过渡到后量子加密 (PQC) 需要对两种加密源语进行彻底修改：也就是密钥协商与数字签名。

迁移 1：密钥建立。密钥协商让双方通过不安全的通道建立共享密钥；然后使用该共享密钥来加密网络流量，从而实现后量子加密。业界已基本趋向于采用基于模块晶格的密钥封装机制 (ML-KEM) 作为标准的后量子密钥协商协议。

ML-KEM 已广泛应用于 TLS，它通常与经典的 Elliptic Curve Diffie Hellman (ECDHE) 搭配使用，其中用于加密网络流量的密钥是通过混合 ML-KEM 与 ECDHE 密钥协商的输出结果而生成。（这也被称为“混合型 ML-KEM”。）目前，流向 Cloudflare 网络的超过 60% 真人用户生成的 TLS 流量均受到混合型 ML-KEM 的保护。向混合型 ML-KEM 的过渡之所以成功，是因为它：

• 阻止“先收集、后解密”攻击

• 无需专用硬件或客户端与服务器之间的专用物理连接，这与量子密钥分发 (QKD) 等方法不同

• 对性能影响极小，即使是短暂的 TLS 连接

由于 ML-KEM 与经典的 ECDHE 并行运行，因此，与经典的 ECDHE 方法相比，其安全性和合规性没有降低。

迁移 2：数字签名。同时，数字签名和证书可以保护真实性，阻止活跃的对手假冒服务器来诱骗客户端。遗憾的是，与传统的 ECC 算法相比，目前的后量子签名体积更大，这减缓了其普及速度。幸运的是，迁移到后量子签名并不那么紧迫，因为后量子签名旨在阻止拥有强大量子计算机的对手，而这种计算机目前尚未问世。因此，虽然 Cloudflare 积极致力于后量子数字签名的标准化和推广，但当前的 Cloudflare IPsec 升级重点在于将密钥建立机制升级为混合型 ML-KEM。

美国网络安全和基础设施安全局 (CISA) 在其 2026 年 1 月发布的出版物《使用后量子加密标准的技术产品类别》中，认可了这两种迁移的性质。

为了实现完全受后量子加密保护的 SASE，我们升级了 Cloudflare IPsec 产品，以支持 IPsec 协议中的混合型 ML-KEM。

IPsec 社区实现后量子加密的历程与 TLS 截然不同。TLS 是加密第 4 层公共互联网流量（例如，从浏览器到内容分发网络 (CDN)）的事实标准，因此，安全性和供应商互操作性是其设计的重中之重。同时，IPsec 是一种第 3 层协议，通常用于连接由同一供应商生产的设备（例如，两个路由器），因此，互操作性历来都不是其关注的重点。考虑到这一点，让我们来看看 IPsec 迈向量子未来的历程。

2020 年 5 月发布的 RFC 8784 旨在成为 IPsec 互联网密钥交换协议第 2 版 (IKEv2) 的后量子更新版本，IKEv2 用于建立对称密钥以加密 IPsec 网络流量。RFC 8784 暗示可以使用长期的预共享密钥 (PSK) 或量子密钥分发 (QKD)。但这两种方法都不太令人满意。

RFC 8784 建议混合使用 PSK 与源自 Diffie Hellman Exchange (DHE) 的密钥，本质上来说是将 PSK 与 DHE 相结合。这种方法可以抵御“先收集、后解密”型攻击者，但无法提供前向保密以防范量子对手。

前向保密是密钥协商协议的一个标准必要条件。它可确保即使是在泄露了长期密钥的情况下，系统也是安全的。RFC 8784 中的 PSK 方法容易受到“先收集、后解密”型攻击者，这种攻击也获得一个长期 PSK 的副本，然后在未来强大的量子计算机面世后，通过破坏 DHE 密钥协商来解密流量。

为了解决前向保密问题，反而可以使用 RFC 8784 来混合经典的 DHE 密钥与根据量子密钥分发 (QKD) 协议新生成的密钥。

QKD 利用量子力学，在双方之间建立共享的私密加密密钥。重要的是，为了让 QKD 正常发挥作用，双方必须拥有专用的硬件或通过专用的物理连接设备进行连接。这个重大限制导致 QKD 无法用于常见的互联网用例，例如，通过 Wi-Fi 将笔记本电脑连接到远程服务器。正是由于种种限制，我们从未投资为 Cloudflare IPsec 部署 QKD。美国国家安全局 (NSA)、德国联邦信息安全局 (BSI) 和英国国家网络安全中心也警告，不要完全依赖 QKD。

2023 年 5 月发布的 RFC 9370 规定使用混合型密钥协商，而不是 PSK 或 QKD。但是，不同于 TLS（它只支持搭配使用后量子 ML-KEM 与经典的 DHE，此项 IPsec 标准支持最多使用七种不同的密钥协商，同时与经典的 Diffie Helman 并行运行。此外，它没有具体说明这些密钥协商的细节，而是让供应商自行选择其算法和实施方案。例如，Palo Alto Networks 高度重视这个问题，在其下一代防火墙 (NGFW) 中内置了对超过七种不同后量子密码套件的支持，其中大多数无法与其他供应商进行互操作，有些甚至尚未实现 NIST 标准化。

多年来，TLS 的发展趋势恰恰相反，注册的密码套件数量从 TLS 1.2 的数百个减少到 TLS 1.3 的大约五个。这种减少“密码套件臃肿”的理念也符合 NIST 2019 年发布的 SP 800 52。减少“密码套件臃肿”的理由包括：

• 提高不同供应商和跨区域的互操作性

• 降低利用降级到弱密码套件发起攻击的风险

• 降低因配置错误而导致安全问题的风险

• 通过减少代码库大小，降低实施缺陷的风险

这就是我们最初没有构建 RFC 9370 支持的原因。

这也是我们对 IPsec 社区提出 draft-ietf-ipsecme-ikev2-mlkem 感到兴奋的原因。这份互联网草案实现了 IPsec 后量子密钥交换的标准化，与 TLS 广泛部署的后量子密钥交换相同：混合型 ML-KEM。新草案填补了 RFC 9370 的空白，指定如何在 IKEv2 中将 ML-KEM 作为附加密钥交换与经典的 Diffie Hellman 并行运行。

鉴于此规范现已发布，我们已着手在 Cloudflare IPsec 产品中支持后量子 IPsec。

Cloudflare IPsec 是一种 WAN 网络即服务解决方案，通过将数据中心、分支机构和云 VPC 连接到 Cloudflare 的全球 IP Anycast 网络，它取代了传统的专用网络架构。

使用 Cloudflare IPsec，Cloudflare 网络充当 IKEv2 响应方，等待来自 IPsec 发起方（即：客户网络中的分支连接器设备）的连接请求。Cloudflare IPsec 支持由分支连接器发起的 IPsec 会话，这些分支连接器包括 Cloudflare 推出的 Cloudflare One Appliance，以及 Cisco、Juniper、Palo Alto Networks、Fortinet、Aruba 等其他不同供应商的连接器。

我们已经在 Cloudflare IPsec IKEv2 响应方中实施了生产环境混合型 ML-KEM 支持，如 draft-ietf-ipsecme-ikev2-mlkem 中的指定。该草案要求首先使用经典的 Diffie Helman 密钥交换来进行第一次密钥交换。派生的密钥用于加密使用 ML-KEM 密钥交换进行的第二次密钥交换。最后，将两次交换生成的密钥混合在一起，并将结果用于保护 IPsec ESP（封装安全有效负载）模式下的数据平面流量。ESP 模式使用对称加密技术，因此，无需任何额外升级即可保证量子安全。我们已使用 strongswan 参考实施中的 IPsec 发起方测试了我们的实施。

您可以通过查看 Cloudflare IPsec 日志，了解 IKEv2 协商中使用的密码套件。

我们选择实施混合型 ML-KEM，而不是纯 ML-KEM（即：仅使用 ML-KEM 而不并行运行 DHE），原因有两个。其一，我们在所有其他 Cloudflare 产品中都采用了混合型 ML-KEM，因为这是 TLS 社区普遍采用的密钥交换方法。其二，它提供了一种“双保险”的安全保障：ML-KEM 可以抵御“先收集、后解密”型量子攻击，而 DHE 则提供久经考验的算法来防范非量子对手。

只有支持互操作性，才能充分利用实施的价值。为此，我们邀请其他根据 draft-ietf-ipsecme-ikev2-mlkem 正在其分支连接器中构建 IPsec 发起方支持的供应商，针对我们的 Cloudflare IPsec 实施进行测试。希望在我们进行封闭测试期间参加与第三方分支连接器互操作性测试的 Cloudflare 客户可以在此处注册。我们计划正式发布并构建与其他供应商的互操作性，随着更多供应商开始支持 draft-ietf-ipsecme-ikev2-mlkem，互操作性将逐步提高。

我们的许多客户从 Cloudflare 购买分支连接器（硬件或虚拟化），而不是从第三方供应商购买。因此，我们用于将本地网络连接到 Cloudflare One 的即插即用型设备 Cloudflare One Appliance 也升级了功能，可以支持后量子加密。

Cloudflare One Appliance 不使用 IKEv2 进行密钥协商或会话建立，而是选择依赖 TLS。设备会定期发起与 Cloudflare 边缘节点的 TLS 握手，通过生成的 TLS 连接来共享对称密钥，然后将该对称密钥注入 IPsec 的 ESP 层，ESP 层随后对 IPsec 数据平面流量进行加密和身份验证。这种设计使我们能够避免构建 IKEv2 发起方逻辑，以及利用现有的 TLS 库简化连接器的维护。

因此，将 Cloudflare One Appliance 升级到支持后量子加密，就像将 TLS 1.2 升级到采用混合型 ML-KEM 的 TLS 1.3 一样，Cloudflare 的不同产品已经多次完成过类似的升级。

与以往一样，我们的客户可以免费升级到 Cloudflare IPsec。我们认为，安全且私密的互联网应该惠及所有人，因此，我们致力于将后量子加密集成到所有 Cloudflare 产品，无需任何专用硬件，也无需客户和最终用户支付任何额外费用。

使用 Cloudflare One Appliance 的客户通过 2026 年 2 月 11 日发布的版本 2026.2.0 获得了后量子加密升级。升级是根据每台设备配置的中断窗口自动推送（无需客户操作）。

对于使用 Cloudflare IPsec 并搭配其他供应商生产的分支连接器设备的客户，随着更多供应商开始支持 draft-ietf-ipsecme-ikev2-mlkem，我们将实现与这些连接器的互操作。您也可以直接联系我们，获取参加封闭测试的权限，并要求我们与特定供应商的分支连接器实现互操作。

后量子 SASE 的价值主张非常明确：企业通过混合型 ML-KEM 保护的隧道发送专用网络流量，从而获得即时的端到端保护。这可以保护流量免受“先收集、后解密”型攻击，即使企业网络中的单个应用尚未升级到支持 PQC 也是如此。

上图显示了如何在各种 Cloudflare One 网络配置中提供后量子混合型 ML-KEM。它包括以下入口：

• 无客户端（使用 TLS 1.3 搭配混合型 ML-KEM，假设浏览器支持混合型 ML-KEM））

• Cloudflare One Client（使用 TLS 1.3 的 MASQUE，搭配混合型 ML-KEM，由设备客户端发起）

• Cloudflare IPsec 入口（如本文中所述）

以及以下出口：

• Cloudflare Tunnel 出口（使用 TLS 1.3 搭配混合型 ML-KEM 隧道，由 Cloudflare 服务器代理发起）

• Cloudflare IPsec 出口（如本文中所述）

下图着重展示了一个示例网络配置，它使用 Cloudflare One Client 入口将设备连接到 Cloudflare One Appliance 出口后面的服务器。最终用户的设备使用 MASQUE 搭配混合型 ML-KEM 连接到 Cloudflare 网络（链路 1）。然后，流量通过 TLS 1.3 搭配混合型 ML-KEM 隧道，在 Cloudflare 全球网络中传输（链路 2）。然后，流量通过后量子加密 Cloudflare IPsec 链路（链路 3）离开 Cloudflare 网络，最终到达一台 Cloudflare One Appliance。最后，流量连接到客户环境中的一台服务器。如此一来，即使服务器本身不支持后量子加密技术，流量在公共互联网中传输时也会受到后量子加密的保护。

最后，我们发现，先进入 Cloudflare One 然后输出到公共互联网的流量，也可以通过我们支持后量子加密的 Cloudflare Gateway，也就是安全 Web 网关 (SWG) 进行保护。下图显示了 SWG 的工作原理：

正如之前的一篇博客文章所述，我们的 SWG 已经可以支持使用混合型 ML-KEM 来加密从 SWG 到源服务器的流量（前提是源服务器支持混合型 ML-KEM），以及从客户端到 SWG 的流量（前提是客户端支持混合型 ML-KEM，大多数现代浏览器均支持）。重要的是，任何通过已安装 Cloudflare One Client 的设备进入 SWG 的流量仍将受到混合型 ML-KEM 的保护，即使 Web 浏览器本身尚不支持后量子加密技术。这是因为 Cloudflare One Client 会建立一条后量子加密的 MASQUE 隧道连接到 Cloudflare 全球网络。通过后量子 Cloudflare IPsec 隧道进入 SWG 的流量也是如此。

综上所述，Cloudflare One 现在在我们的 TLS、MASQUE 和 IPsec 入口/出口提供后量子加密，适用于专用网络流量，也适用于通过我们的 SWG 出口到公共互联网的流量。

通过将 Cloudflare IPsec 和 Cloudflare One 设备整合到后量子 SASE 协议中，我们已将后量子加密扩展到所有主要入口和出口。我们有意选择了互操作性和简单性的途径，即 IETF 以及 NIST 倡导的混合型 ML-KEM 方法，而不是让客户受困于专有实施、“密码套件臃肿”或不必要的硬件升级。

这就是 Cloudflare One 的承诺：提供的 SASE 平台不仅比它所取代的传统架构更快速、更可靠，而且还提供后量子加密功能。无论是保护远程办公人员的浏览器或是千兆数据中心链路，现在您都可以放心这些数据会受到保护，可以抵御“先收集、后解密”型攻击以及其他未来威胁。

在此处注册，获取关于 Cloudflare One SASE 平台后量子功能的完整演示；或者在此处注册，加入 Cloudflare IPsec 封闭测试列表。我们很荣幸能够引领行业迈入密码技术的新时代，并诚邀您与我们携手构建可扩展、符合安全标准的后量子互联网。

此问题并不是任何类型的网络攻击或恶意活动直接或间接引起。之所以造成此问题，原因是 Cloudflare 更改了通过 BYOIP 管道来管理启用 IP 地址的方式。这一更改导致 Cloudflare 意外地撤回了客户前缀。

对于一些 BYOIP 客户来说，这导致他们无法从互联网访问服务和应用，从而导致其使用 BYOIP 的 Cloudflare 部署连接超时和失败。Cloudflare 的递归 DNS 解析器 (1.1.1.1) 网站出现了 403 错误。该事件总持续时间为 6 小时 7 分钟，其中大部分时间用于将前缀配置恢复到更改前的状态。

我们开始观察到故障后，Cloudflare 工程师恢复了更改，并且停止撤回前缀。然而，在工程师能够恢复更改之前，约 1,100 个 BYOIP 前缀已从 Cloudflare 网络中撤回。部分客户能够通过使用 Cloudflare 仪表板，重新播发其 IP 地址来恢复其自己的服务。在恢复所有前缀配置后，我们解决了该事件。

我们对客户造成的影响深表歉意。今天的服务中断让大家失望了。本文将详细回顾事件的来龙去脉，以及哪些系统和流程出现了故障。我们还将概述正在采取的措施，以防止此类中断再次发生。

下图显示了在事件发生期间 Cloudflare 向 BGP 邻居播发的前缀数量（这与影响程度相关），因为未播发的前缀在互联网上无法连接。

在播发给对等互连的 6,500 个前缀中，其中 4,306 个是 BYOIP 前缀。这些 BYOIP 前缀被播发到每个对等互连，代表我们在全球播发的所有 BYOIP 前缀。 

此次事件发生期间（世界标准时间 17:56 至 18:46），共计 6,500 个前缀中，有 1,100 个前缀被撤回。共计 4,306 个 BYOIP 前缀中，25% 的 BYOIP 前缀被无意中撤回。我们能够检测对 one.one.one.one 的影响，并在更多前缀受到影响之前恢复产生影响的更改。在 19:19（世界标准时间），我们向客户发布了指南，他们可通过前往 Cloudflare 仪表板并重新播发其前缀来自行修复此事件。

在 20:20（世界标准时间）左右，Cloudflare 成功恢复了许多播发更改，使 800 个前缀得到恢复。还有约 300 个前缀无法通过仪表板进行修复，因为这些前缀的服务配置因软件错误而从边缘删除。Cloudflare 工程师于 23:03（世界标准时间）手动恢复了这些前缀。 

此次事件没有影响所有 BYOIP 客户，因为配置更改为迭代应用，而非在所有 BYOIP 客户即时应用。一旦发现配置更改会造成影响，在所有客户受到影响之前，该更改就被撤销了。 

受影响的 BYOIP 客户首先经历了一种称为 BGP 路径搜索的行为。在这种状态下，最终用户连接会遍历网络，尝试找到到目标 IP 的路由。这种情况会持续存在，直到打开的连接超时并失败。在将该前缀播发到某处之前，客户会继续看到这种故障模式。出现这种循环直到故障的情况，会影响任何使用 BYOIP 向互联网播发的产品。另外，访客在访问 one.one.one.one（Cloudflare 递归 DNS 解析器网站）时，会遇到 HTTP 403 错误和“边缘 IP 受限”错误消息。基于 1.1.1.1 的 DNS 解析。公共解析器不受影响，包括基于 HTTPS 的 DNS。受影响服务完整明细如下。

还有一些客户通过在 Cloudflare 仪表板上切换前缀无法恢复服务。随着工程师开始重新公告前缀，以便为这些客户恢复服务，尽管这些客户的 IP 地址被播发，但延迟和故障可能有所增加。其原因是，由于我们自己的软件问题，一些用户的寻址设置被从边缘服务器上删除，且状态必须传播回边缘。 

我们下面将讲述寻址系统中的具体故障，但首先需要快速了解寻址 API，这是 Cloudflare 客户 IP 地址的底层真实来源。

寻址 API 是 Cloudflare 网络上存在的地址的权威数据集。对该数据集做出任何更改，都会立即反映在 Cloudflare 的全球网络中。虽然作为橙色警报：小规模故障计划的一部分，我们正在改进这些系统发布更改的方式，但今天客户可以通过与面向公众的 API 交互来配置其 IP 地址，这可配置一组数据库，触发操作工作流，将更改传播到 Cloudflare 的边缘网络。这意味着，对寻址 API 的更改会立即传播到 Cloudflare 边缘。

在 Cloudflare 上播发和配置 IP 地址涉及几个步骤：

• 客户通过寻址 API 或 BGP，控制向 Cloudflare 发送有关 IP 地址的播发/撤回的信号。

• 寻址 API 会指示机器更改前缀播发。

• 一旦足够多的机器收到了更新前缀的通知，就会在路由器上更新 BGP

• 最后，客户可通过服务绑定，将 Cloudflare 产品配置为使用 BYOIP 地址，这会将产品分配到这些范围

寻址 API 让我们能够自动化处理如何播发或撤回地址的大多数流程，但某些流程仍需手动操作。由于这些手动流程最接近生产环境，因此存在风险。作为橙色警报：小规模故障计划的一部分，补救的目标之一是删除在寻址 API 中执行的手动操作，而使用安全的工作流程取而代之。

出错的具体配置部分是一项修改，尝试自动执行客户从 Cloudflare 的 BYOIP 服务中删除前缀的操作，这是目前客户经常提出的手动请求。取消这个手动流程是我们“橙色警报：小规模故障”计划的一部分，旨在推动所有更改，以实现安全、自动化、以运行状况为中介的部署。由于 BYOIP 前缀的相关对象列表可能较大，这会作为定期运行的子任务的一部分来实施，该子任务检查应删除的 BYOIP 前缀，然后将其删除。遗憾的是，这个定期清理子任务查询 API 时发现了一个错误。

下面是清理子任务的 API 查询：

 resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)

以下是 API 实现的相关部分：

	if v := req.URL.Query().Get("pending_delete"); v != "" {
		// ignore other behavior and fetch pending objects from the ip_prefixes_deleted table
		prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
		if err != nil {
			api.RenderError(ctx, w, ErrInternalError)
			return
		}

		api.Render(ctx, w, http.StatusOK, renderIPPrefixAPIResponse(prefixes, nil))
		return
	}

由于客户端传递的 pending_delete 没有值，这里 Query().Get(“pending_delete”) 的结果将是一个空字符串 (“”)，于是 API 服务器会将其解释为对所有 BYOIP 前缀的请求，而不仅仅是那些本应删除的前缀。系统将其解释为所有返回的前缀都在排队等待删除。然后，新的子任务开始系统地删除所有 BYOIP 前缀及其所有相关依赖对象，包括服务绑定，直到发现影响、工程师识别出子任务并将其关闭。

我们的暂存环境包含与生产环境尽可能匹配的数据，但在这种情况下仍显不足，我们用来模拟将要发生情况的模拟数据也不够充分。

此外，虽然我们对此功能进行了测试，但我们在测试过程和环境中对这种场景的覆盖并不完整。初始测试和代码审查的重点是 BYOIP 自助服务 API，并且已成功完成。虽然我们的工程师成功地测试了客户会遵循的确切流程，但测试并未涵盖任务运行程序服务在不显式输入的情况下独立执行更改用户数据的情况。

并非所有受影响的 BYOIP 前缀都以相同的方式受到影响，需要更密集的数据恢复步骤。作为“橙色警报：小规模故障”计划的一部分，我们正在构建一个系统，可通过以运行状况为中介的部署安全地推出操作状态快照。如果出现某些问题并导致意外行为，可以非常迅速地回滚到已知良好的状态。不过，该系统目前尚未进入生产阶段。

在此次事件中，BYOIP 前缀处于不同的影响状态，而这些不同的状态需要采取不同的行动：

• 大多数受影响的客户只是撤回其前缀。在此配置中，客户可进入仪表板并切换其播放，这样即可恢复服务。

• 部分客户的前缀被撤销，并删除了部分绑定。这些客户处于部分恢复状态，他们可以切换某些前缀，但其他前缀不可用。

• 部分客户的前缀被撤销，且所有服务绑定被删除。他们无法在仪表板中切换其前缀，因为没有绑定任何服务（Magic Transit、Spectrum、CDN）。这些客户花了最长时间来缓解风险，因为必须启动全局配置更新，以便将所有这些客户的服务绑定重新应用到 Cloudflare 边缘上的每一台计算机。

发生此事件时，我们正在进行的更改是“橙色警报：小规模故障”计划的一部分，该计划旨在提高 Cloudflare 代码和配置的韧性。在橙色警报：小规模故障计划简介中，工作可分为三个部分：

• 对传播到网络的任何配置更改进行受控部署，就像我们目前对软件二进制版本发布所做的一样。

• 更改 Cloudflare 内部的“紧急访问”规程并消除任何循环依赖关系，以便我们和客户在发生事件期间都能快速行动，并顺利访问所有系统。

• 审核、改进并测试所有处理网络流量的系统的故障模式，确保这些系统在所有条件下（包括意外错误状态）均表现出明确定义的行为。

我们尝试部署的更改属于第一个存储桶。通过将有风险的手动更改转移到安全的自动化配置更新，这会以基于运行状况的方式进行部署，我们旨在提高服务的可靠性。

关键工作已经在进行中，通过分阶段的测试中介和更佳的正确性检查，来增强寻址 API 对配置更改的支持。这项工作与部署更改同时进行。尽管中断前尚未完全部署预防措施，但事件发生时，这些团队正在对这些系统进行积极的维护工作。我们的“橙色警报：小规模故障”计划承诺，要求以受控方式推出到生产环境，我们的工程团队一直深入到堆栈的所有层，以识别并修复所有有问题的结果。虽然这次中断本身并非全球性，但其影响范围和影响却大到不可接受，这进一步强化了“橙色警报：小规模故障”计划状态下的优先事项，直到我们重新树立起信心，确信所有网络变化将尽可能循序渐进。现在我们来更加具体地谈谈对这些系统的改进。

此事件中的问题之一是 pending_delete 标志被解释为字符串，使客户端和服务器都难以合理化该标志的值。我们将改进 API 模式以确保更好的标准化，这将使测试和系统更容易验证 API 调用是否正确构成。这项工作是第三个“橙色警报”工作流的一部分，该工作流旨在创建在所有条件下定义明确的行为。

如今，客户对寻址模式做出的更改会持久存储在一个权威数据库中，这个数据库就是用于操作的数据库。这样一来，手动回滚过程更具挑战性，因为工程师需要利用数据库快照，而不是在期望状态和实际状态之间进行合理化。我们将重新设计回滚机制和数据库配置，以确保我们可以轻松快速地回滚更改，并在客户配置和生产之间引入层。

我们将为从数据库读取的数据创建快照并应用到生产，并以部署所有其他生产更改的相同方式来应用这些快照，以及通过运行状况指标进行调解，以便在出现问题时自动停止部署。这意味着，下次遇到数据库进入错误状态的问题时，我们几乎可以即时将个别客户（或所有客户）恢复到一个正常运作的版本。

虽然这会暂时阻止客户在发生中断时通过我们的 API 进行直接更新，但这意味着我们能够在我们设法修复数据库的同时，继续为客户提供流量，而不必一段时间处于停机状态。这项工作与第一个和第二个“橙色警报”工作流一致，涉及快速回滚以及配置的安全、基于运行状况的部署。

我们将改进监控，以检测何时发生过快或过大的更改（例如快速撤回或删除 BGP 前缀），并在发生这种情况时禁用快照部署。这会形成一种断路器，以阻止任何操作数据库的失控过程具有很大的影响范围，就像我们在这个事件中看到的那样。

此外，我们还在进行一些工作，以直接监控客户运行的服务是否正常运行，这些信号也可以用于跳闸断路器，并阻止应用潜在的危险更改，直到我们有时间进行调查。这项工作与“橙色警报”的第一个工作流一致，涉及安全部署更改。

以下是事件的时间表，包括部署变更和补救措施。

对于发生今天这一事件，以及对我们提供给客户的服务，乃至整个互联网造成的影响深表歉意。我们的目标是提供一个能灵活应对变化的网络，但我们并未兑现对您的承诺。我们正在积极实施这些改进，以确保未来改进后的稳定性，并防止这个问题再次发生。

代码模式是我们最初提出的一种技术，旨在减少使用智能体工具过程中占用的上下文窗口。不必将每个操作描述为单独的工具，而是让模型针对类型化 SDK 编写代码，并在 Dynamic Worker Loader 中安全地执行代码。代码充当一个紧凑的计划。模型可以探索工具操作，组成多个调用，并仅返回其所需的数据。Anthropic 在其使用 MCP 执行代码的博客文章中独立探讨了相同的模式。

今天，我们推出使用代码模式的全新 MCP 服务器，适用于整个 Cloudflare API（从 DNS 和 Zero Trust 到 Workers 和 R2）。服务器只需使用 search() 和 execute() 两个工具，即可通过 MCP 提供对整个 Cloudflare API 的访问，同时仅消耗大约 1000 个令牌。无论存在多少个 API 端点，其占用空间始终保持不变。

对于像 Cloudflare API 这样的大型 API，代码模式可将输入令牌的使用量减少 99.9%。不使用代码模式的同等 MCP 服务器将消耗 117 万个令牌，这超过了最先进的基础模型的整个上下文窗口。

^{代码模式与原生 MCP 的资源节省对比，使用 tiktoken 衡量}

您可以立即开始使用这款全新的 Cloudflare MCP 服务器。此外，我们还将在 Cloudflare Agents SDK 中开源一个新的代码模式 SDK，支持用户在自有 MCP 服务器和 AI 智能体中使用相同的方法。

这款全新的 MCP 服务器在服务器端应用了代码模式。服务器仅导出 search() 和 execute() 这两个工具，而不是数千个工具。这两个工具均由代码模式提供支持。如下是加载到模型上下文中的完整工具界面区域：

[
  {
    "name": "search",
    "description": "Search the Cloudflare OpenAPI spec. All $refs are pre-resolved inline.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "code": {
          "type": "string",
          "description": "JavaScript async arrow function to search the OpenAPI spec"
        }
      },
      "required": ["code"]
    }
  },
  {
    "name": "execute",
    "description": "Execute JavaScript code against the Cloudflare API.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "code": {
          "type": "string",
          "description": "JavaScript async arrow function to execute"
        }
      },
      "required": ["code"]
    }
  }
]

为了了解代码模式的功能，智能体会调用 search()。它根据 OpenAPI 规范的类型化表示编写 JavaScript。智能体可以按产品、路径、标记或任何其他元数据筛选端点，并将数千个端点缩减到所需的少数几个。完整的 OpenAPI 规范永远不会进入模型上下文。智能体仅通过代码与之交互。

当智能体准备好执行操作时，它会调用 execute()。智能体编写的代码可以发出 Cloudflare API 请求、处理分页、检查响应，并将多项操作串联起来，一次性执行。

这两个工具在 Dynamic Worker 隔离环境内运行生成的代码。这是一个轻量级 V8 沙盒，没有文件系统，不会通过提示词注入泄露环境变量，并且默认情况下禁用外部获取。必要时，可以使用出站提取处理程序，明确控制出站请求。

假设用户对其智能体说：“保护我的源服务器免受 DDoS 攻击。”智能体执行的第一步操作是查阅文档。它可能会调用 Cloudflare Docs MCP 服务器，使用 Cloudflare 技能，或直接在网络上搜索。从文档中，它了解到：应在源服务器前端部署 Cloudflare WAF 和 DDoS 保护规则。

第 1 步：搜索正确的端点 search 工具向模型提供一个 spec 对象：包含所有预解析 $refs 的完整 Cloudflare OpenAPI 规范。模型根据该规范编写 JavaScript 代码。在这里，智能体会查找区域中的 WAF 和规则集端点：

async () => {
  const results = [];
  for (const [path, methods] of Object.entries(spec.paths)) {
    if (path.includes('/zones/') &&
        (path.includes('firewall/waf') || path.includes('rulesets'))) {
      for (const [method, op] of Object.entries(methods)) {
        results.push({ method: method.toUpperCase(), path, summary: op.summary });
      }
    }
  }
  return results;
}

服务器在 Workers 隔离环境中运行此代码并返回：

[
  { "method": "GET",    "path": "/zones/{zone_id}/firewall/waf/packages",              "summary": "List WAF packages" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}", "summary": "Update a WAF package" },
  { "method": "GET",    "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules", "summary": "List WAF rules" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/firewall/waf/packages/{package_id}/rules/{rule_id}", "summary": "Update a WAF rule" },
  { "method": "GET",    "path": "/zones/{zone_id}/rulesets",                           "summary": "List zone rulesets" },
  { "method": "POST",   "path": "/zones/{zone_id}/rulesets",                           "summary": "Create a zone ruleset" },
  { "method": "GET",    "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Get a zone entry point ruleset" },
  { "method": "PUT",    "path": "/zones/{zone_id}/rulesets/phases/{ruleset_phase}/entrypoint", "summary": "Update a zone entry point ruleset" },
  { "method": "POST",   "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules",        "summary": "Create a zone ruleset rule" },
  { "method": "PATCH",  "path": "/zones/{zone_id}/rulesets/{ruleset_id}/rules/{rule_id}", "summary": "Update a zone ruleset rule" }
]

完整的 Cloudflare API 规范包含超过 2,500 个端点。模型将范围缩减至其需要的 WAF 和规则集端点，而无需将任何规范信息输入上下文窗口。

模型还可以在调用特定端点之前深入查看其架构。在这里，它会检查区域规则集中可用的阶段：

async () => {
  const op = spec.paths['/zones/{zone_id}/rulesets']?.get;
  const items = op?.responses?.['200']?.content?.['application/json']?.schema;
  // Walk the schema to find the phase enum
  const props = items?.allOf?.[1]?.properties?.result?.items?.allOf?.[1]?.properties;
  return { phases: props?.phase?.enum };
}

{
  "phases": [
    "ddos_l4", "ddos_l7",
    "http_request_firewall_custom", "http_request_firewall_managed",
    "http_response_firewall_managed", "http_ratelimit",
    "http_request_redirect", "http_request_transform",
    "magic_transit", "magic_transit_managed"
  ]
}

智能体现在知道它需要的确切阶段：ddos_l7 用于 DDoS 防护，http_request_firewall_managed 用于 WAF。

第 2 步：执行 API 操作 智能体切换到使用 execute。沙盒获取一个 cloudflare.request() 客户端，该客户端可以对 Cloudflare API 进行经过身份验证的调用。首先，智能体检查区域中已经存在哪些规则集：

async () => {
  const response = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets`
  });
  return response.result.map(rs => ({
    name: rs.name, phase: rs.phase, kind: rs.kind
  }));
}

[
  { "name": "DDoS L7",          "phase": "ddos_l7",                        "kind": "managed" },
  { "name": "Cloudflare Managed","phase": "http_request_firewall_managed", "kind": "managed" },
  { "name": "Custom rules",     "phase": "http_request_firewall_custom",   "kind": "zone" }
]

智能体发现已存在托管的 DDoS 和 WAF 规则集。现在，它可以进行链式调用，在一次执行中检查这些规则并更新敏感度级别：

async () => {
  // Get the current DDoS L7 entrypoint ruleset
  const ddos = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/ddos_l7/entrypoint`
  });

  // Get the WAF managed ruleset
  const waf = await cloudflare.request({
    method: "GET",
    path: `/zones/${zoneId}/rulesets/phases/http_request_firewall_managed/entrypoint`
  });
}

从搜索规范、检查模式到列出规则集、获取 DDoS 和 WAF 配置，整个操作需要调用四次工具。

我们从单个产品的 MCP 服务器开始。想要管理 DNS 的智能体？添加 DNS MCP 服务器。需要记录 Workers 日志的智能体？添加 Workers Observability MCP 服务器。每个服务器会导出一组固定的工具，这些工具已映射到 API 操作。当工具集较小时，这种方式行之有效，但 Cloudflare API 拥有超过 2,500 个端点。任何手动维护的服务器集合都无法跟上速度。

Cloudflare MCP 服务器将简化这个流程。只需两个工具，大约 1,000 个令牌，即可覆盖 API 中的每个端点。添加新产品时，相同的 search() 和 execute() 代码路径会发现并调用它们，无需新的工具定义，也无需新的 MCP 服务器。它甚至支持 GraphQL Analytics API。

Cloudflare MCP 服务器根据最新的 MCP 规范构建。它符合 OAuth 2.1 标准，使用 Workers OAuth 提供商将令牌范围缩减至用户在连接时已获批准的选定权限。智能体只能获得用户明确授予的权限。

对于开发人员而言，这意味着您可以使用简单的智能体循环，并让智能体凭借内置的渐进式功能来发现和访问完整的 Cloudflare API。

目前已经出现了几种减少 MCP 工具消耗令牌数量的方法：

客户端代码模式是我们的第一个实验。模型为 TypeScript 编写有类型的 SDK，并在客户端的 Dynamic Worker Loader 中运行。这种方法的缺点是，它要求智能体提供安全的沙盒访问权限。代码模式在 Goose 和 Anthropic Claude SDK 中以程序化工具调用 (Programmatic Tool Calling) 的方式实施。

命令行界面是另一种方法。CLI 是自编文件程序，并且会在智能体探索过程中逐步揭示其功能。OpenClaw 和 Moltworker 等工具使用 MCPorter 将 MCP 服务器转换为命令行界面，从而逐步揭示智能体。这种方法的局限性显而易见：智能体需要一个外壳，但并非每种环境都会提供外壳，而且这会引入比沙盒隔离环境更广泛的攻击面。

动态工具搜索（例如 Anthropic 在 Claude Code 中所使用的工具），显示一组与当前任务相关的较小工具集。虽然它缩减了上下文使用，但目前需要一个必须维护和评估的搜索功能，并且每个匹配的工具仍然会使用令牌。

以上每种方法都解决了一个实际问题。但对于 MCP 服务器而言，服务器端代码模式结合了这些方法各自的优势：无论 API 大小，令牌成本是固定的；无需修改智能体端；内置渐进式发现功能；以及在沙盒隔离环境中安全执行。智能体只需利用代码来调用两个工具。其他操作均在服务器端完成。

Cloudflare MCP 服务器现已上线。将 MCP 客户端指向服务器 URL，您将被重定向到 Cloudflare 进行授权并选择要授予智能体的权限。将以下配置添加到您的 MCP 客户端：

{
  "mcpServers": {
    "cloudflare-api": {
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

对于 CI/CD、自动化，或者如果您更喜欢自行管理令牌，请创建一个具有所需权限的 Cloudflare API 令牌。用户令牌和帐户令牌均受支持，并且可以作为持有者令牌在 Authorization 标头中传递。

如需获取不同 MCP 设置配置的更多信息，请访问 Cloudflare MCP 存储库。

代码模式解决了单个 API 的上下文成本问题。但智能体极少只与一项服务通信。开发人员使用的智能体可能需要 Cloudflare API，以及 GitHub、数据库和内部文档服务器。每增加一个 MCP 服务器，都会带来与最初遇到的上下文窗口相同的压力。

Cloudflare MCP 服务器门户支持客户在单个网关后组合多个 MCP 服务器，并实现统一的身份验证和访问控制。我们将为客户的所有 MCP 服务器构建一流的代码模式集成，并将它们揭示给具有内置渐进式发现功能和相同固定令牌数量的智能体，无论有多少网关后端服务。

企业为了继续保持领先地位，现在不能只考虑真人访客或遵循传统的 SEO 优化方法，更要开始将智能体视为同等重要的用户。

将原始 HTML 提供给 AI，就像是按字数付费阅读包装，而不是里面的字母。在 Markdown 页面中添加一个简单的 ## About Us 大约消耗 3 个令牌；而它对应的 HTML 代码 <h2 class="section-title" id="about">About Us</h2> 会占用 12-15 个令牌，这还不包括填充每个真实网页但毫无语义价值的 <div> 包装器、导航栏和脚本标签。

您正在阅读的这篇博客文章在 HTML 中占用 16,180 个令牌，而转换为 Markdown 后仅使用 3,150 个令牌。这相当于令牌使用量减少了 80%。

Markdown 已迅速成为智能体和整个 AI 系统的通用语言。格式清晰的结构使其非常适合 AI 处理，最终带来更好的结果，同时最大限度地减少令牌浪费。

问题在于，Web 是由 HTML 而不是 Markdown 构成，而且页面大小多年来一直在稳步增长，导致页面难以解析。智能体的目标是过滤掉所有非必要元素，并扫描相关内容。

如今，将 HTML 转换为 Markdown 是任何 AI 管道的常见步骤。不过，这个流程不尽如人意：它会浪费计算资源，增加成本和处理复杂度，最重要的是，这可能并不是内容创作者最初预期的使用方式。

如果 AI 智能体绕过复杂的意图分析和文档转换，直接从源接收结构化 Markdown 文档，将会怎么样？

Cloudflare 网络现在支持在源实时转换内容，适用于已启用内容协商标头的区域。现在，当 AI 系统从任何使用 Cloudflare 且已启用 Markdown for Agents 功能的网站请求页面时，它们可以在请求中表达对 text/markdown 格式的偏好。在条件允许的情况下，我们的网络会自动、高效地将 HTML 实时转换为 Markdown。

其工作原理如下所述：要从已启用 Markdown for Agents 功能的区域获取任何页面的 Markdown 版本，客户端需要添加 Accept 协商标头，并将 text/markdown 作为其中一个选项。Cloudflare 将检测此标头，从源获取原始 HTML 版本并将其转换为 Markdown，然后再提供给客户端。

下面是一个带有 Accept 协商标头的 curl 示例，请求获取我们的开发人员文档中的页面：

curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ \
  -H "Accept: text/markdown"

或者，如果您要使用 Workers 构建 AI 智能体，则可以使用 TypeScript：

const r = await fetch(
  `https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/`,
  {
    headers: {
      Accept: "text/markdown, text/html",
    },
  },
);
const tokenCount = r.headers.get("x-markdown-tokens");
const markdown = await r.text();

我们已经看到一些目前最流行的编码智能体（例如 Claude Code 和 OpenCode）将此类 Accept 标头与内容请求一起发送。现在，将以 Markdown 格式返回此请求的响应。就是这么简单。

HTTP/2 200
date: Wed, 11 Feb 2026 11:44:48 GMT
content-type: text/markdown; charset=utf-8
content-length: 2899
vary: accept
x-markdown-tokens: 725
content-signal: ai-train=yes, search=yes, ai-input=yes

---
title: Markdown for Agents · Cloudflare Agents docs
---

## What is Markdown for Agents

The ability to parse and convert HTML to Markdown has become foundational for AI.
...

请注意，我们在转换后的响应中添加了一个 x-markdown-tokens 标头，用于指明 Markdown 文档中估计的令牌数量。例如，您可以在流程中使用此值，计算上下文窗口的大小或决定分块策略。

其工作原理如下图所示：

在上一次生日周期间，Cloudflare 宣布推出了内容信号，这个框架支持任何用户表达他们对他人访问其内容后如何使用这些内容的偏好。

返回 Markdown 时，需要确保内容能够被智能体或 AI 爬网程序使用。这就是 Markdown for Agents 转换后的响应添加 Content-Signal: ai-train=yes, search=yes, ai-input=yes 标头的原因，它表明内容可用于 AI 训练、搜索结果和 AI 输入，包括智能体的使用。未来，Markdown for Agents 将提供用于界定自定义内容信号政策的选项。

有关此框架的更多信息，请访问我们的内容信号专门页面。

我们在 Cloudflare 开发人员文档和博客中启用了这项功能，邀请所有 AI 爬网程序和智能体使用 Markdown 而不是 HTML 格式来访问我们的内容。

立即体验此项功能，使用 Accept: text/markdown 请求获取这篇博客。

curl https://blog.cloudflare.com/markdown-for-agents/ \
  -H "Accept: text/markdown"

结果为：

---
description: The way content is discovered online is shifting, from traditional search engines to AI agents that need structured data from a Web built for humans. It’s time to consider not just human visitors, but start to treat agents as first-class citizens. Markdown for Agents automatically converts any HTML page requested from our network to markdown.
title: Introducing Markdown for Agents
image: https://blog.cloudflare.com/images/markdown-for-agents.png
---

# Introducing Markdown for Agents

The way content and businesses are discovered online is changing rapidly. In the past, traffic originated from traditional search engines and SEO determined who got found first. Now the traffic is increasingly coming from AI crawlers and agents that demand structured data within the often-unstructured Web that was built for humans.

...

如果您要构建的 AI 系统需要从 Cloudflare 外部转换任意文档，或者内容源不支持 Markdown for Agents 功能，我们提供了其他方法，帮助您将文档转换为 Markdown 以供应用：

• Workers AI AI.toMarkdown() 支持多种文档类型（不仅限于 HTML）以及摘要功能。

• 如果您需要在真实浏览器中渲染动态页面或应用然后再进行转换，则浏览器渲染 /markdown REST API 支持 Markdown 转换。

为了应对 AI 系统浏览网页方式的转变，Cloudflare Radar 现在在全球 AI 见解页面以及单个机器人信息页面中都提供了 AI 机器人和爬网程序流量的内容类型见解。

新增的 content_type 维度和过滤器将显示返回给 AI 智能体和爬网程序的内容类型分布，按 MIME 类型类别进行分组。

您还可以查看按特定智能体或爬网程序筛选的 Markdown 请求。以下是向 OAI-Searchbot 返回 Markdown 的请求，OAI-Searchbot 是 OpenAI 用于支持 ChatGPT 搜索的爬网程序：

这些新数据将使我们能够跟踪 AI 机器人、爬网程序和智能体使用 Web 内容的方式随时间的变化趋势。与以往一样，可以通过公共 API 和 Data Explorer 免费访问 Radar 中的所有内容。

若要为您的区域启用 Markdown for Agents 功能，请登录 Cloudflare 仪表板，选择您的帐户，选择所在区域，找到“快速操作”，切换 Markdown for Agents 按钮即可启用。此项功能目前处于测试阶段，Pro、Business 和 Enterprise 计划以及 SSL for SaaS 客户均可免费使用。

您可以在 Cloudflare 开发人员文档中找到关于 Markdown for Agents 的更多信息。我们将继续完善和增强这项功能，并且欢迎您提供反馈。我们期待了解 AI 爬网程序和智能体如何处理和适应不断演变的非结构化 Web 数据。

2025 年第四季度，Aisuru-Kimwolf 僵尸网络发起了一场前所未有的轰炸攻击，被称为“圣诞节前夜”DDoS 攻击活动。攻击活动以 Cloudflare 客户以及 Cloudflare 仪表板和基础设施为目标，攻击者发起了超大容量 HTTP DDoS 攻击，攻击速率超过每秒 2 亿次请求 (rps)，距离创纪录的 31.4 TB/秒 (Tbps) 攻击仅过去几周。

1. 2025 年，DDoS 攻击数量激增 121%，平均每小时自动缓解的攻击数量达到 5,376 次。

2. 在 2025 年第四季度，香港的排名跃升了 12 位，成为全球遭受 DDoS 攻击第二多的地点。英国的排名也惊人地上升了 36 位，成为遭受 DDoS 攻击第六多的地点。

3. 受感染的 Android TV（属于 Aisuru-Kimwolf 僵尸网络的一部分）对 Cloudflare 网络发起了超大容量 HTTP DDoS 攻击，与此同时电信公司成为遭受 DDoS 攻击最多的行业。

2025 年，DDoS 攻击总数增长两倍以上，达到惊人的 4710 万次。近年来，此类攻击呈爆炸式增长：2023 年至 2025 年间，DDoS 攻击数量激增了 236%。

2025 年，Cloudflare 平均每小时缓解 5,376 次 DDoS 攻击，其中 3,925 次为网络层 DDoS 攻击，1,451 次为 HTTP DDoS 攻击。

增长最显著的是网络层 DDoS 攻击，同比增长超过三倍。2025 年，Cloudflare 缓解了 3440 万次网络层 DDoS 攻击；相比之下，2024 年缓解了 1140 万次网络层 DDoS 攻击。

其中相当一部分网络层攻击（大约 1350 万次）的目标是受 Cloudflare Magic Transit 保护的全球互联网基础设施以及 Cloudflare 自身的基础设施，这些攻击发生在 2025 年第一季度一次持续了 18 天的 DDoS 攻击活动中。在这些网络层攻击中，690 万次针对 Magic Transit 客户，其余 660 万次则直接针对 Cloudflare。

此次攻击是一次多手段 DDoS 攻击活动，包括 SYN 洪水攻击、Mirai 生成的 DDoS 攻击 和 SSDP 放大攻击等。Cloudflare 系统自动检测并缓解了这些类型的攻击。事实上，我们是在准备 2025 年第一季度 DDoS 威胁报告时才发现此次攻击活动，这恰好体现了 Cloudflare DDoS 缓解措施的有效性！

2025 年第四季度，DDoS 攻击数量比上一季度增长了 31%，比 2024 年则增长了 58%。网络层 DDoS 攻击是造成这一增长的主要原因。2025 年第四季度，网络层 DDoS 攻击占 DDoS 攻击总数的 78%。HTTP DDoS 攻击数量保持不变，但攻击规模却激增，达到了自 2023 年 HTTP/2 Rapid Reset DDoS 攻击活动以来的最高水平。最近的攻击激增是 Aisuru-Kimwolf 僵尸网络发起，我们将在下一节详细介绍。 

2025 年 12 月 19 日星期五，Aisuru-Kimwolf 僵尸网络开始对 Cloudflare 基础设施和 Cloudflare 客户发起超大容量 DDoS 攻击。这次攻击活动的新特点是攻击规模：该僵尸网络使用了超大容量 HTTP DDoS 攻击，攻击速率超过每秒 2000 万次请求 (Mrps)。

Aisuru-Kimwolf 僵尸网络是一个庞大的恶意软件感染设备集，主要是受感染的 Android TV。根据估计，该僵尸网络由 100 万至 400 万受感染的主机组成。它能够发起 DDoS 攻击，可能破坏关键基础设施，导致大多数传统的基于云的 DDoS 防护解决方案崩溃，甚至中断整个国家的网络连接。

在整个攻击过程中，Cloudflare 的自主 DDoS 防御系统检测并缓解了所有攻击，具体包括 384 次数据包密集型攻击、329 次比特密集型攻击和 189 次请求密集型攻击。总计 902 次超大容量 DDoS 攻击，平均每天 53 次攻击。

攻击活动期间，超大容量 DDoS 攻击的平均规模分别为 3 Bpps、4 Tbps 和 54 Mrps。攻击活动期间记录到的最高速率分别为 9 Bpps、24 Tbps 和 205 Mrps。

为了便于理解，打个比方来说，205 Mrps DDoS 攻击速率相当于英国、德国和西班牙三国人口同时输入网址并在同一秒内按下回车键的总和。

虽然“圣诞节前夜”攻击活动规模巨大，但它仅占 Cloudflare 全年观察到的超大容量 DDoS 攻击的一小部分。

根据 Cloudflare 的观察，2025 年全年超大容量 DDoS 攻击数量持续增加。与上一季度相比，2025 年第四季度的超大容量耗尽攻击增加了 40%。

随着 2025 年全年攻击数量的增加，攻击规模也随之扩大，增幅超过 700%，其中一次 DDoS 攻击的速率高达 31.4 Tbps，但仅持续了 35 秒。下图显示了 Cloudflare 检测并拦截的 DDoS 攻击规模的快速增长趋势，每一次攻击都创下世界纪录，即是当时任何公司公开披露的最大规模攻击。

与所有其他攻击一样，这次 31.4Tbps DDoS 攻击也是由 Cloudflare 的自主 DDoS 防御系统自动检测并缓解。该系统能够快速适应并锁定 Aisuru-Kimwolf 等僵尸网络。

大多数超大容量 DDoS 攻击的目标都是 Cloudflare 在电信、服务提供商和运营商行业的客户。Cloudflare 的游戏行业客户以及提供生成式 AI 服务的客户，也成为重点攻击目标。最后，Cloudflare 自身的基础设施也遭受了多种攻击手段的不同类型攻击，例如 HTTP 洪水、DNS 攻击和 UDP 洪水。

在分析各种规模的 DDoS 攻击时，电信、服务提供商和运营商行业也是遭受到最多攻击的行业。而之前，信息技术和服务行业曾居于“首位”。

博彩与赌场行业以及游戏行业分别排名第三和第四。本季度，排名前十的行业中变化最大的是计算机软件和商业服务行业，两者排名均上升了若干位。

这些行业遭受最多攻击是因为它们发挥着关键基础设施的作用，是其他业务的核心骨干，或者对服务中断和延迟极其敏感，且会立即造成高额的财务损失。

DDoS 攻击态势呈现出可预测的稳定性，但全球遭受攻击最多的地点也出现了显著变化。中国、德国、巴西和美国等目标攻击地点排名前五，表明这些地区对攻击者依旧具有吸引力。

中国香港的排名大幅提高，上升了十二位，位列第二。然而，更引人注目的是英国，其排名在本季度飙升了惊人的 36 位，成为第六大遭受攻击最多的地区。

越南在遭受攻击最多的国家/地区中排名第七，紧随其后的是阿塞拜疆（排名第八）、印度（排名第九）和新加坡（排名第十）。

孟加拉国取代印度尼西亚，成为 2025 年第四季度最大的 DDoS 攻击来源地。印度尼西亚在连续一年占据 DDoS 攻击来源地榜首之后，降至第三位。厄瓜多尔的排名也上升了两位，成为第二大 DDoS 攻击来源地。

值得注意的是，阿根廷的排名猛增了 20 位，成为第四大 DDoS 攻击来源地。中国香港上升了三位，位列第五。乌克兰排名第六，紧随其后的是越南、中国台湾、新加坡和秘鲁。

十大攻击来源网络清单看上去就像一份互联网巨头名单，揭示了现代 DDoS 攻击的运行机制，引人入胜。共同点显而易见：威胁行为者正积极利用全球易于访问、功能强大的网络基础设施，主要是面向公众的大型网络服务。 

我们发现，大多数 DDoS 攻击来自与云计算平台和云基础设施提供商相关的 IP 地址，包括 DigitalOcean (AS 14061)、Microsoft (AS 8075)、Tencent (AS 132203)、Oracle (AS 31898) 和 Hetzner (AS 24940)。这表明，轻松配置的虚拟机与大规模攻击之间存在着密切联系。此类云攻击来源主要集中在美国，紧随其后的是与传统电信公司 (Telcos) 相关联 IP 地址的大量攻击。这些电信公司主要来自亚太地区（包括越南、中国大陆、马来西亚和中国台湾），占据了前十中的其它名额。

这种地理位置和组织的多样性证实了攻击的双重现实：虽然排名最高的攻击来源规模庞大，通常源自全球云中心；但实际上引发了真正的全球性问题，攻击通过互联网的关键路径从世界各地路由传播。在许多 DDoS 攻击中，我们发现了数千个不同来源的 ASN，这凸显了僵尸网络节点的确分布在全球各地。

为了帮助托管服务提供商、云计算平台和互联网服务提供商识别并移除发起这些攻击的滥用 IP 地址/账户，我们利用 Cloudflare 在抵御 DDoS 攻击方面的独特优势，向服务提供商提供免费的 DDoS 僵尸网络威胁数据源。

全球已有 800 多个网络注册使用了该情报源，而且我们已见证整个行业社区通过密切协作，成功打击了僵尸网络节点。

DDoS 攻击的复杂性和规模正在迅速增长，远远超出了以往的想象。这种不断演变的威胁态势给许多企业带来了巨大的挑战，使其难以跟上步伐。目前依赖于本地部署缓解设备或按需清洗中心的企业，可能需要重新评估其防御策略。

Cloudflare 致力于利用其庞大的全球网络和自主 DDoS 缓解系统，为所有客户提供免费、无限的 DDoS 防护，无论攻击规模、持续时间或容量如何。

Cloudforce One 肩负着帮助保护互联网安全的使命，它利用 Cloudflare 全球网络（保护着大约 20% 的 Web 内容）的遥测数据，支持其威胁研究和运营响应，从而为全球数百万个组织的关键系统提供保护。

Matrix 是去中心化、端到端加密通信的黄金标准。它为全球的政府通信系统、开源社区以及注重隐私的组织提供支持。 

然而，对于个人开发人员来说，其吸引力往往更贴近自身功能：将分散的聊天网络（例如 Discord 和 Slack）整合到统一的收件箱中，或者只是确保对话历史记录保存在用户控制的基础设施上。从功能上看，Matrix 作为去中心化、最终一致的状态机运行。家庭服务器不使用中央服务器推送更新，而是通过 HTTP 来交换签名的 JSON 事件，以及使用冲突解决算法将这些数据流合并到房间历史记录的统一视图。

但是，运行 Matrix 需要付出“代价”。过去，运行 Matrix 家庭服务器意味着需要承担繁重的运维工作。用户必须配置虚拟专用服务器 (VPS)，调优 PostgreSQL 来处理繁重的写入负载，管理用于缓存的 Redis，配置反向代理，以及处理 TLS 证书的轮换。它有如一头有状态的重量级庞然大物，无论使用频率高低，都需要投入时间和金钱。

我们想了解能否彻底消除这种代价。

剧透一下：我们做到了。在这篇文章中，我们将解释 Cloudflare 如何将 Matrix 家庭服务器移植到 Cloudflare Workers。最终的概念验证成果是一个无服务器架构，这个架构几乎无需运维操作，空闲时成本降至零，并且默认情况下每个连接都受到后量子加密技术的保护。用户可以查看源代码并直接从 Github 部署实例。

我们的切入点是 Synapse，这是基于 Python 的参考 Matrix 家庭服务器，专为传统部署而设计。它使用 PostgreSQL 进行持久化存储，Redis 进行缓存，文件系统用于存储媒体。

将它移植到 Workers 意味着质疑我们过去视为理所当然的每一个存储假设。

挑战在于存储。传统的家庭服务器认为，通过中央 SQL 数据库实现强一致性。Cloudflare Durable Objects 提供强大的替代方案。这个基本组件可提供解析 Matrix 状态所需的强一致性与原子性，并仍然支持应用在边缘运行。

我们使用 Hono 框架，将 Matrix 协议的核心逻辑（事件授权、房间状态解析、加密验证）移植到 TypeScript 中。D1 取代 PostgreSQL；KV 取代 Redis；R2 取代文件系统；Durable Objects 则负责处理实时协调。

映射的工作原理如下：

迁移到 Cloudflare Workers 为开发人员带来诸多优势：部署简单、降低成本、降低延迟和内置安全性。

轻松部署：传统的 Matrix 部署需要配置服务器、管理 PostgreSQL、管理 Redis 集群、更新 TLS 证书、配置负载平衡器、监测基础设施以及轮班值守。

使用 Workers，部署变得非常简单：只需运行 wrangler deploy 命令即可。Workers 会处理 TLS 证书、负载平衡、DDoS 防护和全球分发。

按使用量计费：传统的家庭服务器无论是否有人使用，都需要付费。Workers 采用基于请求的定价，因此，用户只需在使用时付费，而当所有用户均处于睡眠状态时，成本几乎降至零。 

降低全球范围内的延迟：位于 us-east-1 的传统 Matrix 家庭服务器会为亚洲或欧洲用户增加 200 毫秒以上的延迟。与此同时，Workers 在全球 300 多个地点运行。当位于东京的用户发送消息时，Worker 会在东京执行。 

内置安全性：Matrix 家庭服务器可能成为高价值攻击目标：因为它们负责处理加密通信、存储消息历史记录，以及验证用户身份。传统部署需要精心加固：防火墙配置、速率限制、DDoS 缓解、WAF 规则、IP 信誉过滤。

Workers 默认提供所有这些功能。 

2022 年 10 月，Cloudflare 在所有 TLS 1.3 连接中部署了后量子混合密钥协议。每个与 Cloudflare Workers 的连接都会自动协商 X25519MLKEM768，这是结合了经典 X25519 与 ML-KEM（由 NIST 标准化的后量子算法）的混合密钥交换算法。

经典密码学依赖于传统计算机无法解决的数学难题来保证安全性，但运行 Shor 算法的量子计算机却可以轻而易举地解决此类问题。ML-KEM 基于点阵问题，即使是量子计算机也仍然难以解决这些问题。混合密钥意味着只有当两种算法都失效时，才会破坏连接。

理解在哪里执行加密对于安全架构而言至关重要。当有人通过我们的家庭服务器发送消息时，消息的实际传输路径如下所述：

发送者的客户端接收明文消息，并使用 Matrix 的端到端加密算法 Megolm 进行加密。然后，已加密的有效负载会被封装在 TLS 中进行传输。在 Cloudflare 平台中，该 TLS 连接使用 X25519MLKEM768 算法，使其能够抵御量子攻击。

Worker 会终止 TLS，但它接收到的仍然是加密信息，即 Megolm 密文。Cloudflare 将该密文存储在 D1 中，按房间和时间戳对其进行索引，然后将其传递给接收者。但我们永远不会看到明文。“Hello, world”消息仅存在于发送者和接收者的设备上。

当接收者进行同步时，流程步骤则相反。他们通过另一个可抵御量子攻击的 TLS 连接来接收已加密的有效负载，然后使用 Megolm 会话密钥在本地解密。

通过两个独立运行的加密层提供保护：

传输层 (TLS) 保护传输中的数据。数据在客户端加密，然后在 Cloudflare 边缘解密。现在，使用 X25519MLKEM768 算法，传输层能够抵御量子攻击。

应用层 (Megolm E2EE) 保护消息内容。这些内容在发送者设备上加密，并且仅在接收者设备上解密。这使用了经典的 Curve25519 加密技术。

任何 Matrix 家庭服务器运营商（无论是在 VPS 上运行 Synapse 还是在 Workers 上运行这项实施）都可以看到元数据：存在哪些房间，房间里有哪些用户，何时发送了消息。但基础设施链中的任何人都无法看到消息内容，因为端到端加密 (E2EE) 有效负载在到达网络之前已经在发送者设备上加密。Cloudflare 会终止 TLS 连接并将请求传递到 Worker，但两者都只能看到 Megolm 密文。加密房间中的媒体在上传之前会在客户端完成加密，而且私钥永远不会离开用户设备。

在传统的 Matrix 部署中实现后量子 TLS 需要执行以下步骤：将 OpenSSL 或 BoringSSL 升级为支持 ML-KEM 的版本，正确配置密码套件首选项，测试所有 Matrix 应用的客户端兼容性，监测 TLS 协商失败，随着 PQC 标准的演变维持及时更新，以及妥善处理不支持 PQC 的客户端。

如果使用 Workers，上述步骤均自动完成。Chrome、Firefox 和 Edge 都支持 X25519MLKEM768 密钥交换算法。使用平台 TLS 堆栈的移动应用继承了这种支持。随着 Cloudflare PQC 部署的扩展，安全态势有所改善，无需采取任何行动。

移植 Tuwunel 的关键在于，需要确保不同数据之间的一致性。我们充分利用 Cloudflare 的每一个基本组件。

D1 会存储需要在重启后依旧存在且支持查询的所有内容：用户、房间、事件、设备密钥。超过 25 个表格涵盖了完整的 Matrix 数据模型。

CREATE TABLE events (
	event_id TEXT PRIMARY KEY,
	room_id TEXT NOT NULL,
	sender TEXT NOT NULL,
	event_type TEXT NOT NULL,
	state_key TEXT,
	content TEXT NOT NULL,
	origin_server_ts INTEGER NOT NULL,
	depth INTEGER NOT NULL
);

D1 以 SQLite 为基础，也就是说，可以通过最小的改动来移植 Tuwunel 的查询。连接、索引和聚合均能正常发挥作用。

我们吸取了一个惨痛的教训：D1 的最终一致性会打破外键约束。当后续写入事件检查外键时，写入房间的操作可能不可见。因此，我们移除了所有外键，并在应用代码中强制执行引用完整性。

OAuth 授权代码的有效期为 10 分钟，而刷新令牌的有效期为整个会话。

// Store OAuth code with 10-minute TTL
kv.put(&format!("oauth_code:{}", code), &token_data)?
	.expiration_ttl(600)
	.execute()
	.await?;

KV 的全球分布意味着，无论用户身处何地，OAuth 流程都能快速运行。

Matrix 媒体直接映射到 R2，从而让用户上传图像，获取内容寻址的 URL，而且数据出口免费。

某些操作无法容忍最终一致性。当客户端声明一次性加密密钥时，必须以原子方式移除该密钥。如果两个客户端声明相同的密钥，则加密会话建立失败。

Durable Objects 提供单线程、强一致性存储：

#[durable_object]
pub struct UserKeysObject {
	state: State,
	env: Env,
}

impl UserKeysObject {
	async fn claim_otk(&self, algorithm: &str) -> Result<Option<Key>> {
    	// Atomic within single DO - no race conditions possible
    	let mut keys: Vec<Key> = self.state.storage()
        	.get("one_time_keys")
        	.await
        	.ok()
        	.flatten()
        	.unwrap_or_default();

    	if let Some(idx) = keys.iter().position(|k| k.algorithm == algorithm) {
        	let key = keys.remove(idx);
        	self.state.storage().put("one_time_keys", &keys).await?;
        	return Ok(Some(key));
    	}
    	Ok(None)
	}
}

我们使用 UserKeysObject 进行 E2EE 密钥管理，使用 RoomObject 处理实时房间事件（例如输入指示器和已读回执），以及使用 UsersyncObject 管理到设备的消息队列。其余消息则流经 D1。

我们的实施支持完整的 Matrix E2EE 堆栈：设备密钥、交叉签名密钥、一次性密钥、备用密钥、密钥备份和脱水设备。

现代 Matrix 客户端使用 OAuth 2.0/OIDC，而不是传统的密码流程。我们实施了一个完整的 OAuth 提供程序，支持动态客户端注册、PKCE 授权、RS256 签名 JWT 令牌、轮换令牌刷新，以及标准 OIDC 发现端点。

curl https://matrix.example.com/.well-known/openid-configuration
{
  "issuer": "https://matrix.example.com",
  "authorization_endpoint": "https://matrix.example.com/oauth/authorize",
  "token_endpoint": "https://matrix.example.com/oauth/token",
  "jwks_uri": "https://matrix.example.com/.well-known/jwks.json"
}

将 Element 或任何 Matrix 客户端连接到特定域，它会自动发现所有内容。

传统的 Matrix 同步会在初始连接时传输数兆字节的数据，从而消耗移动设备的电池电量和流量套餐。

Sliding Sync 让客户端可以请求获取其所需的内容。客户端无需下载所有内容，而是获取最近 20 个状态最小化的房间。随着用户滚动浏览，他们可以请求更多范围。服务器会跟踪用户位置，并仅发送房间状态的增量数据。

与边缘执行相结合，即使在网络速度较慢的情况下，移动客户端也能在 500 毫秒内完成连接并渲染房间列表。

对于服务小型团队的家庭服务器，二者之间的对比如下所述：

^{*根据截至 2026 年 1 月 15 日，DigitalOcean、AWS Lightsail 与 Linode 发布的公开费率和指标。}

如果规模化部署，经济效益将进一步提高。传统部署需要容量规划和超额配置。Workers 可以自动扩展。

我们最初将此作为一个实验：Matrix 能否在 Workers 上运行？答案是“能”，而且这种方法也适用于其他有状态协议。

通过将传统的有状态组件映射到 Cloudflare 的基本组件，例如 Postgres 到 D1、Redis 到 KV、mutex 到 Durable Objects，我们可以看到，复杂的应用并不需要复杂的基础设施。我们剥离了操作系统、数据库管理和网络配置，只保留了应用程序逻辑和数据本身。

Workers 让用户拥有数据主权，而无需承担维护基础设施的负担。

我们一直在尝试不同的实施方式，也期待对这类服务感兴趣的其他人踊跃提出建议和做出贡献。 

是否准备好在 Workers 上构建强大的实时应用？立即开始使用 Cloudflare Workers 并探索 Durable Objects，构建自定义的有状态边缘应用。欢迎加入我们的 Discord 社区，与在边缘端进行开发的其他开发人员联系和交流。

这篇博客文章是对观察到和已确认的中断事件的总结性概述，并不是第四季度所发生问题的详尽或完整清单。我们通过 Cloudflare 网络中观察到的趋势与预期流量模式的显著偏差检测了这些异常情况。请访问 Cloudflare Radar 中断中心，查看已验证的异常情况以及已确认的中断事件的完整列表。 

10 月 29 日，坦桑尼亚互联网服务中断，因为在该国总统大选投票期间发生了暴力抗议。流量最初在当地时间 12:30 左右 (09:30 UTC) 骤降，比上一周下降了超过 90%。此次中断持续约 26 小时，流量在 10 月 30 日当地时间 14:30 (11:30 UTC) 左右开始恢复。然而，那次恢复非常短暂，大约两小时后，即当地时间 16:15 (13:15 UTC) 左右，流量再次大幅下降。第二次近乎完全的网络中断一直持续到 11 月 3 日，并在当地时间 17:00 (14:00 UTC) 后，流量显著恢复。根据观察，已公布的 IPv4 和 IPv6 地址空间在断网期间也出现了名义上的数量下降，但从未出现公告完全丢失的情况，如果公告完全丢失，即表明该国互联网完全断开。（自治系统会向其他互联网服务提供商公布 IP 地址空间，让它们知道各自负责的 IP 地址块。）

随后，坦桑尼亚总统向遭受此次互联网服务中断影响的驻该国外交使团成员和外籍人士表示了慰问。2020 年坦桑尼亚大选之前，该国的互联网和社交媒体服务也受到过限制。

Digcel Haiti 对电缆切断造成的互联网中断并不陌生，遗憾的是，该公司在第四季度又经历了两起此类事件。10 月 16 日，来自 Digicel Haiti (AS27653) 的流量于当地时间 14:30 (18:30 UTC) 开始下降，随后在当地时间 16:00 (20:00 UTC) 几乎降至零。该公司总经理在 X 平台上发帖指出：“我们在此通知客户，@DigicelHT 的国际光纤基础设施目前出现了两处故障。”当地时间 17:00 (21:00 UTC) 之后，流量开始恢复，并在接下来的一小时内达到了预期水平。当地时间 17:33 (21:34 UTC)，总经理发帖声称，“国际基础设施中的第一根光纤已修复”，并且服务已恢复。 

11 月 25 日，该公司总经理在 X 平台上发布另一条帖子指出，公司“1 号国道上的国际光纤基础设施”已被切断。根据观察，大约一小时前，Digicel 网络流量下降，并在当地时间 02:00 - 08:00 (07:00 - 13:00 UTC) 期间完全中断。当地时间 08:22 (13:22 UTC)，总经理发布的一条 X 更新帖表示，所有服务均已恢复。

10 月 20 日当地时间 17:30 (12:30 UTC)，Cybernet/StormFiber (AS9541) 的互联网流量急剧下降，降至上周同一时段的 50% 左右。与此同时，该网络已公布的 IPv4 地址空间数量减少了超过三分之一。造成这些变化的原因是 PEACE 海底光缆受损，它在苏丹附近的红海地区遭到破坏。 

PEACE 是为巴基斯坦网络提供商传输国际互联网流量的几个海底光缆系统之一（其它还包括 IMEWE 和 SEA-ME-WE-4）。该提供商承诺在 10 月 27 日之前全面恢复服务，但在 10 月 21 日当地时间 02:00 左右（10 月 20 日 21:00 UTC），流量与已公布的 IPv4 地址空间均恢复到接近预期水平。

据报道，根据，10 月 23 日观察到喀麦隆多家互联网服务提供商出现了流量异常，原因是连接非洲西海岸各国与葡萄牙的西非海底光缆系统 (WACS) 出现问题。 

一份已发布的报告（翻译版）指出，MTN 通知用户“WACS 光缆发生了故障，随后互联网服务暂时中断”，Orange Cameroun 通知用户“由于国际接入光缆发生故障，互联网服务中断。”Camtel 发布了一条 X 帖子表示：“喀麦隆电信 (CAMTEL) 特此通知公众，2025 年 10 月 23 日凌晨，位于巴托克 (LIMBE) 的 WACS 光缆设备发生技术故障，导致全国互联网连接中断。” 

起初，受影响的网络提供商的流量在当地时间 05:00 (04:00 UTC) 左右出现下降，随后在当地时间 22:00 (21:00 UTC) 左右恢复到预期水平。流经这些网络的流量在当天波动较大，有时甚至下降 90-99%。目前尚不清楚造成流量波动的原因，可能是由于尝试将互联网流量转移到连接喀麦隆的其他海底光缆系统。在此期间，MTN Cameroon 和 Orange Cameroon 已公布的 IP 地址空间也出现下降，但 Camtel 已公布的 IP 地址空间没有变化。

据报道，中非共和国和刚果共和国的网络连接也受到了 WACS 故障问题的影响。

12 月 9 日，我们观察到多米尼加共和国互联网服务提供商 Claro Dominicana (AS6400) 的流量在当地时间 12:15 (16:15 UTC) 左右急剧下降。流量水平在当地时间 14:15 (18:15 UTC) 左右再次下降，比上周降低 77%，之后迅速恢复到预期水平。此次网络连接中断可能是由两处光纤故障造成，因为服务提供商在中断期间发布了一条 X 帖子指出，故障“导致部分服务出现间歇性中断和运行速度变慢”。Claro 公司发布了一条 X 更新帖指出，技术人员已修复断裂的光缆，全国范围内的互联网服务已经恢复。

根据 Transmisión Eléctrica Dominicana (ETED) 发布的一条 X 帖子（翻译版）可知，11 月 11 日，多米尼加共和国的输电线路故障导致了电力服务中断。此次停电影响了该国的互联网流量，导致从当地时间 13:15 (17:15 UTC) 开始，流量比上一周下降了将近 50%。流量水平一直维持在较低水平，直到 12 月 12 日当地时间 02:00 (06:00 UTC) 左右，随后 ETED 发布了一条 X 帖子（翻译版）指出：“凌晨 2:20，我们已经完成了国家电力系统的恢复，可以满足 96% 的需求。”

随后的一份技术报告指出，“最初是 138 kV San Pedro de Macorís I 变电站停电，该变电站的一条带电线路被手动断开，引发了高强度短路。保护系统立即做出响应，但故障导致附近的几条线路相继断开，将东部地区 575 兆瓦发电容量与电网其余部分隔离开来。这种失衡导致主要发电厂自动跳闸，这是发电厂内置安全机制的组成部分”。

12 月 9 日，肯尼亚多个地区遭遇大面积停电。Kenya Power 解释说，此次停电“是由肯尼亚-乌干达区域互联电网的一个故障引发，这对肯尼亚一侧的电力系统造成了干扰”，并声称“大约 30 分钟内，大部分受影响地区已恢复供电。”不过，互联网连接中断从当地时间 19:15 至 23:00 (16:15 - 20:00 UTC) 持续了将近四个小时。停电导致肯尼亚全国流量下降了 18%，其中 Nakuru County 和 Kaimbu County 的流量变化最明显。

12 月 12 日，俄罗斯无人机袭击了乌克兰境内的敖德萨地区，不仅损坏了当地的仓库和能源基础设施，而且导致该地区部分区域停电。停电中断了互联网连接，导致与上一周相比，流量下降了高达 57%。经过 12 月 13 日当地时间午夜（12 月 12 日 22:00 UTC）的首次下降后，流量在接下来的几天内逐渐恢复，于 12 月 16 日当地时间 14:30 (12:30 UTC) 左右恢复到预期水平。

飓风“梅利莎”于 10 月 28 日登陆牙买加，沿途造成了严重的损坏和破坏。随之而来的停电和基础设施损坏影响了互联网连接，因此，起初从当地时间 06:15 (11:15 UTC) 左右开始，流量下降了大约一半，最终比上一周下降了 70%。牙买加的互联网流量在飓风来临前的几天里一直远低于飓风前的水平，直到 11 月 4 日上午才开始逐渐恢复到预期水平。面对造成了大规模广泛破坏的暴风雨，一个国家/地区的互联网流量通常可能需要数周或数月时间才能恢复到“正常”水平。虽然电力供应可能在几天内基本恢复，但修复已受损的物理基础设施则需要花费更长时间。

11 月 26 日，气旋“森雅”在斯里兰卡和印度尼西亚引发了灾难性洪水和山体滑坡，造成 1000 多人死亡，破坏了这些国家的电信和电力基础设施。基础设施损坏导致多个地区的互联网连接中断，流量也随之下降。

在斯里兰卡，除西部省以外的多个地区都受到最严重的影响，多个省份的流量比上一周下降了 80% 到 95%，包括西北省、南部省、乌瓦省、东部省、北部省、中北省和萨伯勒格穆沃省。

在印度尼西亚，亚齐省和苏门答腊地区的网络中断最为严重。亚齐省的流量最初比上一周下降了超过 75%。苏门答腊地区的北苏门答腊省受影响最严重，流量最初比上一周下降了 30%，随后在下一周开始加快恢复。

10 月 3 日，印度尼西亚互联网服务提供商 Smartfren (AS18004) 的用户遭遇了服务中断。该服务提供商在一条 X 帖子中确认了相关问题，帖文指出（翻译版）：“目前，多个地区的电话、短信和数据服务出现了故障”。该服务提供商的流量从当地时间 09:00 (02:00 UTC) 左右开始下降，降幅高达 84%。中断持续了大约八个小时，流量在当地时间 17:00 (10:00 UTC) 左右恢复到预期水平。Smartfren 并未提供任何关于服务故障原因的额外信息。

英国主要互联网服务提供商 Vodafone UK（AS5378 与 AS25135）在 10 月 23 日经历了短暂的服务中断。当地时间 15:00 (14:00 UTC)，两个 Vodafone ASN 的流量均骤降至零。源自 AS5378 的已公布 IPv4 地址空间减少了 75%，而源自 AS25135 的已公布 IPv4 地址空间则完全消失。两个小时后，也就是当地时间 17:00 (16:00 UTC) 左右，互联网流量和地址空间均恢复到预期水平。Vodafone 没有在其社交媒体频道中提供任何关于此次中断原因的信息，该公司的网络状态检查器页面在中断期间也不可用。

根据一份已发布的报告，10 月 22 日，意大利网络服务提供商 Fastweb (AS12874) 的一个 DNS 解析问题导致其用户的互联网服务中断，进而导致观测到的流量下降超过 75%。Fastweb 确认了这个问题，该问题在当地时间 09:30 - 13:00 (08:30 - 12:00 UTC) 期间影响了有线互联网客户。

虽然此次网络中断并非由网络连接故障导致，但 DNS 解析问题对互联网流量的影响非常相似。如果服务提供商的 DNS 解析器出现问题，切换到 Cloudflare 1.1.1.1 公共 DNS 解析器等服务通常可以恢复网络连接。

12 月 7 日，根据观察，SBIN (AS28683)、MTN Benin (AS37424) 和 Etisalat Benin (AS37136) 网络同时出现流量下降。当地时间 18:30 - 19:30 (17:30 - 18:30 UTC) 期间，全国范围内的流量比上一周下降了高达 80%，其中 Etisalat 和 MTN 的流量降幅接近 100%，SBIN 的流量降幅也超过 80%。

虽然当天早些时候该国发生了一起未遂政变，但目前尚不清楚观察到的此次网络中断是否与政变相关。从路由角度来看，这三个受影响的网络都使用 Cogent (AS174) 作为上游服务提供商，因此，Cogent 的局部问题可能引发了此次短暂的网络中断。  

据报道，以色列网络服务提供商 Cellcom (AS1680) 的一份公告显示，12 月 18 日出现了“互联网连接故障，影响了部分客户”。此次故障发生在当地时间 09:30 - 11:00 (07:30 - 09:00 UTC) 期间，导致流量比上一周下降了将近 70%。一份已发布的报告指出，此次“故障”的原因可能是 DNS 解析失败。

2025 年即将结束之际，12 月 30 日，以色列网络服务提供商 Partner Communications (AS12400) 发生了重大技术故障，导致以色列全国范围内的手机、电视和互联网服务中断。此次故障发生在当地时间 14:00 - 15:00 (12:00 - 13:00 UTC) 期间，导致 Partner Communications 的流量比上一周下降了三分之二。服务中断期间，Cloudflare 1.1.1.1 公共 DNS 解析器接收的查询量激增，这表明问题可能与合作伙伴的 DNS 基础设施息息相关。不过，该服务提供商并未公开确认导致此次服务中断的原因。

第四季度，我们在 Cloudflare Radar 上推出了全新的 Cloud Observatory 页面，用于跟踪包括 Amazon Web Services、Microsoft Azure、Google Cloud Platform 以及 Oracle Cloud Infrastructure 在内的超大规模云平台在地区层面的可用性和性能问题。

10 月 20 日，位于弗吉尼亚州北部的 Amazon Web Services us-east-1 地区出现“错误率和延迟增加”的情况，影响了该地区的多项服务。这些问题不仅影响了该地区的客户以及依赖基础设施的面向公众的网站和应用程序，而且还影响了在 us-east-1 地区托管源服务器资源的 Cloudflare 客户。

根据观察，这些问题大约在 06:30 UTC 时开始产生影响，因为错误（5xx 类）响应比例开始攀升，并在 08:00 UTC 左右达到 17%。us-east-1 中尝试连接源服务器时出现的故障数量也随之增加，并在 12:00 UTC 左右达到峰值。

事件的影响也清晰地体现在关键网络性能指标上，这些指标在整个事件期间一直保持较高水平，直到事件结束前不久（即 23:00 UTC 左右）才恢复到正常水平。在整个事件期间，TCP 与 TLS 握手持续时间逐渐变差，这些指标旨在衡量 Cloudflare 与 us-east-1 中的客户源服务器建立 TCP 与 TLS 连接所需的时间。此外，在事件发生后的最初几个小时内，Cloudflare 从源服务器接收响应标头所需的时间显著增加，之后逐渐恢复到预期水平。

10 月 29 日，Microsoft Azure 发生了一起事件，影响到其内容分发网络服务 Azure Front Door。Azure 的事件报告显示，“客户在两个不同的控制平面构建版本上执行特定顺序的配置更改，导致生成了不兼容的客户配置元数据。这些客户配置更改本身是有效且无恶意的，但它们生成的元数据在部署到边缘站点服务器后暴露了数据平面中的一个潜在错误。这种不兼容性导致在数据平面服务内进行异步处理时触发了崩溃。”

事件报告标记的开始时间是 15:41 UTC，但我们观察到，连接到 Azure 托管源的失败尝试数量在大约 45 分钟之前已开始攀升。事件发生期间，TCP 与 TLS 握手指标也变得更加不稳定，TCP 握手时间有时延长超过 50%，TLS 握手时间在峰值时延长了将近 200%。受影响的指标在 20:00 UTC 后开始改善，Microsoft 表示，此次事件于 10 月 30 日 00:05 UTC 结束。

除了上述中断之外，Cloudflare 在第四季度还经历了两次中断。虽然这些不是传统意义上的互联网服务中断，但确实导致用户在中断期间无法访问由 Cloudflare 路由和保护的网站与应用。

首次中断发生在 11 月 18 日，是由软件故障引起，该故障是因为我们数据库系统权限变更而触发，权限变更导致数据库将多个条目输出到 Cloudflare 机器人管理系统使用的“特征文件”。如需了解更多详细信息，包括根本原因分析和时间线，请参阅相关的博客文章。

第二次中断发生在 12 月 5 日，此次事件影响了部分客户，约占 Cloudflare 处理的 HTTP 总流量的 28%。它是由于我们对请求正文解析逻辑进行更改而引起，当时我们正在尝试检测并缓解新披露的行业级 React Server Components 漏洞。这篇事后分析博客文章中包含更多详细信息，包括根本原因分析和时间线。

如需进一步了解 Cloudflare 为防范此类服务中断事件再次发生而正在开展的工作，请查看我们的博客文章，其中详细介绍了“橙色警报：小规模故障”计划。

第四季度观察到的网络中断事件，凸显了实时数据在维持全球连接方面的重要作用。无论是政府下令的网络中断还是轻微的技术问题，维持透明度都能让技术社区更快速、更有效地做出响应。我们将继续使用 Cloudflare Radar 跟踪这些流量变化，提供应对复杂的现代网络所需的见解。我们会通过 Cloudflare Radar 中断中心、社交媒体，以及 blog.cloudflare.com 网站上的博客文章来发布相关观察结果。欢迎在社交媒体上关注我们：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)，或通过电子邮件联系我们。

温馨提醒，虽然这些博客文章使用来自 Radar 和 Radar Data Explorer 的图表，但底层数据均可通过 Cloudflare API 获得。您可以使用 API 来检索数据，进行本地监测或分析，也可以使用 Radar MCP 服务器将 Radar 数据集成到自有 AI 工具中。

Astro 是用于构建快速、内容驱动型网站的 Web 框架。在过去的几年里，我们已经看到了非常多不同类型的开发人员和公司使用 Astro Web 框架进行构建。其中包括保时捷 (Porsche) 和宜家 (IKEA) 等知名品牌，以及 Opencode 和 OpenAI 等快速发展的 AI 公司。基于 Cloudflare 解决方案构建的平台，例如 Webflow Cloud 和 Wix Vibe，也已选择 Astro 为其客户构建网站并部署到自有平台提供支持。Cloudflare 也使用 Astro 框架来创建开发人员文档、网站、登陆页、博客等。几乎所有互联网内容的创建都在利用 Astro 框架。

通过与 Astro 团队强强联手，我们会加倍努力，将 Astro Web 框架打造成内容驱动型网站的卓越代表。Astro 的最佳版本（也就是 Astro 6）即将发布，将带来由 Vite 提供支持的重新设计后的开发服务器。Astro 6 的首个公开测试版现已发布，正式版 (GA) 将在未来几周内推出。

我们很高兴能分享这则消息，并且更期待这对使用 Astro 框架进行构建的开发人员的非凡意义。如果您还没有尝试过 Astro，不妨试一试并运行 npm create astro@latest 命令。

Astro 将继续保持开源，采用 MIT 许可证，接受用户贡献，并且拥有公开的路线图和开放的治理机制。Astro Technology Company 的所有全职员工现在都是 Cloudflare 员工，并将继续参与 Astro 的开发工作。我们致力于 Astro 的长期成功，也渴望继续完善这个框架。

如果没有非常强大的开源贡献者社区，Astro 不会取得如今的成就。Cloudflare 还致力于通过 Astro 生态系统基金，以及与包括 Webflow、Netlify、Wix、Sentry、Stainless 等在内的众多行业合作伙伴一起，继续支持开源贡献。

从一开始，Astro 就看好 Web 框架和可移植性：Astro 设计为跨云和跨平台运行。这一点不会改变。您可以将 Astro 框架部署到任何平台或云，我们致力于为世界各地的 Astro 开发人员提供支持。

Astro 一直呈现出快速发展的势头：

为什么？因为许多 Web 框架层出不穷，试图面面俱到但最终都销声匿迹，其目标是既满足内容驱动型网站的需求，又满足 Web 应用的需求。

Astro 框架脱颖而出的关键在于：Astro 没有试图为所有用例提供服务，而是始终坚守五项设计原则。Astro 是…

• 内容驱动：Astro 框架的设计宗旨是展示网页内容。

• 服务器优先：在服务器端渲染 HTML 时，网站运行速度更快。

• 默认快速：使用 Astro 框架构建的网站不可能运行缓慢。

• 易于使用：用户无需成为专家，也可以使用 Astro 框架来构建内容。

• 以开发人员为中心：开发人员拥有成功所需的资源。

Astro 的岛屿架构是这一切得以实现的核心。每个页面的大部分内容都可能是快速、静态的 HTML，默认情况下，构建起来既快速又简单，并且围绕内容渲染而设计。用户可以根据需要，使用任何客户端用户界面框架将页面的特定部分渲染成客户端岛屿。甚至也可以在同一页面上混合和匹配多个框架，无论是 React.js、Vue、Svelte、Solid 或其他任何框架。

Astro 与 Cloudflare 的交谈越多，我们就越发意识到彼此的共同点。Cloudflare 的使命是帮助构建更好的互联网，其中一部分正是帮助构建更快速的互联网。几乎所有团队成员都是在构建网站的过程中成长起来，我们希望构建的世界是所有人都享受在互联网上创建内容的乐趣，任何人都可以将自己的内容发布到真正属于自己的网站上。

当 Astro 于 2021 年首次推出时，构建出色的网站变得异常艰难，感觉就像是在与各种构建工具和框架作斗争。随着编码智能体和强大的大语言模型 (LLM) 的出现，如今这话听起来或许有些不可思议；但在 2021 年，如果不是 JavaScript 构建工具领域的专家，想要构建一个优秀且快速的网站确实非常困难。由于 Astro 以及更广泛的前端生态系统的发展，情况得到了显著改善，以至于我们如今几乎认为这是理所当然的事情。

过去五年来，Astro 团队一直致力于简化 Web 开发。随着大语言模型 (LLM)，然后是氛围编码，以及当前真正的编码智能体的出现，任何人都能进行构建，因为 Astro 框架提供易于使用、默认快速的基础。我们都已经看到，在结构良好的代码库中基于正确的基础架构进行构建，智能体能的性能和速度会得到显著提升。越来越多的构建者和平台都选择 Astro 框架作为基础。

这一点在 Cloudflare 与 Astro 共同服务的平台中体现得尤为明显，这些平台利用 Cloudflare for Platforms，以富有创意的方式将 Cloudflare 扩展到支持其客户，并选择 Astro 作为其客户构建内容的框架。 

客户部署到 Webflow Cloud 后，Astro 网站即可正常运行并部署到 Cloudflare 网络。客户使用 Wix Vibe 创建一个新项目后，后台会创建一个在 Cloudflare 上运行的 Astro 网站。客户使用 Stainless 生成开发人员文档网站后，会生成一个在 Cloudflare 上运行的 Astro 项目，该项目由 Starlight 提供支持，这是一个基于 Astro 构建的框架。

这些平台各自面向不同的受众群体。但除了都使用 Cloudflare 和 Astro 之外，它们的共同点是让在互联网上创建和发布内容变得有趣。在当今人人皆可成为构建者和内容创作者的世界，我们认为还有更多平台值得构建，以及更多用户值得触达。

Astro 6 即将推出，首个公开测试版现已发布。如果希望成为首批尝试的用户之一，请运行：

npm create astro@latest -- --ref next

或者，如需升级现有的 Astro 应用，请运行：

npx @astrojs/upgrade beta

Astro 6 将带来基于 Vite Environments API 构建的一款全新的开发服务器，它使用与部署环境相同的运行时在本地运行用户代码。也就是说，当用户使用 Cloudflare Vite 插件运行 astro dev 时，代码将在 workerd（开源 Cloudflare Workers 运行时）中运行，而且可以使用 Durable Objects、D1、KV、Agents 等。这并非 Cloudflare 独有的功能：任何使用 Vite Environments API 插件的 JavaScript 运行时环境都会受益于这项新支持，确保本地开发环境与生产环境使用相同的运行时 API。

Astro 中的实时内容采集功能在 Astro 6 中也保持稳定，并且已完成测试。这些内容集合功能让用户可以实时更新数据，无需重建网站。这使得引入经常变更的内容（例如店铺中的当前库存信息）变得轻而易举，同时仍然能够受益于 Astro 现有内容采集支持所提供的内置验证和缓存功能。

Astro 6 还有更多新增功能，包括 Astro 最受欢迎（得到最多点赞）的功能请求：对内容安全策略 (CSP) 的一流支持，以及更简洁的 API、Zod 4 升级等。

我们很高兴欢迎 Astro 团队加入 Cloudflare。我们期待能够继续开发、继续交付，并不断努力将 Astro 框架打造成构建内容驱动型网站的卓越代表。我们已经在思考 V6 之后的版本，并且乐于倾听用户反馈。

如需了解最新动态，请关注 Astro 博客并加入 Astro Discord。欢迎分享您正在构建的内容！

今天，我们很高兴地宣布，Cloudflare 已经收购了 Human Native。后者是一家总部位于英国的 AI 数据平台公司，专注于将多媒体内容转换为可搜索的有用数据。

Human Native 团队在过去几年一直致力于帮助 AI 开发人员利用已获许可的数据来优化 AI。他们的技术帮助出版商和开发人员将杂乱无章的非结构化内容转换为易于理解、获得许可的数据并最终产生价值。他们采用的方法不是将数据视为可供抓取的对象，而是将其视为值得结构化梳理、维持透明和予以尊重的资产类别。

获得优质数据可能有助于提升技术性能。Human Native 的一个客户，一家知名的英国视频 AI 公司，在使用 Human Native 提供的数据取得了卓越成果之后，丢弃了现有的训练数据。今后，他们只使用获得完全许可、来源可靠的优质数据进行训练。

这预示着生成式 AI 时代的互联网经济模型未来可能的发展方向：基于更优质的数据构建功能更强大的 AI，为创作者提供公平的控制权、补偿和署名权。

过去 30 年来，开放的互联网一直建立在一种基本的价值交换基础之上：创作者创建内容，聚合网站（例如搜索引擎或社交媒体）输送流量。创作者可以通过广告、订阅或直接支持，将这些流量变现。正是这种经济循环推动了互联网的爆炸式增长。

但这种模式正遭遇严峻考验。

爬取与引荐比率正在飙升，每个真人访客平均经历数万次 AI 和机器人爬取，而且目前尚不清楚多用途爬网程序会如何使用它们访问的内容。

在互联网上发布内容的创作者群体非常多元化，包括：新闻出版商、内容创作者、金融专业人士、科技公司、聚合网站等。但这些创作者拥有一个共同点：他们都希望决定 AI 系统使用其内容的方式。

Cloudflare 积极构建 AI Crawl Control 和按抓取付费的工作基于一个简单的理念：内容所有者应该有权决定他人如何以及何时访问其内容。Cloudflare 的许多客户都希望优化他们的品牌和内容，确保其出现在每个训练数据集中，以及在每次新的搜索结果中出现；而其他客户则希望拥有更多控制权，并且只有在提供直接报酬的情况下才允许访问。

无论贵公司属于哪一种客户，AI Search、AI Crawl Control 以及按抓取付费等 Cloudflare 工具都能提供帮助。重要的是，内容所有者掌握最终的决定权。

随着 Human Native 团队加入 Cloudflare，我们将加速推进相关工作，帮助客户对其内容进行转换，从而让传统的真人受众以及 AI 机器人与智能体均可轻松访问和理解这些内容。

爬取过程复杂且成本高昂，处理内容需要耗费大量工程和计算资源，而且没有质量控制保证。爬取的索引可能包含重复项、垃圾邮件、非法资料以及更多令人头疼的问题，导致开发人员面临杂乱无章的非结构化数据。

Cloudflare 最近宣布了正在构建 AI Index，这是一种强大的全新方式，适用于基础模型公司和代理大规模访问内容。

AI 开发人员能够通过发布/订阅模式进行连接：参与的网站在更改内容后发布结构化更新，开发人员可以订阅来实时接收这些更新；而不是盲目地、反复地在开放的互联网上发送爬网程序。

这为内容创作者尝试新的商业模式开辟了新的途径。

Cloudflare 将投入巨资为这些新的商业模式奠定基础，首先从 x402 开始。

我们最近宣布了与 Coinbase 合作创建 x402 Foundation，以支持数字资源的机器对机器交易。

从历史上看，网络支付是为了服务于人类的经济活动而设计。我们浏览商家的网站，通过将商品添加到购物车来表明购买意向，然后通过输入信用卡信息并单击“支付”来确认购买。但是，如果想要实现自动化系统之间的直接交易，应该怎么办呢？我们需要协议来支持机器对机器交易。 

Human Native 和 Cloudflare 将携手合作，加速为这些新的互联网经济模型奠定基础。 

只有在开放、公平以及独立可持续的情况下，互联网才能发挥最大作用。我们很高兴欢迎 Human Native 团队加入 Cloudflare，并且更期待双方能够共同构建解决方案，改善 AI 时代的互联网基础。

继续。

人类已无法实时跟踪每一个重叠的维护请求，也无法兼顾特定于每一个客户的路由规则。我们达到了一个临界点：单靠人工监督已不足以保证，在世界某地进行的例行硬件更新不会意外地与另一地的关键路径发生冲突。

我们意识到，需要一个集中化、自动化的“大脑”来充当保障——一个能够同时洞察整个网络状态的系统。通过在 Cloudflare Workers 上构建这一调度器，我们创造了一种以编程方式强制执行安全约束的方法，确保无论我们推进速度多快，都不会牺牲客户所依赖服务的可靠性。

在这篇博客文章中，我们将解释它的构建过程，并分享目前的成果。

设想一台边缘路由器，它是连接公共互联网与某个大都市区域内众多 Cloudflare 数据中心的冗余网关小组中的一员。在人口密集的城市，我们必须确保位于这一小群路由器背后的多个数据中心不会因为所有路由器同时下线而被切断连接。

另一个维护挑战来自我们的 Zero Trust 产品 Dedicated CDN Egress IPs。它允许客户选择特定的数据中心，让用户的流量从这些数据中心离开 Cloudflare，并发送到地理位置靠近的源服务器，以实现低延迟。（为简洁起见，在本文中我们将该产品称为“Aegis”，这是它之前的名称。）如果客户所选的所有数据中心同时下线，他们将会遇到更高的延迟，甚至可能出现 5xx 错误，而我们必须避免这种情况。

我们的维护调度器解决了类似这样的问题。我们可以确保在某一区域内始终至少有一台边缘路由器处于活跃状态；并且在安排维护时，能够判断多个预定事件的组合是否会导致某客户的 Aegis 池中所有数据中心同时下线。

在创建调度器之前，这些同时发生的破坏性事件可能导致客户的服务中断。而现在，调度器会向内部运维人员提示潜在冲突，使我们能够提议新的时间，以避免与其他相关的数据中心维护事件重叠。

我们将这些运营场景（例如边缘路由器的可用性以及客户规则）定义为维护约束，这让我们能够规划更可预测且更安全的维护。

每个约束都始于一组提议的维护项目，例如一台网络路由器或一组服务器。接着，我们会查找日历中所有与提议的维护时间窗口重叠的维护事件。

然后，我们聚合各类产品 API，例如 Aegis 客户 IP 池列表。Aegis 会返回一组 IP 范围，这些范围对应客户要求从其特定数据中心 ID 发出流量的位置，如下图所示。

[
    {
      "cidr": "104.28.0.32/32",
      "pool_name": "customer-9876",
      "port_slots": [
        {
          "dc_id": 21,
          "other_colos_enabled": true,
        },
        {
          "dc_id": 45,
          "other_colos_enabled": true,
        }
      ],
      "modified_at": "2023-10-22T13:32:47.213767Z"
    },
]

在该场景中，数据中心 21 和数据中心 45 是相互关联的，因为对于 Aegis 客户 9876 来说，我们需要至少一个数据中心保持在线，以便其能够从 Cloudflare 接收出口流量。如果我们试图同时关闭数据中心 21 和 45，调度协调器就会提醒我们，该客户的工作负载将因此受到意外影响。

最初我们尝试了一个简单的方案：将所有数据加载到单个 Worker 中。这包括所有服务器关联关系、产品配置，以及用于计算约束的产品和基础设施健康指标。但只是在概念验证阶段，我们就遇到了“内存不足”的错误。

我们需要更加注意 Workers 的平台限制。这就要求仅加载处理约束业务逻辑所绝对必需的数据。如果收到德国法兰克福某台路由器的维护请求，我们几乎可以肯定不需要关心澳大利亚的情况，因为跨区域之间没有关联。因此，我们只应加载德国邻近数据中心的相关数据。我们需要一种更高效的方法来处理数据集中的关联关系。

在分析约束时，我们发现一种规律：每个约束本质上可归结为两个概念——对象与关联。在图论中，这两类组件分别称为顶点 (vertices) 和边 (edges)。对象可以是网络路由器，而关联则可以是该数据中心内要求路由器保持在线的一组 Aegis 池。我们从 Facebook 的 TAO 研究论文中获得启发，在产品与基础设施数据之上建立了一套图接口。API 示例如下：

type ObjectID = string

interface MainTAOInterface<TObject, TAssoc, TAssocType> {
  object_get(id: ObjectID): Promise<TObject | undefined>

  assoc_get(id1: ObjectID, atype: TAssocType): AsyncIterable<TAssoc>
}

核心理念在于，关联是有类型的。例如，约束会调用图接口来获取 Aegis 产品数据。

async function constraint(c: AppContext, aegis: TAOAegisClient, datacenters: string[]): Promise<Record<string, PoolAnalysis>> {
  const datacenterEntries = await Promise.all(
    datacenters.map(async (dcID) => {
      const iter = aegis.assoc_get(c, dcID, AegisAssocType.DATACENTER_INSIDE_AEGIS_POOL)
      const pools: string[] = []
      for await (const assoc of iter) {
        pools.push(assoc.id2)
      }
      return [dcID, pools] as const
    }),
  )

  const datacenterToPools = new Map<string, string[]>(datacenterEntries)
  const uniquePools = new Set<string>()
  for (const pools of datacenterToPools.values()) {
    for (const pool of pools) uniquePools.add(pool)
  }

  const poolTotalsEntries = await Promise.all(
    [...uniquePools].map(async (pool) => {
      const total = aegis.assoc_count(c, pool, AegisAssocType.AEGIS_POOL_CONTAINS_DATACENTER)
      return [pool, total] as const
    }),
  )

  const poolTotals = new Map<string, number>(poolTotalsEntries)
  const poolAnalysis: Record<string, PoolAnalysis> = {}
  for (const [dcID, pools] of datacenterToPools.entries()) {
    for (const pool of pools) {
      poolAnalysis[pool] = {
        affectedDatacenters: new Set([dcID]),
        totalDatacenters: poolTotals.get(pool),
      }
    }
  }

  return poolAnalysis
}

在上面的代码中，我们使用了两种关联类型：

1. DATACENTER_INSIDE_AEGIS_POOL，用于检索数据中心所在的 Aegis 客户池。

2. AEGIS_POOL_CONTAINS_DATACENTER，用于检索 Aegis 池为流量提供服务所需的数据中心。

这两种关联互为反向索引。访问模式与之前完全相同，但现在图实现能更好地控制查询的数据量。以前我们需要将所有 Aegis 池加载到内存中，并在约束业务逻辑里进行过滤；现在我们可以直接获取与应用相关的数据。

该接口的强大之处在于，图实现可以在后台优化性能，而不会让业务逻辑变得更复杂。这让我们可以利用 Workers 的可扩展性以及 Cloudflare CDN 的优势，从内部系统中非常快速地获取数据。

我们切换到使用新的图实现后，开始发送更具针对性的 API 请求。响应大小在一夜之间减少了 100 倍——从加载少数几个巨大的请求变为加载许多微小的请求。

虽然这解决了一次性加载过多数据导致内存不足的问题，但我们又遇到了子请求数量过多的新问题。因为现在我们不再发起少量大型 HTTP 请求，而是发起数量级更多的微小请求，结果很快就持续突破了 Workers 的子请求限制。

为了解决这个问题，我们在图实现和 fetch API 之间构建了一个智能中间件层。

export const fetchPipeline = new FetchPipeline()
  .use(requestDeduplicator())
  .use(lruCacher({
    maxItems: 100,
  }))
  .use(cdnCacher())
  .use(backoffRetryer({
    retries: 3,
    baseMs: 100,
    jitter: true,
  }))
  .handler(terminalFetch);

如果您熟悉 Go 语言，可能见过 singleflight 包。我们借鉴了这个思路，在获取管道中的第一个中间件组件实现了对正在进行的 HTTP 请求去重，让同一 Worker 内的重复请求都等待同一个 Promise 返回数据，而不是产生重复的请求。接下来，我们使用轻量级的最近最少使用 (LRU) 缓存，在内部缓存已经请求过的数据。

完成这两项操作后，我们使用 Cloudflare 的 caches.default.match 函数缓存 Worker 运行所在区域的所有 GET 请求。由于我们有多个性能特征各异的数据源，因此我们谨慎地选择生存时间 (TTL) 值。例如，实时数据仅缓存 1 分钟。相对静态的基础设施数据可以根据数据类型缓存 1 到 24 小时。电源管理数据可能需要手动更改且更改频率较低，因此我们可以将其在边缘端缓存更长时间。

除了上述层级外，我们还加入了标准的指数退避 (exponential backoff)、重试 (retries) 和抖动 (jitter) 机制。这有助于减少因下游资源临时不可用而产生的无效 fetch 调用。通过适度退避，我们提高了下一次成功获取数据的概率；反之，如果 Worker 持续不断发送请求而不退避，当源站返回 5xx 错误时很容易突破子请求限制。

综合这些措施后，我们实现了约 99% 的缓存命中率。缓存命中率是指直接从 Cloudflare 快速缓存内存（命中）返回数据的 HTTP 请求，相对于需要从控制平面数据源（未命中）发起较慢请求的百分比，计算公式为 (命中数/(命中数 + 未命中数))。高命中率意味着更好的 HTTP 请求性能和更低的成本，因为在 Worker 中从缓存查询数据的速度比从位于不同区域的源服务器获取数据快一个数量级。经过调优内存缓存和 CDN 缓存的设置后，命中率大幅提升。由于我们的工作负载很多是实时的，命中率永远达不到 100%，因为我们每分钟至少需要请求一次最新数据。

我们已经讨论了如何改进获取层，但尚未说明如何让源站的 HTTP 请求更快。我们的维护调度器需要实时响应网络降级和数据中心机器故障。为此，我们使用分布式 Prometheus 查询引擎 Thanos，将边缘的高性能指标传递到调度器中。

为了说明采用图处理接口如何影响实时查询，我们来看一个例子。要分析边缘路由器的健康状况，原本我们会发送如下查询：

sum by (instance) (network_snmp_interface_admin_status{instance=~"edge.*"})

最初，我们向存储 Prometheus 指标的 Thanos 服务请求每个边缘路由器的当前健康状况列表，并在 Worker 中手动筛选与维护相关的路由器。这种方法有很多不足之处。例如，Thanos 返回的响应大小高达数 MB，需要进行解码和编码。Worker 也需要缓存和解码这些大型 HTTP 响应，以便在处理特定维护请求时过滤掉大部分数据。由于 TypeScript 是单线程的，而解析 JSON 数据又受 CPU 限制，发送两个大型 HTTP 请求意味着一个请求会被阻塞，等待另一个请求完成解析。

现在我们改为直接使用图来查找有针对性的关联关系，例如边缘路由器与骨干路由器之间的接口链路，用 EDGE_ROUTER_NETWORK_CONNECTS_TO_SPINE 表示。

sum by (lldp_name) (network_snmp_interface_admin_status{instance=~"edge01.fra03", lldp_name=~"spine.*"})

结果平均只有 1 KB，而不是数 MB，大约缩小了 1000 倍。这也大幅降低了 Worker 内部的 CPU 消耗，因为我们把大部分反序列化工作交给 Thanos 完成。正如前面所说，这意味着我们需要发起更多的小请求，但 Thanos 前的负载平衡器可以将请求均匀分散，从而提高这种用例的吞吐量。

我们的图实现与获取管道成功控制了成千上万个微小实时请求形成的“惊群效应”(thundering herd)。不过，历史分析带来了不同的 I/O 挑战——我们不再只是获取小而具体的关联关系，而是要扫描数月的数据来发现冲突的维护窗口。过去，Thanos 会对我们的对象存储 R2 发起大量随机读取，造成巨大带宽开销。为了解决这一问题又不损失性能，我们采用了 Observability 团队今年内部开发的新方法。

我们有足够多的维护用例，必须依赖历史数据来判断我们的解决方案是否准确，以及能否随 Cloudflare 网络的扩展而扩展。我们既不想引发事故，也不希望不必要地阻碍已计划的物理维护。为了在这两个目标之间取得平衡，我们可以利用两月前甚至一年前的维护事件时间序列数据，来分析某类维护事件违反我们约束（例如边缘路由器可用性、Aegis 相关规则）的频率。今年早些时候，我们曾在博客中介绍过利用 Thanos 自动向边缘发布及回滚软件的做法。

Thanos 主要将数据查询分发到 Prometheus，但当 Prometheus 的数据保留期不足以回答查询时，就不得不从对象存储（在我们的案例中为 R2）下载数据。Prometheus 的 TSDB 块最初是为本地 SSD 设计的，依赖随机访问模式，这在迁移到对象存储后会成为瓶颈。当我们的调度器需要分析数月的维护历史数据以识别冲突约束时，从对象存储进行随机读取会带来巨大的 I/O 开销。为解决此问题，我们实现了一个转换层，将这些 TSDB 块转换为 Apache Parquet 文件。Parquet 是一种面向大数据分析的原生列式存储格式，按列而非按行组织数据，并结合丰富的统计信息，使我们可以只获取所需的部分数据。

此外，由于我们将 TSDB 块重写为 Parquet 文件，还可以按支持少量大块依序读取数据的方式存储数据。

sum by (instance) (hmd:release_scopes:enabled{dc_id="45"})

在上面的示例中，我们将选择元组“(__name__, dc_id)”作为主要排序键，以便名称为“hmd:release_scopes:enabled”且“dc_id”值相同的指标能够被排到一起。

我们的 Parquet 网关现在会发起精确的 R2 区间请求，仅提取与查询相关的特定列。这将有效载荷从数 MB 减少到数 KB。而且因为这些文件段是不可变的，我们可以在 Cloudflare CDN 上积极缓存它们。

这使 R2 变成了低延迟的查询引擎，让我们可以即时针对长期趋势回测复杂的维护场景，避免了原 TSDB 格式下的超时和高尾延迟问题。下图展示了一次近期的负载测试，结果显示在相同查询模式下，Parquet 的 P90 性能最高可达旧系统的 15 倍。

如果想深入了解 Parquet 的实现原理，可以观看 PromCon EU 2025 上的演讲 Beyond TSDB: Unlocking Prometheus with Parquet for Modern Scale。

通过利用 Cloudflare Workers，我们从一套会因内存不足而崩溃的系统，演进为一个能智能缓存数据并使用高效可观测性工具实时分析产品与基础设施数据的系统。我们构建了一个能在网络增长与产品性能之间取得平衡的维护调度器。

但“平衡”是个动态目标。

每天，我们都在全球增加更多硬件，而要确保维护过程中不打断客户流量，其逻辑复杂度会随着产品种类和维护操作类型的增多呈指数级上升。我们已经攻克了第一阶段的挑战，但现在正面对只有在如此大规模下才会显现的更微妙、更复杂的问题。

我们需要不怕难题的工程师。加入我们的基础设施团队，和我们一起构建未来吧。

2025 年 11 月 18 日，Cloudflare 网络出现严重故障，导致网络流量传输中断了大约两小时十分钟。将近三周后，在 2025 年 12 月 5 日，Cloudflare 网络再次出现故障，导致 28% 受到我们网络支持的应用程序无法访问，整个事件持续了大约 25 分钟。

虽然 Cloudflare 在两次事件发生之后已经发布了详细的事后分析博客文章，但我们深知，还需要付出更多努力才能赢回客户的信任。今天，我们将分享 Cloudflare 正在落实的各项工作的详细信息，以防止此类服务中断事件再次发生。

我们将计划命名为“橙色警报：小规模故障”，这反映了我们的目标，即：提高 Cloudflare 网络的韧性，防范可能引发重大中断事件的错误或过失。“橙色警报”表示，此项目相关工作的优先级高于一切。作为参考，Cloudflare 此前曾发布过一次“橙色警报”，因为当时发生了另一起重大事件，需要公司所有员工给予该项目最高优先级。我们认为，最近发生的事件也需要予以同等重视。“橙色警报”是我们实现这一目标的方式，让团队能够在必要时进行跨职能协作以完成相应的高优先级工作，同时暂停任何其他工作。

“橙色警报”工作分为三个主要领域：

• 对传播到网络的任何配置更改进行受控部署，就像我们目前对软件二进制版本发布所做的一样。

• 审核、改进并测试所有处理网络流量的系统的故障模式，确保这些系统在所有条件下（包括意外错误状态）均表现出明确定义的行为。

• 更改 Cloudflare 内部的“紧急访问”*规程并消除任何循环依赖关系，以便我们和客户在发生事件期间都能快速行动，并顺利访问所有系统。

我们将采取迭代改进的方式来逐步推进这些项目，而不是在项目结束时进行一次“大爆炸”式的变更。每一次单独更新都将有助于提高 Cloudflare 的韧性。最终，我们预计 Cloudflare 网络韧性将得到增强，能够更好地应对诸如过去两个月内发生的全球性事件所引发的问题。

我们理解，这些事件给 Cloudflare 客户和整个互联网社群造成了困扰。我们对此深感不安，这正是我们将这项工作列为 Cloudflare 所有员工的首要任务的原因所在。

^{*Cloudflare 的“紧急访问”规程让特定人员能够在特定情况下提高权限，执行紧急操作以解决严重问题。}

在第一次事件中，访问 Cloudflare 客户网站的用户看到了错误页面，提示 Cloudflare 无法响应其请求。在第二次事件中，用户看到了空白页面。

这两次中断都遵循相似的故障模式。在每次事件发生前的几分钟，我们都即刻在全球数百个城市的数据中心部署了配置更改。

11 月的更改是 Cloudflare 机器人管理分类器的自动更新。我们运行各种人工智能模型，这些模型学习流经 Cloudflare 网络的流量，以构建用于识别机器人的检测规则。我们不断更新这些系统，以抢先防范那些试图规避 Cloudflare 安全保护措施并访问客户网站的恶意行为者。

在 12 月的事件过程中，为了保护我们的客户免受流行的开源框架 React 中的漏洞影响，我们对安全分析师使用的一款安全工具进行了更改，以改进签名机制。与新的机器人管理更新的紧迫性类似，我们需要抢在企图利用此漏洞的攻击者之前采取行动。当时正是这项更改触发了事件。

这种模式暴露了 Cloudflare 在部署配置更改与发布软件更新方面存在的一个严重缺陷。我们以受控和受监测的方式发布软件版本更新。对于每个新的二进制版本，必须成功完成多个阶段的验证才部署，然后为全球流量提供服务。我们首先将其部署到员工流量，然后谨慎地将其推广到全球越来越多的客户，首先从免费用户开始。如果在任何阶段检测到异常，我们都可以在无需人工干预的情况下回滚版本。

我们尚未将这种方法应用于配置更改。与发布为 Cloudflare 网络提供支持的核心软件不同，进行配置更改时，我们修改的是软件行为参数值，并且可以立即生效。我们也赋予客户这种能力：如果在 Cloudflare 解决方案中更改设置，更改将在几秒钟内在全球范围内传播。

虽然这种速度具有优势，但也伴随着需要加以解决的风险。过去的两次事件表明，我们必须以对待软件版本变更同样的谨慎态度，来对待网络流量传输方式的任何更改。

两次事件的核心共同点，是我们能够在几秒钟内在全球范围内部署配置更改。在这两次事件中，错误的配置都在几秒钟内导致了 Cloudflare 网络瘫痪。

就像对软件版本已经采用的做法那样，引入受控配置部署是我们“橙色警报”计划中最重要的工作流程。

Cloudflare 配置更改会非常快速地传播至网络。当用户创建新的 DNS 记录或新的安全规则后，它会在几秒钟内到达网络上 90% 的服务器。这由我们内部称为 Quicksilver 的软件组件提供支持。

Quicksilver 也用于我们内部团队所需的任何配置更改。速度是其优势：我们可以非常快速地响应并全局更新 Cloudflare 网络行为。然而，在这两次事件中，这都导致破坏性更改在几秒钟内传播到了整个网络，而没有经过任何测试环节进行验证。

虽然可以近乎即时地将更改部署到网络的功能在许多情况下都很有用，但很少需要使用这项功能。我们正在努力以相同的方式处理配置管理与代码管理，具体方法是在 Quicksilver 中引入受控部署机制来管理任何配置更改。

我们每天通过内部称之为“运行状况调解部署”（Health Mediated Deployment，简称 HMD）的系统，多次向 Cloudflare 网络发布软件更新。在此框架下，Cloudflare 旗下拥有服务（部署于 Cloudflare 网络中的软件）的每个团队都必须定义用于衡量部署成功或失败的各项指标、发布计划，以及部署失败时应该采取的步骤。

不同的服务拥有略微不同的变量。有些服务可能需要更长的等待时间，才能继续发送到更多数据中心；而另一些服务可能对错误率的容忍度较低，即使这会导致误报。

部署完成后，HMD 工具包将开始根据计划谨慎地推进部署流程，并监测每个步骤，然后继续下一步。如果任何步骤失败，则系统会自动启动回滚，并且可以根据需要，通知相关团队。

在橙色警报结束时，配置更新将遵循相同的流程。我们希望，这种做法让我们能够快速发现过去这两次事件中出现的类似问题，并在这些问题演变成普遍问题之前予以解决。

虽然我们乐观地认为，加强对配置更改的控制可以帮助我们在问题演变成事件之前及时发现这些问题，但我们知道，错误仍然会不可避免地发生。在这两次事件中，Cloudflare 网络的一部分错误演变成了大部分技术栈问题，包括客户用于配置其 Cloudflare 解决方案使用方式的控制平面。

我们需要思考如何谨慎、分阶段地推出，不仅要考虑地理区域的扩展（扩展到更多数据中心），而且还要考虑用户群体的扩展（扩展到各种不同的员工和客户类型）。我们还需要规划提高部署的安全性，以防止故障从一项服务（例如，Cloudflare 机器人管理服务）蔓延到另一项不相关的服务（例如，Cloudflare 仪表板）。

为此，我们正在审核构成 Cloudflare 网络的每个关键产品和服务的接口合同，以确保：a) 假设每个接口之间会发生故障，以及 b) 尽量以最合理的方式处理这些故障。 

回到 Cloudflare 机器人管理服务故障事件，至少有两个关键接口，如果我们当时假设这些接口会发生故障，便可以从容不迫地处理，客户原本也不太可能受到影响。第一个故障点是读取已损坏配置文件的接口。我们不应陷入恐慌，而应该设置一组合理的、经过验证的默认值，以便让流量流经 Cloudflare 网络，而即使在最坏的情况下，我们也只会丢失用于机器人检测机器学习模型的实时微调数据。 第二个接口位于运行 Cloudflare 网络的核心软件与机器人管理模块之间。如果机器人管理模块发生故障（正如实际事件中发生的那样），我们不应该默认丢弃流量。相反，我们可以再次设置一个更合理的默认值，让流量以尚可接受的分类流经 Cloudflare 网络。

在之前的事件中，我们花费了过长时间来解决问题。在这两次事件中，我们的安全系统都阻止了团队成员访问其所需的工具来解决问题，这使得情况变得更加糟糕；在某些情况下，循环依赖关系拖慢了我们的速度，因为一些内部系统也变得不可用。

作为一家安全公司，我们所有的工具都受到了身份验证层的保护，并且配备了精细化访问控制，以确保客户数据安全并防止未经授权的访问。这种做法是正确的，但与此同时，在速度至关重要的情况下，现有流程和系统却拖慢了我们的处理速度。

循环依赖关系也影响了我们的客户体验。例如，在 11 月 18 日的事件中，我们的无验证码机器人解决方案 Turnstile 变得无法使用。由于 Cloudflare 仪表板的登录流程中使用了 Turnstile，因此，在最需要进行关键更改时，没有活动会话或 API 服务令牌的客户无法登录 Cloudflare。

Cloudflare 团队将审核并改进所有紧急访问规程和技术，以确保在必要时，我们能够以最快的速度访问适当的工具，同时维持我们的安全要求。这包括检查和消除循环依赖关系，或者在发生事件后能够快速“绕过”这些依赖关系。我们还将提高培训演习的频率，以便所有团队都能够充分理解相关流程，做好应对未来可能会发生的任何潜在灾难情况的准备。

虽然这篇文章并未涵盖 Cloudflare 正在进行的所有内部工作，但上述工作流程描述了公司要求内部团队关注的首要优先事项。每个工作流程对应一个详细的计划，几乎涉及 Cloudflare 的所有产品和工程团队。我们还有很多工作要做。

到第一季度末，并且很大程度上在此之前，我们将：

• 确保所有生产系统都采用“运行状况调解部署”(HMD) 进行配置管理。

• 根据每个产品集的故障模式，适当地更新相应的系统。

• 确保已制定相应的流程，以便在紧急情况下，合适的人员能够获得适当的访问权限来执行适当的补救措施。

其中一些目标将会是持续性的长期目标。随着不断推出新软件，我们始终需要更好地处理循环依赖关系，并且我们也需要更新紧急访问规程，以体现 Cloudflare 安全技术随着时间的推移而发生的变化。

在过去的两次事件中，我们辜负了用户和整个互联网社群的期望。我们必须努力加以改正。我们计划在推动此项工作的过程中适时分享最新进展，同时真诚地感谢客户和合作伙伴提出的问题与反馈。

在处理大量数据时，快速获取概览是非常有帮助的——这正是 SQL 中的聚合所提供的功能。聚合，也被称为“GROUP BY 查询”，能提供鸟瞰式的视角，让您能迅速从海量数据中获得洞察。

正因如此，我们非常激动地宣布：R2 SQL 现已支持聚合功能。R2 SQL 是 Cloudflare 推出的无服务器、分布式分析查询引擎，能够对存储在 R2 Data Catalog 中的数据进行 SQL 查询。聚合功能将帮助 R2 SQL 用户发现数据中的重要趋势与变化、生成报告，并在日志中找出异常。

此次发布基于已支持的过滤查询功能，后者是分析工作负载的基础，允许用户在 Apache Parquet 文件的大量数据中找到所需的信息。

在本文中，我们将详细介绍聚合功能的用途和特点，然后深入探讨我们如何扩展 R2 SQL 以支持在存储在 R2 Data Catalog 中的海量数据上运行此类查询。

聚合也称为“GROUP BY 查询”，可以生成底层数据的简要汇总。

一个常见的聚合用例是生成报告。假设有一个名为“sales”的表，其中包含某组织在各个国家/地区和部门的历史销售数据。我们可以使用如下聚合查询轻松生成按部门统计的销售报告：

SELECT department, sum(value)
FROM sales
GROUP BY department

我们可以使用“GROUP BY”语句，将表中的行划分为多个存储桶。每个存储桶都有一个标签，对应一个特定部门。当所有行被划分进各自的存储桶后，我们就可以对每个存储桶中的所有行计算“sum(value)”，从而得到该部门的总销售量。

对于某些报告，我们可能只关心销售量最高的部门。这时，“ORDER BY”语句就派上用场了：

SELECT department, sum(value)
FROM sales
GROUP BY department
ORDER BY sum(value) DESC
LIMIT 10

这里我们指示查询引擎按照各部门的总销售量降序排列，并仅返回前 10 个销售量最高的部门。

最后，我们有时可能希望过滤掉异常数据。例如，我们只想在报告中包含总销售量大于 5 的部门。我们可以轻松地通过“HAVING”语句实现这一点：

SELECT department, sum(value), count(*)
FROM sales
GROUP BY department
HAVING count(*) > 5
ORDER BY sum(value) DESC
LIMIT 10

我们在查询中添加了一个新的聚合函数“count(*)”，它用于计算每个存储桶中有多少行。这直接对应于该部门的销售次数，因此我们也在“HAVING”子句中添加了一个条件，确保只保留那些行数大于 5 的存储桶。

聚合查询有一个有趣的特性：它们可以引用并不实际存在于原始数据中的列。以“sum(value)”为例：这个列是由查询引擎在运行时动态计算出来的，而像“department”这样的列则是直接从存储在 R2 上的 Parquet 文件中读取的。这个细微差别意味着，任何引用了如“sum”、“count”等聚合函数的查询，都需要分成两个阶段来处理。

第一阶段是计算新列。如果我们要使用“ORDER BY”语句按“count(*)”列对数据进行排序，或使用“HAVING”语句基于该列过滤行，我们需要知道该列的值。一旦知道“count(*)”等列的值，我们就可以继续执行查询的其余部分。

请注意，如果查询在“HAVING”或“ORDER BY”子句中没有引用聚合函数，但仍在“SELECT”子句中使用它们，我们可以使用一种技巧。由于我们直到最后才需要聚合函数的值，因此我们可以部分计算它们，并在准备向用户返回结果之前再合并结果。

这两种方法之间的关键区别在于我们何时计算聚合函数：是提前算好，以便后续做更多处理；还是按需即时计算，边处理边构建最终结果。

首先，我们来探讨“即时构建结果”的方式——我们称之为“分散-聚集聚合”(scatter-gather aggregations)。接着在此基础上，我们会介绍“洗牌式聚合”(shuffling aggregations)，它支持在聚合函数之上执行额外的操作，例如“HAVING”和“ORDER BY”。

没有使用“HAVING”和“ORDER BY”子句的聚合查询能够以类似于过滤查询的方式执行。对于过滤查询，R2 SQL 会选择一个节点作为查询执行的协调节点。该节点分析查询内容，并查阅 R2 Data Catalog，以确定哪些 Parquet 行组可能包含与查询相关的数据。每一个 Parquet 行组代表一个相对较小的任务单元，可由单个计算节点处理。协调节点将任务分发给多个工作节点，收集结果并返回给用户。

为了执行聚合查询，我们遵循相同的步骤，将小任务分发给工作节点。但这一次，工作节点不仅要依据 WHERE 子句中的条件过滤行，还要计算“预聚合”(pre-aggregates)。

预聚合是聚合过程的中间状态。它是对一部分数据做部分聚合后的不完整结果。多个预聚合可以被合并，以计算出聚合函数的最终值。将聚合函数拆分为多个预聚合，使我们可以水平扩展聚合计算，充分利用 Cloudflare 网络中的庞大计算资源。

例如，“count(*)”的预聚合结果就是一个数字，代表数据子集中行的数量。计算最终的“count(*)”就像将这些数字相加一样简单。“avg(value)”的预聚合结果包含两个数字：“sum(value)”和“count(*)”。然后，可以通过将所有“sum(value)”值相加，将所有“count(*)”值相加，最后将第一个数字除以第二个数字来计算“avg(value)”的值。

当工作节点完成预聚合的计算后，会将结果流式传输给协调节点。协调节点收集所有结果，根据预聚合计算出聚合函数的最终值，并将最终结果返回给用户。

当协调节点可以通过合并来自各个工作节点的小型、部分状态来计算最终结果时，分散-聚合的方式非常高效。如果您执行类似 SELECT sum(sales) FROM orders 这样的查询，协调节点会从每个工作节点收到一个单一数值并相加。无论 R2 中存储了多少数据，协调节点的内存占用都可以忽略不计。

然而，当查询需要根据聚合结果进行排序或过滤时，这种方式就会变得低效。考虑下面这个查询——它用于找出销售额最高的前两个部门：

SELECT department, sum(sales)
FROM sales
GROUP BY department
ORDER BY sum(sales) DESC
LIMIT 2

要正确确定全局的前 2 名，需要知道整个数据集中每个部门的销售总额。由于数据在底层 Parquet 文件中是随机分布的，某个特定部门的销售记录很可能分散在许多不同的工作节点上。一个部门在每个单独的工作节点上的销售额可能都很低，因此不会进入任何本地的“前 2”列表，但在全局汇总后却可能是销售额最高的部门。

下图展示了分散-聚合方法为何不适用于此查询。“Dept A”是全球销售额冠军，但由于它的销售记录均匀分布在多个工作节点上，它没有进入某些本地的前 2 列表，最终被协调节点丢弃。

因此，当查询按全局聚合结果排序时，协调节点无法依赖来自工作节点的预筛选结果。它必须向每个工作节点请求每个部门的销售总额，以便在计算全局总数后进行排序。如果按高基数列（如 IP 地址或用户 ID）进行分组，这就会迫使协调节点接收并合并数百万行数据，从而在单个节点上造成资源瓶颈。

为了解决这个问题，我们需要引入洗牌 (shuffling)——一种在最终聚合发生之前，将特定分组的数据重新聚集到一起的方法。

为了解决数据随机分布带来的挑战，我们引入了一个洗牌阶段。工作节点不再将结果发送给协调节点，而是直接相互交换数据，根据分组键将行数据进行归类。

这种路由依赖于确定性哈希分区。当工作节点处理一行数据时，它会对 GROUP BY 列进行哈希计算，以确定目标工作节点。由于该哈希是确定性的，集群中的每个工作节点都能独立地就特定数据应发送到哪里达成一致。例如，如果“Engineering”的哈希值指向工作节点 5，那么所有工作节点都知道应将“Engineering”相关的行路由到工作节点 5。无需中央注册表。

下图展示了这一流程。注意“Dept A”最初位于工作节点 1、2 和 3 上。因为哈希函数将“Dept A”映射到工作节点 1，所有工作节点都会将这些行路由到同一个目标节点。

洗牌聚合能够产生正确的结果。然而，这种“全部对全部”(all-to-all) 的数据交换会引入时序依赖。如果工作节点 1 在工作节点 3 尚未完成发送其“Dept A”数据份额时就提前开始计算最终总额，那么结果将是不完整的。

为了解决这个问题，我们强制执行严格的同步屏障。协调节点跟踪整个集群的进度，而工作节点则缓冲它们的输出数据，并通过 gRPC 流刷新到对等节点。只有当每个工作节点确认已完成输入文件的处理并已刷新完洗牌缓冲区时，协调节点才会发出继续执行的命令。这一屏障保证在进入下一阶段时，每个工作节点上的数据集都是完整且准确的。

一旦同步屏障解除，每个工作节点都持有其被分配组的完整数据集。此时，工作节点 1 拥有“Dept A”100% 的销售记录，并能确定地计算出最终总额。

这使得我们可以将过滤、排序等计算逻辑下推到工作节点执行，而不必让协调节点承担这些负担。例如，如果查询包含 HAVING count(*) > 5，工作节点可以在聚合完成后立即过滤掉不满足该条件的分组。

在此阶段的末尾，每个工作节点会为它所负责的分组生成一个已排序的最终结果流。

最后一块拼图是协调节点。在分散-聚合模型中，协调节点需要承担对整个数据集进行聚合与排序的高开销任务。而在洗牌模型中，它的角色发生了变化。

由于工作节点已经在本地计算出了最终的聚合结果并完成了排序，协调节点只需执行一次 k 路归并 (k-way merge)。它会为每个工作节点打开一个数据流，逐行读取结果；比较每个工作节点当前行的排序值，根据排序规则选出“胜出者”，并将其加入即将返回给用户的最终查询结果中。

这种方法对于 LIMIT 查询尤其高效。如果用户请求前 10 个部门，协调节点会在归并过程中找到前 10 条记录后立即停止处理，而无需加载或归并剩余的数百万行数据。这样可以在不大量消耗计算资源的前提下，支持更大规模的操作。

随着聚合功能的加入，R2 SQL 从一个擅长过滤数据的工具，转变为能够在海量数据集上进行数据处理的强大引擎。这得益于我们实现了诸如“分散-聚合”与“洗牌”等分布式执行策略，使我们能够将计算推送到数据存储的位置，充分利用 Cloudflare 的全球计算与网络规模。

无论您是要生成报表、监控大批量日志以发现异常，还是仅仅想从数据中洞察趋势，现在都可以在 Cloudflare 开发人员平台内轻松完成这一切，而无需承担管理复杂 OLAP 基础设施的开销，也不必将数据移出 R2。

R2 SQL 的聚合功能现已可用。我们非常期待看到您使用这些新功能处理 R2 Data Catalog 中的数据。

• 快速开始：请查看我们的文档，获取运行聚合查询的示例与语法指南。

• 加入讨论：如果您有任何问题、反馈，或想要分享您正在构建的项目，欢迎加入 Cloudflare 开发人员 Discord 与我们交流。

我们的视角之所以独特，是因为 Cloudflare 的全球网络在超过 125 个国家/地区的 330 座城市设有节点，平均每秒处理超过 8100 万次 HTTP 请求，峰值期间每秒为数百万客户网站代处理超过 1.29 亿次 HTTP 请求；此外，还每秒响应约 6700 万次（权威 + 解析器）DNS 查询。Cloudflare Radar 利用这些 Web 和 DNS 服务产生的数据，结合其他互补数据集，提供近乎实时的洞察，展现我们在互联网上观察到的流量、机器人、安全、连接性以及 DNS 的模式与趋势。

我们的《Radar 年度回顾》利用了这种可观测性，但并非提供实时视图，而是回顾 2025 年：其中包含交互式图表、图形和地图，让您可以探索和比较选定的趋势和指标，并进行年度和跨地域的比较，还可以分享和嵌入年度回顾图表。

《2025 年度回顾》报告分为六个部分：流量、AI、采用与使用情况、连接性、安全性和电子邮件安全，数据涵盖 2025 年 1 月 1 日至 12 月 2 日期间。为确保一致性，我们沿用了与往年相同的计算方法。今年我们还纳入了一些新的数据集，包括多项与 AI 相关的指标、全球速度测试活动和超流量 DDoS 攻击规模演变。微型网站上提供超过 200 个国家/地区的趋势；但由于数据不足，不包括面积较小或人口较少的地区。某些指标仅显示全球范围的概况，如果选择某个国家/地区，则不会显示任何信息。

在这篇文章中，我们将重点介绍年度回顾微型网站主要版块的关键发现和有趣观察，此外，我们还发布了一篇配套的《最受欢迎的互联网服务》博客文章，专门探讨了主要互联网服务的趋势。

诚挚建议您访问 2025 年度回顾专题网站，以更详细地了解数据集和指标，包括您所在国家/地区的数据，看看自 2024 年以来这些数据发生了哪些变化，以及它们与其他相关地区的数据有何不同。

我们希望《年度回顾》对您而言是一份富有洞察力且功能强大的工具，它可以帮助您探索定义 2025 年互联网的颠覆性变革、技术进步和关键指标。

我们来深入了解一下。

• 2025 年全球互联网流量增长了 19%，从 8 月份开始出现显著增长。➜

• 排名前十位的热门互联网服务较去年发生了一些变化，同时也有一些新服务进入了各个类别的榜单。➜

• 2025 年，Starlink 的网络流量翻了一番，其中包括来自 20 多个新国家/地区的流量。➜

• 2025 年，Googlebot 再次成为 Cloudflare 请求流量的最大来源，因为它抓取了数百万个 Cloudflare 客户网站，用于搜索索引和 AI 训练。➜

• 人类生成的 Web 流量中采用后量子加密的比例已增长到 52%。➜

• Googlebot 占经验证机器人流量的四分之一以上。➜

• 来自双用途 Googlebot 的抓取量远远超过其他 AI 机器人和爬网程序。➜

• 2025 年，AI“用户行为”抓取量增长超过 15 倍。➜

• 其他 AI 机器人占 HTML 请求流量的 4.2%，而仅 Googlebot 就占了 4.5%。➜

• 在主要 AI 与搜索平台中，Anthropic 的抓取-引荐比最高。➜

• AI 爬网程序是在 robots.txt 文件中被完全禁止次数最多的用户代理。➜

• 在 Workers AI 上，Meta 的 llama-3-8b-instruct 模型最受欢迎，文本生成则是最常用的任务类型。➜

• iOS 设备贡献了全球移动设备流量的 35%，在许多国家/地区，这一比例超过一半。➜

• 2025 年，使用 HTTP/3 与 HTTP/2 的全球网页请求占比均略有上升。➜

• 基于 JavaScript 的库与框架仍是构建网站的核心工具。➜

• 五分之一的自动化 API 请求来自基于 Go 语言的客户端。➜

• Google 依旧是全球第一大搜索引擎，排名其后的 Yandex、Bing 和 DuckDuckGo 与其差距明显。➜

• Chrome 在各大平台和操作系统上仍保持浏览器榜首地位——但在 iOS 上，Safari 的市场份额最大。➜

• 2025 年全球观测到的 174 起重大互联网中断事件中，近半数源于政府主导的地区性或全国性断网。➜

• 在全球范围内，通过 IPv6 发出的双栈请求不到三分之一，而在印度，这一比例超过了三分之二。➜

• 欧洲多国的下载速度位居全球前列，全部超过 200 Mbps。西班牙在多项互联网质量指标的测评中始终位列前茅。➜

• 伦敦和洛杉矶是 2025 年 Cloudflare 速度测试活动的热点城市。➜

• 在 117 个国家/地区中，超过一半的请求流量来自移动设备。➜

• 通过 Cloudflare 网络传输的全球流量中，有 6% 的流量被我们的系统缓解，原因包括被判定为潜在恶意流量或出于客户定义的特定原因。➜

• 全球机器人流量的 40% 来自美国，其中 Amazon Web Services 和 Google Cloud 合计贡献了全球机器人流量的四分之一。➜

• 2025 年，“人与社会”领域的组织遭受最多攻击。➜

• 路由安全性（以 RPKI 有效路由占比及覆盖的 IP 地址空间衡量）在 2025 年持续改善。➜

• 全年超流量 DDoS 攻击的规模显著增长。➜

• Cloudflare 分析的邮件中，超过 5% 被判定为恶意邮件。➜

• 恶意邮件中最常见的威胁类型包括：欺骗性链接、身份冒充与品牌仿冒。➜

• 来自 .christmas 与 .lol 顶级域的邮件几乎全部被识别为垃圾邮件或恶意邮件。➜

为了确定年度回顾这段时间内的流量趋势，我们将 2025 年第二个完整日历周（也就是 1 月 12 日至 18 日）的平均每日流量（不包括机器人流量）作为基准。（之所以使用第二个日历周，是因为考虑人们在寒假和元旦假期后有时间恢复到“正常”的学习和工作节奏。）流量趋势图表中显示的百分比变化均根据基准值计算，它并不代表某个国家/地区的绝对流量。趋势线表示七日滞后平均值，用于平滑每日精细化层面数据的急剧变化。

2025 年的流量增长似乎分为几个阶段。整体来看，流量在 4 月中旬之前基本持平，通常在基准值的几个百分点范围内波动。然而，从 5 月开始出现增长，达到比基准高出约 5%，并在 8 月中旬前保持在 +4% 至 +7% 之间。就在此后，增长速度加快，在 9 月、10 月和 11 月稳步上升，年底时达到全年最高增长 19%。在 11 月底的一次增长推动下，2025 年的增长率比 2024 年观察到的 17% 高出约 10%。在过去几年中，我们也观察到流量增长在后半年加速，尽管在 2022 至 2024 年间，这种加速始于 7 月。目前尚不清楚为何今年的增长似乎推迟了几周。

^{2025 年全球互联网流量趋势}

博茨瓦纳的峰值增长最高，在 11 月 8 日达到比基准高出 298%，并在年末时高出基准 295%。（有关该增长原因的更多信息，请参见下面的 Starlink 部分。）博茨瓦纳和苏丹是唯二在一年内增长超过一倍的国家/地区，不过还有一些其他国家/地区的流量在一年中的某个时间点也出现了超过 100% 的峰值增长。

^{2025 年博茨瓦纳互联网流量趋势}

长时间互联网中断的影响在图表中也清晰可见。例如，10 月 29 日，坦桑尼亚政府因选举日抗议活动在该国实施互联网关闭。这次关闭仅持续一天，但随后从 10 月 30 日到 11 月 3 日又发生了另一次关闭。尽管在关闭前该国流量已比基准高出逾 40%，但中断最终导致流量骤降至比基准低 70% 以上——出现了急剧反转。连接性恢复后，流量迅速回升。牙买加也出现了类似模式：在 10 月 28 日飓风“梅丽莎”(Melissa) 来临前，互联网流量激增，随后风暴造成岛上停电和基础设施损坏，导致流量大幅下降。风暴过境后，流量开始恢复，到 12 月初已回升至略高于基准的水平。

^{2025 年坦桑尼亚互联网流量趋势}

^{2025 年牙买加互联网流量趋势}

在年度回顾中，我们关注截至目前的 11 个月数据。除了“总体”排名之外，我们还根据对全球数百万用户访问我们 1.1.1.1 公共 DNS 解析器的匿名查询数据分析，对九个类别的服务进行了排名。出于排名的目的，我们将属于单一互联网服务提供商的域名都归为同一组。

Google 和 Facebook 再次位居前十名榜单的前两位。尽管前十名榜单中的其他成员与 2024 年的排名保持一致，但中间位置的排名有所变动。Microsoft、Instagram 和 YouTube 的排名均有所上升；Amazon Web Services (AWS) 下降了一位，而 TikTok 则下降了四位。

^{2025 年全球主要互联网服务}

在生成式 AI 服务中，ChatGPT/OpenAI 依然位居榜首。但其他位置出现变动，体现出这一领域的活跃发展。排名上升的服务包括 Perplexity、Claude/Anthropic 以及 GitHub Copilot。2025 年前十名的新晋者包括 Google Gemini、Windsurf AI、Grok/xAI 和 DeepSeek。

^{2025 年全球主要生成式 AI 服务}

其他类别榜单中也出现了内部排名变化——Shopee（“东南亚及台湾地区领先的电子商务在线购物平台”）首次进入电子商务榜单，HBO Max 也加入了视频流媒体排名。这些分类排名以及特定服务的发展趋势，将在另一篇博文中更详细地探讨。

此外，今年我们还首次提供了国家/地区层面的“总体”、“生成式 AI”、“社交媒体”和“即时通讯”类别的热门互联网服务洞察。（2024 年仅分享了“总体”数据。）

SpaceX 的 Starlink 卫星互联网服务仍然是为服务不足或未覆盖地区以及飞机和船只上的用户提供网络连接的热门选择。我们分析了与 Starlink 的主要自治系统 (AS14593) 相关的请求总流量，以跟踪 2025 年全年 Starlink 服务使用量的增长情况。图表中趋势线所示的请求量代表七天移动平均值。

2025 年全年，Starlink 的全球流量持续增长，总请求量同比增长了 2.3 倍。每当 Starlink 服务进入一个新国家/地区时，我们通常都会看到流量的迅速增长，这一趋势在 2025 年仍在延续。

^{2025 年 Starlink 全球流量增长}

这正是我们在 @Starlink 宣布提供服务的 20 多个新国家/地区所看到的：几天之内，这些地区的 Starlink 网络流量迅速增长。其中包括亚美尼亚、尼日尔、斯里兰卡和圣马丁岛。

我们还观察到一些目前尚未宣布提供服务地区的 Starlink 流量。然而，Starlink 发布的地理位置信息中包含与这些国家相关的 IPv4 和/或 IPv6 前缀。考虑到 Starlink 用户可以漫游使用其服务（和设备），这些流量可能来自这些地区的漫游用户。

^{2025 年尼日尔的 Starlink 流量增长}

在 2025 年前已经开通服务的国家/地区中，贝宁、东帝汶和博茨瓦纳的流量增长最为显著，分别增长了 51 倍、19 倍和 16 倍。Starlink 服务于 2023 年 11 月首次宣布在贝宁提供服务，2024 年 12 月宣布在东帝汶提供服务，以及 2024 年 8 月宣布在博茨瓦纳提供服务。

^{2025 年博茨瓦纳的 Starlink 流量增长}

类似的服务，例如 Amazon Leo、Eutelsat Konnect 和中国的“千帆”，也在继续扩大其卫星星座并逐步实现商业化。我们希望未来也能对这些服务的流量增长进行分析。

为了查看 Cloudflare 在 2025 年从整个 IPv4 互联网接收到的总请求流量，我们可以使用希尔伯特曲线，它让我们能够实现 IPv4 地址序列的二维可视化，使附近的 IP 地址彼此靠近，从而让这些地址可用于调查互联网 IPv4 地址空间。在可视化图表中，我们将 IPv4 地址聚合为 /20 前缀，这意味着在最高缩放级别下，每个方块代表来自 4096 个 IPv4 地址的流量。这种聚合方式有助于控制可视化所需的数据量。有关可视化的更多细节可参见我们《2024 年度回顾》博客文章。

连续第三年，2025 年向 Cloudflare 发出最多请求流量的 IP 地址段是 Google 的 66.249.64.0/20——这是 Googlebot Web 爬网程序用于检索网页内容以进行搜索索引和 AI 训练的多个地址段之一。鉴于 Cloudflare 网络上托管的网络内容数量庞大，以及 Googlebot 的高强度爬取活动，这个 Googlebot 地址段再次成为最大请求流量来源并不令人意外。该 Googlebot 前缀产生的 IPv4 请求流量，几乎是第二大流量源（146.20.240.0/20，属于 Rackspace Hosting 所通告的大范围 IPv4 地址段）的四倍。作为一家云服务和托管服务提供商，Rackspace 支持多种客户和应用程序类型，因此我们尚不清楚其向 Cloudflare 发出流量的具体驱动原因。

^{希尔伯特曲线放大视图，显示在 2025 年产生最大请求量的地址块}

今年，我们为可视化工具新增了按自治系统 (ASN) 搜索的功能，让用户可以查看某网络提供商的 IP 地址在 IPv4“宇宙”中的分布广度。

一个例子是 AS16509（AMAZON-02，用于 AWS），它展示了 Amazon 多年来收购大量 IPv4 地址空间的结果。另一个例子是 AS7018（ATT-INTERNET4，AT&T），它是美国境内最大的 IPv4 地址通告者之一。我们从该 ASN 看到的流量大部分来自 12.0.0.0/8，这是一个包含超过 1600 万个 IPv4 地址的地址块，自 1983 年以来一直归 AT&T 所有。

^{希尔伯特曲线图，显示在 2025 年向 Cloudflare 发送了流量且来自 AS7018 的 IPv4 地址块}

“后量子”指一系列旨在保护加密数据免受“先收集、后解密”攻击的加密技术。这些攻击的攻击者能够捕获并存储当前数据，以便将来使用足够先进的量子计算机进行解密。Cloudflare 研究团队自 2017 年以来一直致力于后量子密码学的研究，并定期发布关于后量子互联网发展现状的最新进展。

继 2024 年显著增长之后，2025 年全球后量子加密流量占比几乎翻了一番，从年初的 29% 增长到 12 月初的 52%。

^{2025 年全球后量子加密 TLS 1.3 流量增长}

今年，28 个国家/地区的后量子加密流量占比增加了一倍以上，其中波多黎各和科威特增长显著。科威特的后量子流量占比从 13% 提升至近 37%，增长了近两倍；波多黎各则从 20% 增长到 49%。

这三个国家/地区与其他一些国家/地区一起，在 9 月中旬出现后量子流量占比大幅增长，恰逢 Apple 发布操作系统更新，其中说明：“TLS 保护的连接将自动声明支持 TLS 1.3 中的混合式量子安全密钥交换。”在科威特和波多黎各，超过一半的请求流量来自移动设备，而其中约有一半又来自 iOS 设备，因此这一软件更新导致后量子流量占比大幅上升也就不足为奇了。

^{2025 年波多黎各后量子加密 TLS 1.3 流量增长}

正因如此，在 iOS 26 正式发布后，来自 Apple iOS 设备的后量子加密流量占比在 9 月份显著上升。发布仅四天后，iOS 设备发起的带有后量子支持的请求流量在全球的占比从不到 2% 跃升至 11%。截至 12 月初，来自 iOS 设备的请求中有超过 25% 使用了后量子加密。

Cloudflare Radar 上新推出的“机器人目录”提供了有关“经验证机器人”和“签名代理”的大量信息，包括其运营方、类别、相关用户代理、文档链接以及流量趋势等。“经验证机器人”必须符合一系列要求，并通过 Web Bot Auth 或 IP 验证方式进行身份验证。“签名代理”则由终端用户控制，并通过其 Web Bot Auth 实现获得已验证签名，且需满足另一套单独的要求。

Googlebot 用于抓取网站内容进行搜索索引和 AI 训练，它是 Cloudflare 在 2025 年观察到的最活跃的机器人。它在 2 月中旬至 7 月中旬期间最为活跃，并在 4 月中旬达到峰值，占经验证机器人流量的 28% 以上。其他流量较大的 Google 运营机器人包括 Google AdsBot（用于监控投放 Google 广告的网站）、Google Image Proxy（用于检索和缓存电子邮件中嵌入的图像）和 GoogleOther（由各种产品团队用于从网站获取可公开访问的内容）。

OpenAI 的 GPTBot 是用于 AI 训练内容抓取的机器人，位列第二，占经验证机器人流量的约 7.5%。其抓取活动在今年上半年波动较大。Microsoft 的 Bingbot 同样用于搜索索引和 AI 训练的内容抓取，全年贡献了 6% 的经验证机器人流量，活动相对稳定。

^{2025 年全球经验证机器人流量趋势}

搜索引擎爬网程序和 AI 爬网程序是最活跃的两个经验证机器人类别，其流量模式与这些类别中的主要机器人（包括 GoogleBot 和 OpenAI 的 GPTBot）的流量模式密切相关。搜索引擎爬网程序占经验证机器人流量的 40%，而 AI 爬网程序的流量是其一半 (20%)。搜索引擎优化机器人也相当活跃，占经验证机器人请求的 13% 以上。

^{2025 年全球经验证机器人流量趋势（按类别划分）}

今年 9 月，Cloudflare 在一篇博客文章中提出了“负责任的 AI 机器人原则”，其中之一是：“AI 机器人应有明确且单一的目的，并对外声明。”在 Radar 平台的 AI 机器人最佳实践概览中，我们注意到包括 Google 和 Microsoft 在内的多家机器人运营商都使用双用途的爬网程序。

由于 Googlebot 抓取的内容既用于搜索引擎索引，也用于 AI 模型训练，因此我们将其纳入了今年的 AI 爬网程序概览。在 2025 年，其抓取量远超其他主流 AI 机器人。请求流量从 2 月中旬开始上升，4 月底达到峰值，随后在 7 月底之前缓慢下降。之后，抓取量逐步回升，直至年底。Bingbot 同样具有双重目的，但其爬取量仅为 Googlebot 的一小部分。Bingbot 的抓取活动全年总体呈上升趋势。

^{2025 年全球 AI 爬网程序流量趋势}

OpenAI 的 GPTBot 用于抓取可能用于训练其生成式 AI 基础模型的内容。其抓取活动在全年波动较大，6 月达到最高水平，但 11 月底的抓取量仅略高于年初。

OpenAI ChatGPT-User 的抓取量全年持续增长，该爬网程序会在用户向 ChatGPT 或 CustomGPT 提问时访问网页。从 2 月中旬开始，其每周使用模式变得更加明显，这表明学校和工作场所的使用量正在增加。峰值请求量比年初高出 16 倍。6 月至 8 月期间，由于许多学生放假，许多专业人士休假，活动量也明显下降。

OAI-SearchBot 用于在 ChatGPT 的搜索功能中链接和显示网站，其抓取活动在 8 月份之前逐渐增长，然后在 8 月和 9 月出现几次流量峰值，之后在 10 月份开始更快速增长，10 月下旬的峰值请求量约为年初的 5 倍。

^{2025 年全球 OpenAI 爬网程序流量趋势}

Anthropic 的 ClaudeBot 抓取量在上半年翻了一番，但在下半年逐渐下降，最终回到比年初高约 10% 的水平。Perplexity 的 PerplexityBot 抓取量在 1 月和 2 月缓慢增长，但从 3 月中旬到 4 月出现大幅跃升。此后至 10 月增长较为平稳，11 月再次显著上升，最终达到年初水平的约 3.5 倍。

^{2025 年全球 ClaudeBot 流量趋势}

^{2025 年全球 PerplexityBot 流量趋势}

ByteDance 的 Bytespider 是 2024 年的主要 AI 爬网程序之一，但 2025 年的抓取量低于多个其他训练型机器人，并且全年活动持续下降，延续了去年的下滑趋势。

大多数 AI 机器人抓取数据主要用于三个目的：训练，即收集网站内容用于 AI 模型训练；搜索，即索引网站内容以用于 AI 平台上的搜索功能；以及用户行为，即响应用户向聊天机器人提出的问题而访问网站。值得注意的是，搜索抓取也可能包括用于检索增强生成 (RAG) 的抓取，该功能让内容所有者无需重新训练或微调模型即可将自己的数据引入 LLM 生成。（第四个“未声明”目的涵盖了抓取目的不明确或未知的 AI 机器人流量。）

用于模型训练的抓取量占 AI 爬网程序流量的绝大多数，峰值时可达到搜索抓取量的 7-8 倍，用户行为抓取量的 32 倍。训练流量数据受 OpenAI GPTBot 的影响很大，因此，其全年走势与 GPTBot 非常相似。

用于搜索的抓取量在 3 月中旬之前最为强劲，之后下降了约 40%。此后，增长速度更加平缓，但在调查期结束时仍比年初低近 10%。

用户行为类抓取在 2025 年伊始是三类目的中抓取量最低的，但在 1 月和 2 月翻了一倍以上；3 月初，流量再次翻倍，此后全年持续增长，从 1 月到 12 月初增长了超过 21 倍。这一增长趋势与 OpenAI 的 ChatGPT-User 机器人流量走势高度吻合。

^{2025 年全球用户行为爬网程序流量趋势}

2025 年，AI 爬网程序频频登上新闻，原因是内容所有者对其产生的流量规模表示担忧，尤其是这些流量大多无法将最终用户引导回源网站。为了更好地理解 AI 机器人抓取活动的影响，并将其与非 AI 机器人和人类网页使用进行对比，我们分析了 Cloudflare 客户群中 HTML 内容的请求流量，并将其划分为来自人类、AI 机器人或非 AI 机器人。（注意：由于我们在此仅关注 HTML 内容，因此机器人与人类所占的流量比例会与 Radar 上分析所有内容类型请求流量时的比例不同。）由于 Googlebot 抓取非常活跃且具有双重用途，我们在本分析中单独列出了它的占比。

整个 2025 年，我们发现 AI 机器人产生的流量平均占 HTML 请求的 4.2%。这一比例在全年波动很大，4 月初曾降至最低 2.4%，6 月底则升至最高 6.4%。

相比之下，非 AI 机器人在 2025 年初占 HTML 页面请求的一半，比人类产生的流量高出 7 个百分点。这一差距在 6 月初的前几天一度扩大到 25 个百分点。然而，从 6 月中旬开始，这两类流量占比逐渐接近；自 9 月 11 日起，进入了一个人类流量占比有时超过非 AI 机器人的阶段。截至 12 月 2 日，人类流量占 HTML 请求的 47%，非 AI 机器人占 44%。

Googlebot 是一个特别“贪吃”的爬网程序，今年它单独贡献了 4.5% 的 HTML 请求，略高于所有 AI 机器人的总体占比。其占比在年初略低于 2.5%，随后在四个月内迅速攀升，4 月底达到峰值 11%。之后的几个月回落至接近起点水平，并在下半年再次增长，年末占比为 5%。这一占比变化基本反映了前文所述的 Googlebot 抓取活动趋势。

^{2025 年全球按机器人类型划分的 HTML 流量占比}

我们于 7 月 1 日在 Radar 上推出了抓取-引荐比指标，用于衡量给定 AI 或搜索平台在抓取某网站的同时，向该网站发送实际用户流量的频率。高比值意味着大量抓取但几乎没有带来真实访客。

这是一个波动性较大的指标，随着抓取活动和引荐流量的每日变化，数值也会随之起伏。该指标比较了来自与特定搜索或 AI 平台相关的用户代理的总请求数（响应内容类型为 Content-type: text/html）与 Referer 标头包含与特定搜索或 AI 平台相关的主机名的 HTML 内容请求总数。

Anthropic 今年的抓取-推荐比最高，一度达到 500,000:1，尽管 1 月至 5 月期间波动极大。这种高波动和高比值很可能是由于该时期推荐流量极少所致。之后比值趋于稳定，但仍高于其他平台，范围大致在 25,000:1 到 100,000:1 之间。

OpenAI 的比值随时间变化剧烈，3 月曾高达 3,700:1。这可能与 GPTBot 抓取活动的稳定化以及 ChatGPT 搜索功能使用量增加有关——后者会在回复中包含指向源网站的链接。用户点击这些链接会增加 Referer 计数，从而可能降低比值（前提是抓取流量没有以相同或更快的速度增加）。

Perplexity 在主要 AI 平台中拥有最低的抓取-引荐比，年初低于 100:1，但在 3 月底随 PerplexityBot 抓取流量激增而飙升至 700:1 以上。激增后回落，峰值通常保持在 400:1 以下，9 月起进一步降至 200:1 以下。

在搜索平台中，Microsoft 的比值意外呈现出每周周期性模式，周四最低，周日最高。全年峰值比值通常在 50:1 到 70:1 之间。Google 的抓取-引荐比年初略高于 3:1，之后稳步增长，到 4 月份达到 30:1 的高点。达到峰值后，该比值在 7 月中旬之前出现了一些波动，回落到 3:1，但在 2025 年下半年又缓慢上升。DuckDuckGo 的比值在前三季度始终低于 1:1，但在 10 月中旬突然跃升至 1.5:1，并在剩余时间里保持较高水平。

^{2025 年全球 AI 和搜索平台抓取-引荐比率}

robots.txt 文件在 RFC 9309 中正式定义为机器人排除协议 (Robots Exclusion Protocol)，它是一种文本文件，内容所有者可通过它向 Web 爬网程序发出信号，指示哪些部分的网站允许或不允许被爬取。文件中的指令可显式地允许或禁止 AI 爬网程序搜索和访问整个站点或站点的特定部分。这些指令本质上相当于一个“禁止入内”标志，并不提供任何正式的访问控制。不过，Cloudflare 的托管 robots.txt 功能会自动更新站点的现有 robots.txt，或在站点上创建一个 robots.txt 文件，其中包含要求主流 AI 机器人运营商不要将内容用于 AI 模型训练的指令。此外，我们的 AI Crawl Control 功能可以跟踪对站点 robots.txt 指令的违反情况，并让站点所有者能够阻止来自违规用户代理的请求。

在 Cloudflare Radar 上，我们提供了对我们排名前 10,000 个域名中 robots.txt 文件数量的洞察，以及文件中针对选定爬网程序用户代理的“允许”和“禁止”指令的完全/部分配置。（此处的“完全”指适用于整个站点的指令，“部分”指仅适用于指定路径或文件类型的指令。）在年度回顾微型网站中，我们展示了 2025 年全年这些指令配置的变化趋势。

被完全禁止次数最多的用户代理是与 AI 爬网程序相关的用户代理，包括 GPTBot、ClaudeBot 和 CCBot。用于搜索索引和 AI 训练的 Googlebot 和 Bingbot 爬网程序的指令主要倾向于部分禁止访问，很可能是为了隔离登录端点及其他非内容区域。对于这两个机器人，全年观察到的完全禁止站点的指令仅占禁止指令总数的一小部分。

^{按用户代理划分的 robots.txt 禁止指令}

在已发现的 robots.txt 文件中，显式“允许”指令的数量远少于“禁止”指令，这很可能是因为在没有特定指令的情况下，默认政策就是允许访问。Googlebot 拥有的显式“允许”指令数量最多，但其中超过一半是“部分允许”。针对 AI 爬网程序的“允许”指令出现在更少的域名上，而对 OpenAI 爬网程序的允许指令更倾向于显式的“完全允许”。

Google-Extended 是一个用户代理令牌，网站发布者可利用它管理 Google 从其站点爬取的内容是否可用于训练 Gemini 模型，或从 Google 搜索索引向 Gemini 提供站点内容。今年针对它的“允许”指令数量增加了两倍——年初大多为部分允许访问，而年末显式允许全站访问的指令数量超过了仅允许部分站点内容的指令。

^{按用户代理划分的 robots.txt 允许指令}

AI 模型的竞争格局正在迅速演变，提供商会定期发布更强大的模型，能够完成文本生成、图像生成、语音识别和图像分类等任务。Cloudflare 与 AI 模型提供商密切合作，确保这些模型发布之后，Workers AI 可以尽快为其提供支持，而且我们最近已并购了 Replicate，以显著扩展我们支持的模型目录。2025 年 2 月，我们在 Radar 上推出了对公开可用支持模型的受欢迎程度及其执行的任务类型的可见性分析，统计基于客户账户份额。

全年中，Meta 的 llama-3-8b-instruct 占据主导地位，其账户份额达 36.3%，是第二名 OpenAI 的 whisper (10.1%) 和第三名 Stability AI 的 stable-diffusion-xl-base-1.0 (9.8%) 的三倍多。Meta 和北京智源人工智能研究院 (BAAI) 在前十名中各有多款模型，前十名模型的账户份额合计达 89%，其余份额分布在其他众多模型中。

^{2025 年全球 Workers AI 最受欢迎的模型}

任务受欢迎程度在很大程度上由热门模型驱动，文本生成、文本转图像和自动语音识别位列前三。48.2% 的 Workers AI 客户帐户使用了文本生成功能，几乎是文本转图像 (12.3%) 和自动语音识别 (11.0%) 份额的四倍。

^{2025 年全球 Workers AI 最受欢迎的任务}

除了上面介绍的年初至今的分析之外，下面我们还将对正在被抓取的内容进行时间点分析。请注意，这些分析结果并未包含在年度回顾专题网站中。

在年度回顾的 AI 部分，我们关注的是全球范围内 AI 机器人和爬网程序的流量，而不考虑被抓取内容所属帐户的地理位置。如果按地理维度进一步细分，并使用 2025 年 10 月的数据，查看各地理区域（以客户的账单地址为准）所拥有站点的爬网程序流量来源，可以发现：Googlebot 在每个区域的爬网程序流量占比均在 35%–55% 之间。

OpenAI 的 GPTBot 和 Microsoft 的 Bingbot 是第二活跃的爬网程序，抓取份额为 13-14%。在北美、欧洲和大洋洲等发达经济体，Bingbot 明显领先于其他 AI 爬网程序。但在南美和亚洲等快速增长的市场，GPTBot 对 Bingbot 的领先优势较小。

在分析 2025 年 10 月按客户行业划分的 AI 爬网程序活动时，我们发现零售和计算机软件行业持续吸引最多的 AI 爬网程序流量，两者合计占全部爬网程序活动的 40% 以上。

排名前十的其他行业的抓取活动份额则要小得多。这十大行业占抓取活动总量的近 70%，其余部分分布在众多其他行业。

^{2025 年 10 月 AI 抓取活动行业占比}

全球领先的两个移动设备操作系统是 Apple 的 iOS 和 Google 的 Android。通过分析每个网页请求中包含的 User-Agent 标头信息，我们可以计算出全年按客户端操作系统划分的流量分布。由于 Android 设备在价格区间、外形规格和功能方面分布广泛，Android 设备在全球产生的移动设备流量占大多数。

从全球来看，2025 年来自 iOS 的流量占比同比略有增长，上升了两个百分点，达到 35%。从 iOS 流量占比最高的国家来看，摩纳哥的比例最高，为 70%；共有 30 个国家/地区由 iOS 驱动了 50% 或以上的移动设备流量，包括丹麦 (65%)、日本 (57%) 和波多黎各 (52%)。

^{2025 年全球按操作系统划分的移动设备流量分布}

对于 Android 使用率较高的国家/地区，其份额明显更高。2025 年，有 27 个国家/地区的 Android 使用率超过 90%，其中巴布亚新几内亚最高，达到 97%。苏丹、马拉维、孟加拉国和埃塞俄比亚的 Android 份额也达到 95% 或更高。在 175 个国家/地区，Android 设备流量占比达到 50% 或更高，巴哈马以 51% 的份额位居该列表末尾。

^{2025 年 iOS 和 Android 使用情况分布}

HTTP（超文本传输协议）是支撑互联网运作的核心协议。在过去 30 多年里，它经历了数次重大修订。第一个标准化版本 HTTP/1.0 于 1996 年采用，HTTP/1.1 于 1999 年采用，HTTP/2 于 2015 年采用。而 2022 年标准化的 HTTP/3 是一次重大更新，它运行在一种名为 QUIC 的新传输协议之上。使用 QUIC 作为底层传输协议，使 HTTP/3 能够更快地建立连接，并通过缓解丢包和网络变化的影响来提升性能。同时，由于默认提供加密，使用 HTTP/3 还能降低遭受攻击的风险。

2025 年，全球范围内发往 Cloudflare 的请求中，有 50% 使用了 HTTP/2，HTTP/1.x 占 29%，其余 21% 通过 HTTP/3 发送。这些比例与 2024 年相比基本持平——今年 HTTP/2 和 HTTP/3 的占比仅略微上升。

^{2025 年全球按 HTTP 版本划分的流量分布}

从地理分布来看，HTTP/3 的使用似乎正在增长并不断扩展。去年我们曾指出，有八个国家/地区的 HTTP/3 请求占比超过三分之一。而在 2025 年，已有 15 个国家/地区的 HTTP/3 请求占比超过三分之一，其中格鲁吉亚的采用率达到 38%，略高于 2024 年留尼汪岛的最高水平 37%。（从历史数据来看，格鲁吉亚年初时的 HTTP/3 采用率约为 46%，但在上半年有所下降，随后趋于平稳。）亚美尼亚的 HTTP/3 采用率同比增长最大，从 25% 跃升至 37%。

有七个国家/地区的整体 HTTP/3 使用率低于 10%，主要原因是来自机器人流量的 HTTP/1.x 请求比例较高。这些国家/地区包括：香港、多米尼克、新加坡、爱尔兰、伊朗、塞舌尔和直布罗陀。

要打造一个现代化的网站，开发人员必须熟练地将日益增多的库和框架与第三方工具和平台进行整合。所有这些组件必须协同工作，才能确保网站提供高性能、功能丰富且无故障的用户体验。与往年一样，我们利用 Cloudflare Radar 的 URL 扫描仪，对排名前 5,000 的域名相关网站进行了扫描，以识别在 11 个类别中最常用的技术和服务。

jQuery 自称是一个快速、轻量且功能丰富的 JavaScript 库。我们的扫描发现，它在网站上的出现频率是 Slick（一个用于展示图片轮播的 JavaScript 库）的 8 倍。React 仍然是用于构建 Web 界面的最主要 JavaScript 框架，其被扫描到的网站数量是 Vue.js 的两倍。PHP、Node.js 和 Java 仍是最受欢迎的编程语言/技术，遥遥领先于其他语言，包括 Ruby、Python、Perl 和 C。

^{2025 年热门网站技术、JavaScript 库类别}

WordPress 依然是最受欢迎的内容管理系统 (CMS)，不过其在被扫描网站中的占比下降至 47%，减少的份额被多个竞争者瓜分。HubSpot 和 Marketo 仍是最主要的营销自动化平台，其合计份额同比增长了 10%。在 A/B 测试工具中，VWO 的占比同比增长了八个百分点，进一步拉大了与 Optimizely 的差距；而 Google Optimize 已于 2023 年 9 月停止服务，其占比从 14% 下滑至 4%。

应用程序编程接口 (API) 是现代动态网站以及 Web 和原生应用程序的基础。这些网站和应用程序高度依赖自动化 API 调用来提供定制化信息。通过分析 Cloudflare 所保护和分发的网络流量，我们可以识别出针对 API 端点的请求。通过对这些 API 相关请求应用启发式规则，并排除来自人类用户使用浏览器或原生移动应用程序的访问后，我们就可以识别出用于构建 API 客户端的热门编程语言。

2025 年，20% 的自动化 API 请求来自基于 Go 语言的客户端，相比 Go 在 2024 年 12% 的占比，实现了显著增长。Python 的占比也同比上升，从 9.6% 增至 17%。Java 跃居第三位，占比达 11.2%，较 2024 年的 7.4% 有所提升。去年排名第二的 Node.js，其占比在 2025 年降至仅 8.3%，滑落至第四位；而 .NET 依然居于前五名的末位，占比跌至仅 2.3%。

^{2025 年最受欢迎的自动化 API 客户端语言}

Cloudflare 拥有独特的优势来衡量搜索引擎市场份额，因为我们为全球数百万客户提供网站和应用程序的保护服务。为此，自 2021 年第四季度以来，我们一直在定期发布关于该数据的季度报告。我们使用 HTTP Referer 标头来识别向客户网站和应用程序发送流量的搜索引擎，并以总体汇总形式呈现市场份额数据，同时也按设备类型和操作系统进行分类展示。（设备类型和操作系统信息基于 User-Agent 和 Client Hints HTTP 请求标头。）

在全球范围内，Google 向 Cloudflare 保护和提供服务的网站输送的流量最多，2025 年的市场份额接近 90%。排名前五的其他搜索引擎包括 Bing (3.1%)、Yandex (2.0%)、百度 (1.4%) 和 DuckDuckGo (1.2%)。从全年趋势来看，Yandex 的市场份额从 5 月份的 2.5% 下降到 7 月份的 1.5%，而百度的市场份额从 4 月份的 0.9% 增长到 6 月份的 1.6%。

^{2025 年全球搜索引擎市场份额概况}

Yandex 用户主要集中在俄罗斯，该本土平台的市场份额为 65%，几乎是 Google (34%) 的两倍。在捷克共和国，用户更喜欢 Google (84%)，但本地搜索引擎 Seznam 的 7.7% 市场份额与其他国家的第二大搜索引擎相比表现强劲。

^{2025 年捷克共和国搜索引擎市场份额概况}

对于全球汇总的“桌面”系统流量，Google 的市场份额下降到约 80%，而 Bing 的市场份额跃升至近 11%。这可能是由于基于 Windows 的系统持续占据市场主导地位：在 Windows 系统上，Google 的流量占比仅为 76%，而 Bing 的流量占比约为 14%。对于移动设备流量，Google 的市场份额接近 93%，这一比例在 Android 和 iOS 设备中保持一致。

^{2025 年基于 Windows 系统的搜索引擎市场份额概况}

如需了解更多详细信息，包括“其他”类别下汇总的搜索引擎，请参阅 Cloudflare Radar 上的季度搜索引擎推荐报告。

Cloudflare 在衡量浏览器市场份额方面也拥有独特的优势，我们多年来一直发布关于该主题的季度报告。为了识别发出内容请求的浏览器及其关联的操作系统，我们使用来自 User-Agent 和 Client Hints HTTP 标头的信息。我们以整体汇总以及按设备类型和操作系统细分的方式呈现浏览器市场份额数据。请注意，同时适用于桌面和移动设备的浏览器（例如 Google Chrome 或 Apple Safari）的市场份额以汇总形式呈现。

2025 年，全球三分之二的 Cloudflare 请求流量来自 Chrome，与去年的份额相似。仅在 Apple 设备上可用的 Safari 是第二大最受欢迎的浏览器，市场份额为 15.4%。紧随其后的是 Microsoft Edge (7.4%)、Mozilla Firefox (3.7%) 和 Samsung Internet (2.3%)。

^{2025 年全球浏览器市场份额概况}

在俄罗斯，Chrome 仍然是最受欢迎的浏览器，市场份额为 44%，但本土的 Yandex 浏览器以 33% 的市场份额位居第二，而 Safari、Edge 和 Opera 的市场份额均低于 10%。有趣的是，Yandex 浏览器曾在 6 月以 39% 对 38% 的微弱优势一度超越 Chrome，但随着时间的推移，其市场份额被 Chrome 大幅超越。

^{2025 年俄罗斯浏览器市场份额概况}

作为 iOS 上的默认浏览器，Safari 在此类设备上遥遥领先，市场份额高达 79%，是 Chrome (19%) 的四倍。来自 DuckDuckGo、Firefox 和 QQ 浏览器（由中国腾讯开发）的请求不到 1%。相比之下，在 Android 系统上，85% 的请求来自 Chrome，而供应商提供的 Samsung Internet 以 6.6% 的份额位居第二。另一款供应商提供的浏览器 Huawei Browser 以 1% 的份额位居第三。尽管 Edge 是 Windows 系统的默认浏览器，但其 19% 的份额远不及 Chrome，后者在该操作系统中以 69% 的份额领先。

^{2025 年 iOS 设备浏览器市场份额概况}

有关如需了解更多详细信息，包括“其他”类别下汇总的浏览器数据，请参阅 Cloudflare Radar 上的季度浏览器市场份额报告。

互联网中断仍然是一个持续存在的威胁，而且这些中断的潜在影响也在不断扩大，因为它们可能导致经济损失、教育和政府服务中断以及通信受限。2025 年，我们在季度总结文章（第一季度、第二季度、第三季度）以及涵盖葡萄牙、西班牙和阿富汗重大中断事件的独立文章中，都报道了重要的互联网中断事件及其相关原因。Cloudflare Radar 中断中心持续跟踪这些互联网中断事件，并利用 Cloudflare 的流量数据来深入解析其范围和持续时间。

今年观察到的中断事件有近一半与为防止学术考试作弊而实施的互联网关闭有关。包括伊拉克、叙利亚和苏丹在内的多个国家再次在考试期间实施了为期数周、每次持续数小时的互联网关闭。此外，利比亚和坦桑尼亚因抗议和社会动荡而实施了由政府主导的中断；在阿富汗，塔利班下令在多个省份切断光纤互联网连接，作为“防止不道德行为”行动的一部分。

光缆中断（影响了海底和国内光纤基础设施）也是 2025 年互联网中断的主要原因之一。美国、南非、海地、巴基斯坦和中国香港等多个国家/地区的网络服务提供商因此遭遇了持续数小时至数天的服务中断。其他值得注意的中断事件还包括：埃及开罗一座电信大楼发生火灾，导致多家服务提供商的互联网连接中断数天；以及牙买加因飓风“梅丽莎”(Hurricane Melissa) 造成破坏，导致该岛的互联网流量在一周多的时间里持续下降。

在“年度回顾”微型网站的时间轴中，将鼠标悬停在某个圆点上即可查看该次中断的相关信息，点击则可跳转获取更深入的分析。

^{2025 年，全球范围内发生了 170 多起重大互联网中断事件}

尽管网络地址转换等解决方案使网络提供商能够扩展有限的 IPv4 资源，可用的 IPv4 地址空间也已在十多年前就基本耗尽。不过，这些举措在一定程度上减缓了 IPv6 的普及速度。IPv6 协议是在 20 世纪 90 年代中期设计的，旨在取代 IPv4，并提供更大的地址空间，以更好地支持互联网连接设备数量的预期增长。

近 15 年来，Cloudflare 一直是 IPv6 的积极倡导者和推动者，并推出了多项解决方案，包括 2011 年推出的 Automatic IPv6 Gateway，该网关为所有客户提供免费的 IPv6 支持；以及 2014 年为所有客户默认启用 IPv6 支持。简单来说，仅有服务器端的支持还不足以推动 IPv6 的普及，最终用户的连接也必须支持 IPv6。通过汇总和分析全年向 Cloudflare 发出的请求所使用的 IP 协议版本，我们可以洞察 IPv6 和 IPv4 的流量分布情况。

2025 年，全球范围内具备 IPv6 能力的“双栈”请求中，有 29% 是通过 IPv6 发出的，比 2024 年的 28% 上升了一个百分点。印度再次高居榜首，IPv6 采用率达 67%；紧随其后的是马来西亚、沙特阿拉伯和乌拉圭，它们的 IPv6 请求占比也超过一半，与去年相同。一些国家的增幅尤为显著，例如伯利兹从 4.3% 大幅增长至 24%，卡塔尔的采用率几乎翻倍，达到 33%。遗憾的是，部分国家/地区仍然落后，94 个国家/地区的采用率低于 10%，其中包括俄罗斯 (8.6%)、爱尔兰 (6.5%) 和中国香港 (3.0%)。更落后的是采用率低于 1% 的 20 个国家/地区，包括坦桑尼亚 (0.9%)、叙利亚 (0.3%) 和直布罗陀 (0.1%)。

^{2025 年全球按 IP 协议版本划分的流量分布}

^{2025 年 IPv6 采用率最高的五个国家/地区}

在过去十来年里，我们出于多种目的使用互联网速度测试：让服务提供商保持诚信、排查连接问题，或在社交媒体上炫耀特别高的下载速度。事实上，我们已经习惯将下载速度作为衡量网络质量的主要指标。虽然这确实是一个重要的指标，但对于越来越流行的使用场景（如视频会议、直播和在线游戏）而言，强大的上传速度和低延迟同样至关重要。然而，即使网络服务商提供了包含高对称速度和更低延迟的服务层级，由于成本、可用性或其他因素，消费者的采用程度往往参差不齐。

speed.cloudflare.com 上的测试可以测量下载速度和上传速度，以及负载和非负载延迟。通过汇总 2025 年世界各地进行的测试结果，我们可以从国家/地区的角度了解这些连接质量指标的平均值，并洞察测量数据的分布情况。

在 2025 年平均下载速度最高的国家中，欧洲国家占据了重要地位。西班牙、匈牙利、葡萄牙、丹麦、罗马尼亚和法国均跻身前十名，其中西班牙和匈牙利的平均下载速度均超过 300 Mbps。西班牙的平均速度较 2024 年提升了 25 Mbps，而匈牙利的增速更是高达 46 Mbps。与此同时，亚洲国家/地区在平均上传速度方面表现突出，韩国、澳门、新加坡和日本进入前十，平均速度均超过 130 Mbps。

但就上传速度而言，西班牙以 206 Mbps 位居榜首，比 2024 年提升了 13 Mbps。该国在两项速度指标上的优异表现可能得益于“UNICO-宽带”计划——这是“一个面向电信运营商的招标项目，旨在部署高速宽带基础设施，提供至少 300 Mbps 的对称速度服务，并可扩展至 1 Gbps”，目标是到 2025 年覆盖 100% 的人口。

^{2025 年全球下载速度最高的国家/地区}

如上所述，低延迟连接对于为用户提供良好的游戏和视频会议/流媒体体验至关重要。延迟指标可以分为负载延迟和空闲延迟。前者测量的是在网络带宽被实际使用状态下的延迟，而后者则是在没有其他网络流量时的“空闲”连接状态下测得的延迟。（这些定义是从速度测试应用程序的角度出发的。）

在 2025 年，多个欧洲国家同时在空闲延迟和负载延迟两项指标上表现优异，位列全球最低水平。在平均空闲延迟方面，冰岛测得的最低值为 13 毫秒，仅比摩尔多瓦快 2 毫秒。除了这两个国家外，葡萄牙、西班牙和匈牙利也跻身前十，平均空闲延迟均在 20 毫秒以下。在平均负载延迟方面，摩尔多瓦以 73 毫秒位居全球最低，成为该项指标的领头羊。此外，匈牙利、西班牙、比利时、葡萄牙、斯洛伐克和斯洛文尼亚也进入了前十，平均负载延迟均低于 100 毫秒。

^{摩尔多瓦测得的空闲/负载延迟}

正如我们前面所讨论的，speed.cloudflare.com 上的速度测试可以测量用户的连接速度和延迟。我们回顾了这些测试的汇总结果，重点展示了取得最佳成绩的国家或地区。不过，我们也好奇全球范围内的测试活跃度——用户最关注连接质量的地区在哪里？他们进行速度测试的频率又如何？新的年度回顾动画可视化图表展示了按周汇总的速度测试活动。

数据在区域层面上进行汇总，并将相关活动绘制在世界地图上，圆圈的大小代表每周进行的测试数量。需要注意的是，每周测试次数少于 100 次的区域不会显示在图中。从全年的测试量来看，伦敦大区、洛杉矶地区、东京、香港以及美国的多个城市是测试最活跃的地区。

通过动画形式观察全年变化，可以看到测试量在一些周期中出现了逐周激增的情况。例如：在截至 6 月 10 日的那一周，肯尼亚的内罗毕地区测试量显著上升；在截至 7 月 29 日的那一周，伊朗的德黑兰地区出现激增；在截至 8 月 5 日的那一周，俄罗斯多个地区测试量同步上涨；以及在截至 10 月 28 日的那一周，印度的卡纳塔克邦也出现了明显增长。目前尚不清楚导致这些测试量激增的具体原因——Cloudflare Radar 中断中心并未显示这些时间段内出现影响上述地区的互联网中断，因此不太可能是由于用户在测试网络恢复情况所致。

^{2025 年按地点统计的 Cloudflare 速度测试活动}

无论好坏，在过去二十五年间，移动设备已成为日常生活中不可或缺的一部分。全球各地的普及程度不一——据世界银行的统计数据显示，截至 2025 年 10 月，多个国家和地区的手机拥有率超过 90%，而在另一些地区，这一比例低于 10%。在某些国家/地区，移动设备主要通过 Wi-Fi 连接到互联网，而在“移动网络优先”的其他国家/地区，主要通过 4G/5G 服务来访问互联网。

Cloudflare 收到的每个请求都包含 User-Agent 标头，其中的信息使我们能够将其归类为来自移动设备、台式机或其他类型的设备。对 2025 年全球数据进行汇总后发现，43% 的请求来自移动设备，高于 2024 年的 41%。其余请求来自“传统”笔记本电脑和台式机等设备。与去年的观察类似，这些流量占比与 2022 年以来《年度回顾》报告中测量的数据一致，表明移动设备使用已趋于“稳定状态”。

在 117 个国家/地区，超过一半的请求来自移动设备，其中苏丹和马拉维分别以 75% 和 74% 的比例领先。2025 年，斯威士兰、也门、博茨瓦纳、莫桑比克和索马里这五个非洲国家/地区的移动设备请求份额也超过 70%，这与该地区较高的手机拥有率相符。在移动设备流量占比较低的国家/地区中，直布罗陀是唯一一个低于 10% 的（为 5.1%），除此之外，仅有六个国家/地区的移动请求占比低于四分之一。这比 2024 年要少，当时有 12 个国家/地区的移动占比低于 25%。

^{2025 年全球按设备类型划分的流量分布}

^{2025 年按设备类型划分的全球流量分布}

Cloudflare 利用 DDoS 缓解技术或 Web 应用程序防火墙 (WAF) 托管规则，自动缓解针对客户网站和应用程序的攻击流量，从而保护客户免受恶意攻击者造成的各种威胁。我们还允许客户缓解非恶意流量，例如使用请求速率限制或阻止来自特定位置的所有流量等技术。采取此类措施的原因可能源于合规性或业务需求。我们分析了 2025 年 Cloudflare 网络中因各种原因而被缓解的流量占总流量的比例，以及被识别为 DDoS 攻击或被 WAF 托管规则阻止的流量所占的比例。

今年，共有 6.2% 的全球流量被缓解，比 2024 年下降了 0.25 个百分点。其中，3.3% 的流量因 DDoS 攻击或托管规则而被缓解，同比增长了 0.1 个百分点。超过 30 个国家/地区的流量中有超过 10% 被一般性缓解措施处理；而 14 个国家/地区中，有超过 10% 的发起流量被 DDoS/WAF 缓解措施处理。二者相比 2024 年均有所下降。

赤道几内亚是被缓解流量占比最高的国家/地区，分别有 40% 的一般性缓解比例和 29% 的 DDoS/WAF 缓解比例。这两个比例在过去一年中有所上升，分别从 26%（一般缓解）和 19%（DDoS/WAF 缓解）增长而来。相比之下，多米尼克是被缓解流量最少的国家/地区，仅有 0.7% 的流量被缓解，而其中只有 0.1% 是由于 DDoS/WAF 而被缓解。

下图中显示的 7 月份被缓解流量大幅上升的情况，是由于一次规模极大的 DDoS 攻击活动，主要针对某一个 Cloudflare 客户的域名。

^{2025 年全球被缓解流量趋势}

机器人是一种被编程用于执行特定任务的软件应用程序。Cloudflare 使用先进的启发式算法区分机器人流量与人类流量，对每个请求评分以判断其来源于机器人或人类用户的可能性。通过监控疑似来自机器人的流量，网站和应用程序所有者可以发现潜在的恶意活动，并在必要时予以阻止。然而，并非所有机器人都是恶意的，有些机器人也可以具有积极作用。Cloudflare 维护着一个经验证机器人目录，其中包括用于搜索引擎索引、安全扫描、站点/应用程序监控等用途的机器人。不论意图如何，我们基于请求的 IP 地址识别其所归属的网络（自治系统）及国家/地区，对 2025 年的机器人流量来源进行了分析。

在全球范围内，排名前十的国家/地区占观测到的机器人流量的 71%。其中 40% 来自美国，远高于德国的 6.5%。美国的份额比 2024 年增加了五个百分点以上，而德国的份额则略有下降。排名前十的其他国家/地区在 2025 年的机器人流量份额均低于 5%。

^{2025 年按来源国家/地区划分的全球机器人流量分布}

从网络角度来看，我们发现云平台仍然是机器人流量的主要来源之一。这背后有多个因素，包括便于使用自动化工具快速配置计算资源、成本相对较低、地理分布广泛以及平台具备高带宽互联网连接能力。

与 Amazon Web Services 相关的两个自治系统共占观察到的机器人流量总量的 14.4%，而与 Google Cloud 相关的两个自治系统合计占 9.7%。紧随其后的是 Microsoft Azure，其产生的机器人流量占 5.5%。这三家平台的占比相比 2024 年均有所上升。在排名前十的多数国家/地区中，这些云平台在当地设有强大的数据中心布局。而在世界其他地区的自动化机器人流量中，当地的电信运营商往往占据最大份额。

^{2025 年按来源网络划分的全球机器人流量分布}

攻击者不断变换其战术与目标，通过多样化手段试图规避检测，或根据他们企图造成的破坏来选择目标。他们可能会在购物高峰期攻击电子商务网站，对企业造成经济损失；也可能攻击政府相关网站或民间社会网站，发表政治声明；或者攻击游戏服务器，使竞争对手的网络瘫痪。为了识别 2025 年针对特定行业的攻击活动，我们分析了客户记录中标明所属行业和类别的客户的被缓解流量。我们按来源国家/地区对 17 个目标行业的被缓解流量进行了每周汇总。

“人与社会”领域的组织是全年遭受最多攻击的目标，全球被缓解流量中有 4.4% 针对该领域。被归类为“人与社会”的客户包括宗教机构、非营利组织、公民和社会组织以及图书馆。该领域年初的被缓解流量占比不到 2%，但在 3 月 5 日那一周，这一比例跃升至 10%，并在月底增至超过 17%。针对这些网站的其他攻击高峰出现在 4 月下旬（达到 19.1%）和 7 月初（达到 23.2%）。许多此类组织受到 Cloudflare Galileo 项目的保护，这篇博客文章详细介绍了他们在 2024 年和 2025 年遭受的攻击和威胁。

去年遭受最多攻击的“博彩/游戏”领域的被缓解攻击份额同比下降了一半以上，降至仅 2.6%。尽管人们可能预期针对博彩网站的攻击会在超级碗和疯狂三月等重大体育赛事期间达到顶峰，但这种趋势并不明显，因为攻击份额在 3 月 5 日那一周达到峰值 6.5%——此时距离超级碗已过去一个月，而距离疯狂三月开始还有几周时间。

^{2025 年按垂直行业划分的全球被缓解流量占比，摘要视图}

边界网关协议 (BGP) 是互联网的核心路由协议，它通过在网络之间传递路由信息，使流量能够在来源和目的地之间传输。然而，由于它依赖于连接网络之间的信任，对等方之间共享的错误信息（无论是有意还是无意）都可能导致流量被发送到错误的位置——甚至可能发送到攻击者控制的系统。为了解决这个问题，资源公钥基础设施 (RPKI) 应运而生，它是一种加密方法，用于对记录进行签名，将 BGP 路由公告与正确的源自治系统 (AS) 编号关联起来，以确保共享的信息确实来自被授权的网络。Cloudflare 一直是路由安全的倡导者，包括作为 MANRS CDN 和云计划的创始参与者，以及提供公共工具，让用户能够测试其互联网服务提供商是否已安全实施 BGP。

我们分析了 Cloudflare Radar 路由页面上的可用数据，以确定 RPKI 有效路由的份额以及该份额在 2025 年的变化情况，并确定有效路由覆盖的 IP 地址空间份额。后一个指标值得关注，因为覆盖大量 IP 地址空间（数百万个 IPv4 地址）的路由公告比覆盖少量 IP 地址空间（数百个 IPv4 地址）的公告具有更大的潜在影响。

2025 年初，有效 IPv4 路由的份额为 50%，到 12 月 2 日增长到 53.9%。有效 IPv6 路由的份额增加到 60.1%，增长了 4.7 个百分点。从有效路由覆盖的全球 IP 地址空间份额来看，IPv4 增长到 48.5%，增长了三个百分点。有效路由覆盖的 IPv6 地址空间份额略有下降，为 61.6%。尽管这些指标的同比变化正在放缓，但我们在过去五年中取得了显著进展。自 2020 年初以来，RPKI 有效 IPv4 路由和 IPv4 地址空间的份额都增长了大约三倍。

^{2025 年按 IP 版本划分的全球 RPKI 有效路由项占比}

^{2025 年 RPKI 有效路由覆盖的全球公布的 IP 地址空间占比}

巴巴多斯在有效 IPv4 路由比例方面增幅最大，从 2.2% 大幅提升至 20.8%。在有效 IPv6 路由方面，马里在 2025 年的占比增长最为显著，从 10.0% 升至 58.3%。

巴巴多斯在有效 IPv4 地址空间覆盖比例上也实现了最大增幅，从仅 2.0% 跃升至 18.6%。至于 IPv6 地址空间，塔吉克斯坦和多米尼克在年初时几乎没有被有效路由覆盖的空间，但到年末分别达到了 5.5% 和 3.5%。

在我们发布的季度 DDoS 报告系列（第一季度、第二季度、第三季度）中，我们强调了针对 Cloudflare 客户及 Cloudflare 基础设施的超流量网络层攻击的频率和规模不断增长。我们将“超流量网络层攻击”定义为在第 3/4 层发动且峰值超过每秒 1 TB (1 Tbps) 或每秒超过十亿数据包 (1 Bpps) 的攻击。这些报告提供了季度视角，但我们也希望展示全年的活动情况，以了解攻击者最活跃的时间段，以及攻击规模如何随时间增长。

从 Tbps 的角度来看 2025 年的超流量攻击活动，7 月份此类攻击数量最多，超过 500 次，而 2 月份最少，仅略高于 150 次。攻击强度总体保持在 5 Tbps 以下，但在 8 月底被拦截的一次 10 Tbps 攻击预示着未来趋势的到来。此次攻击是 9 月第一周发生的一系列超过 10 Tbps 攻击的开端，随后在当月最后一周又发生了一系列超过 20 Tbps 的攻击。10 月初，观察到多次规模不断增大的超大流量攻击，当月最大攻击峰值达到 29.7 Tbps。然而，这一记录很快就被打破，11 月初的一次攻击达到了 31.4 Tbps。

从 Bpps 的角度来看，超流量攻击活动要少得多，11 月份攻击次数最多（超过 140 次），而 2 月和 6 月仅有 3 次。全年攻击强度总体保持在 4 Bpps 以下，直到 8 月底，但在接下来的几个月里，攻击规模不断增大，并在 10 月份达到峰值。尽管 10 月份拦截的 110 多次攻击中，大多数攻击强度低于 5 Bpps，但当月的一次 14 Bpps 攻击是全年按每秒数据包数计算的最大超流量攻击，打破了 9 月份连续五次创下的记录。

^{2025 年 DDoS 攻击规模峰值}

最新统计数据显示，尽管企业越来越多地使用协作/即时通讯应用程序，但电子邮件仍然是外部业务联系的主要沟通渠道。鉴于电子邮件在企业中的广泛应用，攻击者仍然认为它是进入企业网络的有效途径。生成式 AI 工具使得攻击者更容易制作高度针对性的恶意电子邮件，这些邮件能够逼真地冒充可信品牌或合法发件人（例如公司高管），但却包含欺骗性链接、危险附件或其他类型的威胁。Cloudflare Email Security 保护客户免受各种基于电子邮件的攻击，包括通过发送有针对性的恶意电子邮件来执行的攻击。

2025 年，Cloudflare 分析的电子邮件中平均有 5.6% 被识别为恶意邮件。Cloudflare Email Security 服务处理的邮件中，恶意邮件的比例在一年中的大部分时间里通常在 4% 到 6% 之间。我们的数据显示，从 10 月份开始，恶意电子邮件的比例有所上升，这可能是由于 Cloudflare Email Security 服务实施了改进的分类系统。

^{2025 年全球恶意电子邮件占比趋势}

欺骗性链接是 2025 年最主要的恶意电子邮件威胁类别，在 52% 的邮件中发现了此类链接，高于 2024 年的 43%。由于 HTML 中超链接的显示文本可以任意设置，攻击者可以使 URL 看起来像是链接到良性网站，但实际上它链接的是恶意资源，可用于窃取登录凭据或下载恶意软件。4 月下旬和 11 月中旬，包含欺骗性链接的已处理电子邮件的比例高达 70%。

身份冒充是指攻击者冒充他人发送电子邮件。他们可能使用看起来相似、被伪造的域名，或通过显示名称技巧，使邮件看似来自受信任的域名。品牌仿冒是一种身份伪装形式，攻击者冒充知名公司或品牌来发送网络钓鱼邮件。品牌仿冒也可能使用显示名称欺骗或域名冒充。2025 年，身份冒充 (38%) 和品牌仿冒 (32%) 都在不断增长，分别高于 2024 年的 35% 和 23%。两者在 11 月中旬均有所增长。

^{2025 年全球电子邮件威胁类别趋势}

除了提供 .com 或 .us 等顶级域名 (TLD) 的流量、地理分布和数字证书信息外，Cloudflare Radar 还提供有关“最常被滥用”的 TLD 的解析——这些 TLD 的域名在 Cloudflare Email Security 分析的邮件中，发送的恶意邮件和垃圾邮件比例最高。该分析基于电子邮件的 From: 标头中找到的发送域的 TLD。例如，如果邮件来自 sender@example.com，则 example.com 是发送域，.com 是关联的 TLD。在年度回顾分析中，我们仅包含那些平均每小时至少收到 30 封邮件的顶级域。

根据 2025 年全年分析的邮件，我们发现 .christmas 和 .lol 是滥用最严重的顶级域，分别有 99.8% 和 99.6% 的邮件被归类为垃圾邮件或恶意邮件。按恶意邮件占比对 TLD 进行排序，.cfd 和 .sbs 的恶意邮件占比均超过 90%。就垃圾邮件占比而言，.best TLD 的情况最糟糕，69% 的邮件被归类为垃圾邮件。

^{2025 年产生最高占比恶意邮件和垃圾邮件的顶级域}

尽管互联网和万维网随着时间不断演进与变化，但一些关键指标似乎已趋于相对稳定。然而，我们预计其他指标（例如追踪 AI 趋势的指标）在未来几年会随着该领域的快速发展而发生变化。

我们强烈建议您访问 Cloudflare Radar 2025 年度回顾微型网站，探索您所在国家/地区的趋势，并思考这些趋势在您规划 2026 年时对组织的影响。您也可以在 Cloudflare Radar 上获取许多此类指标与趋势的近实时洞察。此外，如上文所述，若想了解多个行业类别及国家/地区的热门互联网服务情况，我们建议您阅读配套的年度回顾博客文章。

如有任何疑问，您可以通过 radar@cloudflare.com 或社交媒体 @CloudflareRadar (X)、https://noc.social/@cloudflareradar (Mastodon) 以及 radar.cloudflare.com (Bluesky) 联系 Cloudflare Radar 团队。

俗话说，“众人拾柴火焰高”。为了完成我们的年度回顾报告，从数据的汇总与分析、微型网站的创建，到相关内容的制作，都离不开团队的共同努力。在此，我要向所有为今年工作做出贡献的团队成员致以诚挚的感谢：Jorge Pacheco、Sabina Zejnilovic、Carlos Azevedo、Mingwei Zhang、Sofia Cardita（数据分析）；André Páscoa、Nuno Pereira（前端开发）；João Tomé（最受欢迎的互联网服务）；David Fidalgo、Janet Villarreal 和国际化团队（翻译）；Jackie Dutton、Kari Linder、Guille Lasarte（传播）；Laurel Wamsley（博客编辑）；以及 Paula Tavares（工程管理），同时感谢 Cloudflare 各部门的同事们给予的支持与帮助。

本报告是《2025 年 Cloudflare Radar 年度回顾》的一部分，重点关注互联网服务热门程度的变化。我们希望您能从结果中看出九大类别的发展趋势 — 谁在上升，谁在下滑，以及谁继续吸引我们的注意力。

这些排名显示了每个类别的相对热门程度，基于 Cloudflare 的 1.1.1.1 的匿名 DNS 查询数据。2022 年推出的 DNS 解析器和机器学习辅助排名方法。排名较低并不意味着流量降低，仅表示其他服务的增长速度可能更快。

• 生成式 AI ➜

• 社交媒体 ➜

• 电子商务➜

• 视频流 ➜

• 新闻 ➜

• 通信 ➜

• 元宇宙和游戏 ➜

• 金融服务 ➜

• 加密货币服务 ➜

从社交媒体和流媒体的统治地位到 AI 聊天机器人的快速增长，数据表明互联网正在不断适应用户需求和新技术。我们观察到的一些变化与新闻事件相吻合，例如以色利-伊朗的短暂冲突和唐纳德·特朗普的就职典礼，以及欧洲歌唱大赛和黑色星期五等全球现象。

• 亚洲电子商务攀升：Shopee 和 Temu 加入亚马逊，跻身全球电子商务前三。

• ChatGPT 仍然领先，但竞争对手不断涌现：Claude、Gemini、Perplexity 和 DeepSeek 使生成式 AI 领域竞争激烈，Gemini 在年底占据了第二的位置。

• Instagram 上升，TikTok 和 X 下降：Instagram 总体排名从第 7 位升至第 5 位，在社交媒体类别中排在第 2 位，而 TikTok 下滑至第 8 位，X 跌出前 20 榜单。

• 快手在新兴市场悄然崛起：这款中国短视频应用在我们的全球社交媒体排名攀升，目前在巴西排在第 3 位，在几个新兴市场排名靠前。

• Roblox 仍主导游戏行业，PlayStation 超越 Xbox：Roblox 在元宇宙和游戏类别中稳居第一，PlayStation 超过 Xbox，排名第二。

• Stripe 和 Nubank 引领数字优先金融：Stripe 仍稳居金融服务领域第一，巴西新型银行 Nubank 突显拉丁美洲数字银行的蓬勃发展。

• 加密货币趋于稳定，OKX 交易量激增：Binance 保持领先地位，但由于特朗普就职典礼前后加密货币流量激增以及市场反弹，OKX 跃升至第二位。

• AI 压力下的新闻：由于 AI 平台正在重塑人们查找信息的方式，Globo 和 ESPN 在新闻类别中占据主导地位，大多数传统媒体在我们的综合排名中均出现下滑。

此外，我们连续第二年将年度回顾微站点中最热门的网际网路服务按国家/地区提供。年度回顾中提供了前十榜单，不仅提供综合排名，还提供 100 多个国家和地区的生成式 AI、社交媒体和短信排名情况。在本文末尾，我们将重点介绍从这些本地化数据中得出的主要趋势。

探索完整的 2025 年 Cloudflare Radar 年度回顾微站点，获取交互式可视化、额外指标，以及关于互联网流量模式、安全趋势和网络性能数据的更深入分析。查看 2025 年度回顾博客文章，了解更多见解。

我们的分析使用的匿名 DNS 查询数据来自全球数百万用户的 1.1.1.1 公共 DNS 解析器。我们对与每项服务关联的域名进行了汇总（例如 twitter.com、t.co 和 x.com 被归类为“X”），专注于最终用户访问的服务，不包括 root-servers.net 这类基础设施域名。 

自我们在 2022 年推出现行排名方法以来，Google（包括 Google Maps 和 Google Calendar 等服务）一直是全球最热门的互联网服务。Facebook 连续第三年保持第二的位置。

Apple 和 Microsoft 与 Google 遵循类似的模式，其主要域名（apple.com 和 microsoft.com）为许多不同的服务提供支持。使用不同域名的其他服务（例如 Outlook 或 iCloud）将单独计数。

（注：在这些排名中，我们使用 ▲▼ 符号来表示与 2024 年相比的变化。）

1. Google
2. Facebook
3. Apple
4. Microsoft ▲
5. Instagram ▲
6. AWS ▼
7. YouTube ▲
8. 抖音 ▼
9. Amazon
10. WhatsApp

Apple 在今年大部分时间都稳居第三，但从夏季开始，Microsoft 对其发起了短暂的挑战，并在 2025 年底的几天内一度上升到该位置。即便如此，Apple 年末时仍排名第三。Microsoft 的工具总体表现优于 2024 年 — Outlook 和 Microsoft 365/Office 仅略低于前 10 服务。

Instagram 是 2025 年表现最佳的服务之一。年初排在第 7 位，与 2024 年的排名一致，但到年底攀升至第 5 位，并在 5 月和 6 月的几天内达到第 4 位。YouTube 也有所进步，排名上升一位到第 7 位。WhatsApp 的另一项 Meta 服务排名保持在第 10 位，但在 2025 年底出现更频繁，排在第 9 位，甚至在 5 月和 6 月的部分时间达到第 7 位。

抖音年初经历动荡，包括在美国被临时禁令后，总体排名有所下降。从 2024 年末的第 4 位降至 2025 年末的第 8 位，夏季及之后表现最差。通过 amazonaws.com 域名，分开追踪 Amazon 的 Amazon Web Services (AWS) 也略有下滑，下降一位到第 6 位。亚马逊仍然排在第 9 位，但面临的竞争比 2024 年更加激烈。

下图显示了这些顶级互联网服务在全年中的演变情况。

X 继续呈下降趋势。2022 年，其排名一度高达第 10 位，与 Instagram 不相上下。2023 年，该服务跌出了前十榜单，并在 2024 年左右跌至第 14-15 位。2025 年，其最初排在第 15 位，之后排名持续下滑，年底跌出前 20 榜单。有关 X 性能的更多信息，请参阅下面的社交媒体部分。

2022 年底，随着 ChatGPT 的推出，生成式 AI 成为全球公认的领域，并在 2023 年风靡全球。与 2024 年相同，OpenAI 的 ChatGPT 在 2025 年仍是该类别中最热门的服务，包括聊天机器人、编程助手和其他 AI 工具。但其现在面临强大的通用聊天机器人竞争对手，包括 Claude、Perplexity 和 Google Gemini，这些公司的业务随着时间的推移而出现了更大增长。

1. ChatGPT / OpenAI
2. Claude / Anthropic ▲
3. Perplexity ▲
4. Google Gemini ▲
5. Character.AI ▼
6. GitHub Copilot ▲
7. Windsurf AI ▼
8. QuillBot ▼
9. Grok / xAI ▲
10. DeepSeek ▲

2024 年，最接近 ChatGPT 的服务包括 Character.AI（角色扮演聊天机器人）、Codeium（编码助手，即现在的 Windsurf）和 QuillBot（写作和释义工具）。在 2025 年，这些工具的排名有所下降，尤其是 QuillBot，原因是用户开始寻找更广泛、面向消费者的聊天机器人。Character.AI 的排名下降也恰逢其在 10 月宣布将禁止青少年使用其 AI 聊天机器人 — 到 11 月，其排名在第 5 位和第 7 位之间波动。

最大的增幅来自 Google 的 Gemini。2025 年初，该服务在前十榜单之外，但排名稳步攀升，自 9 月中旬起，在大多数日子都保持在第 2 位。在我们的年末加权排名中，其位列第四。

Anthropic 的 AI 助手 Claude 在今年表现强劲，从 2025 年初的第 8-10 位上升至 7 月和 8 月的大部分工作日的第 2 位，之后在 9 月中旬被 Gemini 超越。与其企业定位相符，Claude 在工作日的使用量明显更高。

9 月起，Perplexity 从第 7 位攀升至稳居第 3 位，而 Grok（来自 xAI 的聊天机器人）在 2 月中旬进入前 20 榜单，并在月底达到第 9 位，并在 10 月和 11 月的几个周末达到顶峰，排在第 6 位。

中国聊天机器人和开源模型开发商 DeepSeek 成为今年最引人注目的入场者。1 月 28 日至 2 月 3 日，该产品从前 20 位之外跃升至第 3 位，这表明新的参与者能够以惊人的速度颠覆 GenAI 领域。在今年剩余的时间内，排名稳定在第 6 位到第 10 位之间。

明显的周末与工作日模式已经显现：ChatGPT 和 Claude 在工作日占据主导地位，反映了其在工作场所的普及；而 Grok、Perplexity 和 DeepSeek 在周末表现更佳，表明其对消费者和潜在的业余爱好者更具吸引力。

在众多编码助手中，GitHub Copilot 的排名从 2024 年的第 7 位上升到 2025 年的第 6 位，并在今年上半年的几天内达到第 3 位。Windsurf AI（前身为 Codeium）最初排在第 4 位，表现强劲，但由于面向消费者的平台崛起，年底排名下降至第 7-8 位。

字节跳动的豆包在 2023 年推出，尽管存在一个问题，但其表现依然强劲：豆包在国际上以不同的名称运营 — Dola（原名 Cici）。虽然国际版本使用其自身的域名，但网络模式表明其可能仍然依赖于与豆包共享的一些后端基础设施，包括与 doubao.com 相关的端点。这种重叠有助于解释为什么即使 Dola/Cici 在面向消费者的品牌所在的地区，豆包也能出现在全球排名中。豆包在中国以外的地区排名很高：在澳大利亚的 GenAI 类别中排在第 7 位，在新西兰排在第 8 位，在英国排在第 9 位，在几个非洲国家/地区排名甚至更高（在安哥拉和刚果排在第 2 位）。

在专用 AI 服务中，开源模型存储库 Hugging Face 在今年取得了一些最显著的增长，在 9 月 20 日至 21 日达到第 3 位，这很可能是受到模型发布的影响。Google 的专用 AI 产品表现平平：DeepMind 在 5 月达到顶峰，排在第 12 位，而 AI Studio 在 9 月中旬短暂进入前 20 位。

ElevenLabs（AI 语音生成）在高峰时段达到第 13-14 位，而 Poe（Quora 的多机器人聚合器）则从第 11 位下降到第 18 位。Meta AI 仍未进入前十榜单，仅在 8 月零星出现，并在 10 月至 11 月再次零星出现。

在更大的综合排名中查看生成式 AI 服务趋势时，一些显著趋势包括：

• ChatGPT 在总体域排名中持续稳步上升。在 2022 年底推出后，该应用在 2023 年初排名在 200 位左右，并在年底逼近前 100 位。在返校季和复工潮的助力下，该产品于 2024 年底跻身前 50 位。2025 年，其排名从第 51-60 位开始，并在 11 月 25 日达到顶峰，排在第 33 位，且在工作日排名持续上升。

  

• 截至 11 月底，ChatGPT 的排名紧随 X 之后（排名在第 26-29 位之间），领先于 Discord、Pinterest 和 Reddit。对于这项三年前还不存在的服务来说，这是一个重要的里程碑。

• 其他 GenAI 服务的整体排名也在上升，但没有任何服务能与 ChatGPT 的发展势头相提并论。Gemini 在三月中旬进入前 500 位后迅速上升，并在 11 月 24 日达到第 133 位的峰值。Claude 在一月份仅略高于 500 位，12 月 2 日达到第 155 位，并且从八月起一直保持在前 200 位的位置。Perplexity 在 2025 年初从大约第 450 位猛增至 10 月 19 日的峰值第 155 位，并在 11 月份徘徊在第 160 位左右。Grok 在 11 月 18 日达到第 223 位。

报告指出，全球估计有超过 50 亿人使用社交媒体，而且这一数据还在不断增长。Facebook 仍是全球主导平台，但本次排名中最大的变化是 Instagram 取代 TikTok 占据了第二的位置。这些平台，以及 Facebook，都跻身十大最热门的网际网路服务之列。

1. Facebook
2. Instagram ▲
3. 抖音 ▼
4. Snapchat ▲
5. 领英 ▲
6. X / Twitter ▼
7. 快手 ▲
8. Discord ▼
9. Pinterest
10. Reddit

Instagram 和 TikTok 自五月起互换排名，六月下旬起，Instagram 稳居第二，且地位无可争议。Snapchat 在 3 月份跃居第 4 位，取代了 X。X 年底排在第 6 位，在我们的排名中首次落后于 LinkedIn。Discord 和 Reddit 都短暂地达到第 7 位，然后分别稳定在第 8 位和第 9-10 位左右。

受拉丁美洲和其他新兴市场增长的推动，Kwai（在中国称为 Kuaishou）从 2024 年底的第 8 位升至 2025 年的第 7 位。中国短视频平台目前在巴西社交媒体类别中排名第二（仅次于 Facebook），在巴西总排名中位列第三。

快手在两个主要新兴市场，即巴西（第 3 位）和印度尼西亚（第 9 位）跻身前十榜单。其还在叙利亚排在第 15 位，在哥伦比亚排在第 18 位，以及在埃及排在第 20 位。除此之外，该服务在多米尼加共和国（第 25 位）、圭亚那（第 26 位）、阿曼（第 28 位）和阿根廷（第 30 位）等市场表现出显著的影响力。

我们的全球排名也突显出前 20 榜单中有几个非西方平台。抖音（TikTok 的中国版）连续第二年保持在第 11 位。VK（常被称为俄罗斯的 Facebook）保持在第 12 位，而快手旗下的东南亚 TikTok 竞争对手 SnackVideo 排在第 13 位。在 1 月份美国短暂的 TikTok 禁令期间获得关注的小红书 (RedNote) 排在第 14 位。

纵观 X 的微博客竞争对手，没有其他竞争对手获得显著发展。Meta 的微博客应用 Threads 在任何时候都未进入前 20 榜单，并且在 1 月 30 日美国禁用 TikTok 期间，Bluesky 仅短暂出现过。Tumblr 在今年大部分时间位列前 20 位，Mastodon 服务器在 10 月的大部分时间也位列其中。

基于订阅的内容平台 OnlyFans 在 5 月至 8 月初持续出现在前 20 榜单中（第 19 位左右），但在下半年有所下降。以下是 2024 年的社交媒体前十榜单：

让我们抛开社交媒体类别，看看这些平台在我们的综合排名中的表现，不同服务之间的差距更大。

X 替代方案的 DNS 存在受到限制。Mastodon（聚合服务器）表现最佳，一直稳定在第 208 位到第 248 位之间，并且周末的流量更高。Bluesky 在 5 月份左右达到约第 240 位的峰值，但在今年大部分时间里排名有所下降。随着美国举行期中的州和地方选举，其排名在 11 月 4 日出现显著上升（第 229 位）。这与 2024 年美国总统大选后的模式类似，当时 Bluesky 在选举日前后表现更好，并在 11 月 14 日达到顶峰，排在第 193 位。

Threads 在两个平台上均表现落后，6 月份峰值排名第 279 位，但总体排名在第 360 位左右。（注意：Threads 使用 Meta 的共享基础设施，因此部分图片可能从 Facebook/Instagram 域加载，这可能会减少其独立的 DNS 占用量。）

总体排名中的使用模式：

• 工作日与周末趋势：X、LinkedIn、Snapchat 和 Discord 在工作日表现更好，而 Kwai、Pinterest、Tumblr 和 OnlyFans 在周末表现最佳。LinkedIn 在周一至周三的排名最高，而 Tinder 仍然延续了周日达到峰值的模式。

• 增长案例：Reddit 在 2025 年全年保持在前 50 位（相较于 2024 年有所提升），在五月之后稳定在第 34-40 位之间，并在周一至周四表现最为出色。快手在下半年表现也很强劲，九月份达到顶峰，排在第 28 位。

• 下降：Quora 延续了 2024 年的下降趋势，排名从第 160 位左右跌出前 200 位。Tinder 和 Tumblr 也呈现类似的趋势，排名均跌至第 200 位以下。4 月至 6 月，OnlyFans 一直保持在前 200 位内，但在下半年有所下滑。

• 事件驱动的流量激增：Instagram 在 5 月中旬至 6 月中旬的几天内排在第 4 位。X 的排名在 3 月 2 日 Oscar 获奖期间达到顶峰，而 2024 年的顶峰排名为第 12 位。11 月 30 日，黑色星期五当周的周日，Pinterest 的流量激增。

每个网络周和黑色星期五都会提醒我们，电子商务在全球互联网流量中已变得多么重要。在该类别中，Amazon 在 2025 年仍是无可争议的领导者，但最强劲的势头来自于新的参与者，他们现已进入前三名：Shopee（2015 年在新加坡推出，在东南亚很受欢迎）和中国的 Temu（2022 年扩展到美国）。与此同时，2024 年排名前三的淘宝和速卖通的排名均有所下降，分别降至第 5 位和第 10 位。

1. Amazon
2. Shopee ▲
3. Temu ▲
4. Shopify
5. 淘宝 ▼
6. eBay ▲
7. 阿里巴巴 ▼
8. Shein
9. Mercado Libre
10. 速卖通 ▼

2025 年初，Shopee 和淘宝争夺第二的位置，但从四月中旬到七月初，Temu 一度超越了两者。从 7 月开始，Shopee 一直稳居第二，Temu 则稳定在第三的位置。2024 年，Shopee 略低于前 10 位，Temu 排在第 5 位。

Shopify 也巩固了其市场地位。其年初排在第 6 位，自 7 月以来一直稳定保持在第 4 位，与 2024 年的排名相同，但现在领先于淘宝和速卖通，仅落后于 Shopee 和 Temu。

eBay 表现出更明显的恢复：在 2024 年末排在第 7 位（2023 年排在第 3 位）后，其在今年年初在第 3 位和第 6 位之间波动，最终稳定在第 6 位。Shein 保持在第 8 位，与 2024 年持平，并持续超越 Mercado Libre（第 9 位）。

排在前十榜单之外的是俄罗斯的 Wildberries，其后是沃尔玛和日本的乐天。

纵观更广泛的总体排名，有几个模式非常突出：

• 亚马逊的发展轨迹与 2024 年类似。7 月之后在第 9 位和第 10 位之间波动，在黑色星期五当周升至第 8 位，并在 11 月 29 日（黑色星期五的第二天）达到顶峰，排在第 7 位。该服务继续在星期日表现更佳。

• Shopee 在今年大部分时间都保持在第 50 位左右，在双十一（11 月 11 日）的表现优于黑色星期五，达到了第 46 位（对比黑色周五第 48 位)。Shopify 在 11 月缩小了差距：其表现最好的一天是 11 月 28 日的黑色星期五，在 11 月 6 日也达到第 49 位。Shopify 在工作日的表现持续走强。

• Temu 以低成本市场模式而闻名，在 5 月 18 日（2025 年欧洲歌唱大赛决赛次日）达到顶峰，排在第 36 位。该网站年初时排名接近第 60 位（对比2024 年初未进入前 100 位），并在 2025 年底排在 50 左右。黑色星期五对其排名没有明显影响。

  

• Shein 今年表现更加稳定，在 2024 年险些未能进入前 100 位之后，排名保持在第 80 位到第 90 位之间。11 月 29 日达到顶峰，排在第 7 位。Temu 在 2024 年的表现与 Shein 相似，但在 2025 年的表现明显超过了 Shein。

• eBay 的一致性得到提升，全年排名稳定在第 46 位到第 62 位之间（（在 2024 年保持在前 70 位之外）。在 4 月 15 日达到顶峰，排在第 42 位。与往年一样，“黑色星期五”的影响不大，这反映了二手市场季节性需求的下降。

• Mercado Libre 在 2025 年实现了显著增长，并从 9 月起进入前 100 位。与 2024 年一样，其表现最好的一天是黑色星期五（11 月 28 日），达到第 82 位（对比2024 年排在第 100 位）。

其他零售服务在“整体”类别中也受到了黑色星期五当周的影响：

• Adidas 进入前 250 位，在网络星期一达到第 229 位，在黑色星期五达到第 249 位（与 2024 年类似）。

• Nike 的排名略有下滑，在黑色星期五达到峰值，排名第 287 位。

• Target 在网络星期一的排名达到第 117 位，比 2024 年的最高排名第 127 位有所提高。该服务在星期六表现最佳。

• Walmart 的表现略好于 Target，在 8 月 23 日至 24 日的周末达到顶峰，排在第 101 位，并在感恩节前达到第 120 位。

• Ikea 的模式与 2024 年几乎相同，在 6 月 2 日至 3 日达到顶峰，排在第 242 位。

尽管行业整合加剧，视频流媒体仍然是 2025 年最稳定的类别之一。前三榜单连续第三年没有变化：YouTube 排名第一，其次是 Netflix 和 Twitch。

1. Youtube
2. Netflix
3. Twitch
4. Roku
5. Disney Plus
6. Prime Video
7. Vimeo
8. Pluto TV ▲
9. Plex TV WW
10. HBO Max ▲

HBO Max 是今年上升幅度最大的平台，首次进入前十榜单，并受益于《小丑回魂：欢迎来到德里镇》的新剧集，在网络星期一（12 月 1 日）达到第 8 位。前十榜单中唯一的变化是 Pluto TV，这是一个由广告支持的免费服务，其排名超过了 Plex TV。

在付费服务中，Netflix 仍是明显的领导者，其次是 Disney Plus（第 5 位）和 Prime Video（第 6 位）。Hulu（第 11 位）、Peacock（第 15 位）、Apple TV+（第 17 位）和 Paramount Plus（第 20 位）均未进入前十榜单。Roku 一直保持在第 4 位，并在黑色星期五这一周短暂超过了 Twitch。Disney Plus 全年都保持在第 5 位，但在 3 月至 6 月期间的几个周末攀升至第 4 位，大约在 《夜魔侠：重生》首映以及之后的《安多》第二季首映期间。

2025 年期间的前十榜单：

在这一年中，主要的首映明显推动了整体排名的提升：

• YouTube 在 7 月 5 日（MrBeast 发布“世界上最快的汽车与猎豹的速度比较！”当天）排在第 5 位。

• Netflix从 6 月下旬开始，周末排名稳定在第 11 位左右，并在《怪奇物语》第五季发布后于 11 月 30 日达到顶峰，排名第 10 位。

• Disney+ 的排名介于第 47 位和第 60 位之间，其最强劲的峰值可能与《夜魔侠：重生》有关。

• 在 11 月 22 日至 23 日以及 11 月 30 日《居家男人》第三季上线后，Prime Video 的排名达到第 53 位。

  

• HBO Max 在我们的综合排名中一直接近前 100 位，并在 11 月 23 日《小丑回魂：欢迎来到德里镇》发布期间达到顶峰。Hulu 在网络周也有类似表现，排名达到第 132 位。Paramount+ 在 11 月底的周末表现优于 Peacock，于 11 月 23 日和 30 日达到顶峰，排在第 197 位。

与往年一样，大多数付费流媒体平台在周末，尤其是周日表现最为强劲，这反映了全球的观看习惯。

新闻机构继续为公众提供信息，尽管其可见性和流量似乎日益被 AI 驱动的搜索和摘要工具削弱（我们在 2025 年 8 月的博客文章中探讨了这一趋势）。这一类别，包括传统新闻媒体和新闻聚合器，着重指出了 2025 年的几个转变。

1. Globo
2. ESPN ▲
3. BBC ▼
4. NY Times ▼
5. CNN ▼
6. Fox News ▼
7. Yahoo Finance
8. Google News ▲
9. NewsBreak ▲
10. Times of India ▲

横跨电视、广播和印刷领域的巴西媒体巨头 Globo，连续第三年稳居榜首。ESPN 排名升至第二，超越了 BBC（第 3 位），后者在全球以 43 种语言运营。由于 ESPN 的排名上升，纽约时报（第 4 位）、CNN（第 5 位）和 Fox News（第 6 位）的排名均下降了一位。

Google 新闻升至第 8 位（具有明显的周末倾向），而美国本地新闻聚合应用 NewsBreak 在年底表现突出，并在 11 月的几天内达到第 7 位。

《卫报》不在前十榜单中，在加拿大 3 月 领导权选举期间曾短暂排在第 10 位，而 RT（俄罗斯官方媒体）从年初的前 10 位下降到年底的第 20 位左右。7 月 24 日至 27 日这是一场意义重大的美国-欧盟关税相关贸易谈判期间，《金融时报》的排名飙升至第四。

在更广泛的总体排名中，重大的地缘政治、政治和体育赛事导致新闻流量激增。去年，激增是由选举推动的。

• 特朗普就职典礼（1 月 20 日至 21 日）：美国有线电视新闻网 (CNN)、《纽约时报》(NYT) 和福克斯新闻的收视率均显著上升。

• 美国-英国贸易协议宣布与胜利日 80 周年纪念日（5 月 8 日）：今年的最高峰：CNN（第 126 位）、NYT（第 129 位）、Fox News（第 164 位）、BBC（第 106 位）。

• 以色列-伊朗冲突（冲突开始于 6 月 13 日，当时以色列对伊朗发动了轰炸，结束于 6 月 24 日）：BBC 达到年度峰值（第 101 位），CNN（第 125 位）、NYT（第 136 位）和 Fox News（第 160 位）也显示出平行的峰值。

下图显示了围绕五月和六月峰值的 BBC、CNN、《纽约时报》和福克斯新闻的排名。

• 美国期中选举日（11 月 5 日）：CNN （第 157 位）、NYT （第 169 位）和 Fox News （第 191 位）均录得小幅上升。

区域动态也十分突出。Globo 在 2 月 2 日的巴西超级杯决赛期间达到顶峰，排名在第 60-77 位之间。ESPN 也出现了类似的事件驱动型激增，在 4 月 26 日 NFL 选秀和 NBA 季后赛期间达到第 82 位；9 月 28 日排名第 79 位，当时 NFL 第 4 周与 MLB 常规赛激动人心的最后一天重合；10 月 26 日排名第 79 位，因为 F1 墨西哥城大奖赛恰逢 NFL 第 8 周和 NBA 新赛季的第一周，促使球迷同时关注多个联赛。

2025 年下半年，大多数美国主要新闻媒体的总体排名逐渐下降，从年初的较高位置下降至 200 位左右。这表明，随着 AI 工具和社交平台日益成为用户获取新闻的渠道，消费模式正在发生转变。

消息传送仍是互联网通信的核心部分，并且该类别持续成熟，顶级企业保持领先地位。WhatsApp 连续第四年稳居第一，而 2025 年最显著的变化是 Signal 排名上升至第 5 位，这反映了人们对注重隐私的工具的需求日益增长。

（注：Apple 的 iMessage 未包括在内，因为该服务没有唯一的域名。无法单独衡量社交平台（Instagram 私信、X 消息、Snapchat）内的消息功能，这些功能与各自社交媒体平台的其他功能不同。

1. WhatsApp
2. QQ
3. Telegram
4. Rakuten Viber
5. Signal ▲
6. 微信 ▼
7. LINE
8. Messenger ▲
9. Zalo.me ▲
10. KakaoTalk ▲

得益于游戏、移动支付和通信工具的综合生态系统，中国服务 QQ（腾讯 QQ）连续第三年位列第二。Telegram（第 3 位）和 Rakuten Viber（第 4 位）保持稳定，仍然是东欧、亚洲和中东地区的主要平台。

从 10 月起，开源加密消息服务 Signal 超过中国应用微信，排名从 10 月起稳居第 5 位，扭转了 2024 年的排名。其兴起突显了人们对开源、端到端加密消息传递日益增长的兴趣，尤其是在注重安全的社区中。亚洲应用也表现强劲：来自日本的 LINE 仍然排在第 7 位，而越南的 Zalo.me 排在第 9 位，韩国的 KakaoTalk 排名下降至第 10 位（2024 年底排在第 8 位）。Meta 的 Messenger 在 6 月之后排名达到第 8 位。

整体排名中的规律：

• WhatsApp 保持了总排名第 9 位，并在 1 月和 11 月的几天内达到第 8 位。

• Telegram 在 7 月 1 日达到顶峰，排在第 56 位，恰逢中东发生重大地区动乱。

• 微信在年初时接近前 100 位，到 12 月份左右下滑至第 130 位。

尽管“元宇宙”新闻逐渐从公众的关注中消失，游戏仍继续为互联网流量提供大量流量。Roblox 连续第三年在该类别排名中占据主导地位，而 2025 年最大的转变是 PlayStation 从 5 月开始从 5 月起超过 Xbox，跃居第二。

1. Roblox
2. PlayStation ▲
3. Xbox / Xbox Live ▼
4. Epic Games / Fortnite ▼
5. Steam ▼
6. Electronic Arts
7. Blizzard
8. Minecraft ▲
9. Riot Games /《英雄联盟》▼
10. 任天堂 ▲

Steam 排在第 4 位，在 2024 年意外上升后延续了强劲表现。该服务在工作日和关键发布期间表现最佳，并在三月、四月和七月的数天内达到第三位。其表现最佳的一天是 4 月 24 日，达到第 2 位，恰逢《饿狼传说：狼之都》发布。

Electronic Arts（第 6 位）和 Blizzard（第 7 位）保持稳定，同时《我的世界》从第 9 位攀升至第 8 位，周末表现强势。Riot Games/《英雄联盟》跌至第 9 位，Nintendo 回到前十榜单。Meta 的 Oculus 连续第二年未能进入前十榜单，在总体排名中从大约前 100 位下降到接近第 130 位。

以下是 2025 年的前十榜单：

总体排名中的使用模式：

• Roblox 在 7 月 6 日的年度 Hatch 活动（7 月 2 日至 12 日）期间，排名达到最高的第 15 位，并且在周末的排名持续上升。

• PlayStation 在黑色星期五当周（11 月 22 日 - 23 日和 29 日 - 30 日）排名达到第 30 位，是今年表现最佳的一次。

• Minecraft 保持在第 87 位到第 120 位之间，可预见其在周末出现峰值。

• Oculus 在 2025 年销量有所下降，从大约前 100 位下降到年底的约第 130 位，反映了主流 VR 普及速度放缓。

游戏平台，例如 Roblox、Xbox、Epic Games/Fortnite、Steam 和 PlayStation，均显示出显著的周末效应，多数服务在周六和周日的排名比工作日高 20-40 位。这种模式体现了游戏作为一种休闲驱动型产业的地位。

尽管传统银行和税务工具仍然存在，即使在 2025 年，数字优先的金融服务仍然占据主导地位。爱尔兰裔美国支付平台 Stripe 在 2023 年超越 PayPal 后，连续第三年蝉联第一。

1. Stripe
2. TradingView
3. 支付宝
4. 贝宝
5. Nubank
6. Binance
7. Banco do Brasil ▲
8. Intuit ▲
9. Google Pay ▲
10. OKX ▲

2025 年排在前六位与 2024 年末相比排名没有变化。PayPal 通常排在第 4 位，在 2 月底 3 月初的几天内短暂升至榜首。交易者和投资者平台 TradingView 稳居第二（工作日表现更好），并在 1 月 13 日达到顶峰。当日，由于 12 月强劲的就业数据重新引发了对持续通货膨胀的担忧，美国市场暴跌。中国的移动和在线支付平台支付宝保持在第三位。

今年，巴西在线银行业务持续扩张的趋势再次显现。全球最大的数字银行和拉丁美洲主要金融集团 Nubank 连续第二年位列第五。巴西银行首次进入前十榜单，另一家巴西银行 Bradesco 跌出榜单。

Binance 保持其第 6 位的位置，Coinbase 跌出前十榜单。Intuit 今年进入前十榜单，在美国纳税日期间（4 月 14 日至 15 日）达到顶峰，排名第 6 位。在年底强劲表现的推动下，Google Pay 和加密货币交易所 OKX 也首次进入前十榜单。

在总体排名中，其他金融服务方面的趋势：

• Stripe 在今年晚些时候表现最佳，在光棍节（11 月 12 日）的次日排在第 70 位，在网络星期一（12 月 1 日）排在第 71 位。该服务在周末的表现持续提升，且整体排名呈现稳定上升趋势，从 80 位左右上升至接近 70 位。

• PayPal 在黑色星期五当周排名更高，在 11 月 29 日飙升至第 82 位。然而，其整体峰值出现在今年早些时候的 3 月 2 日，达到第 73 位。

• Nubank 在巴西狂欢节（2 月 28 日至 3 月 5 日）前几天表现最佳，在 2 月 22 日达到第 85 位。该服务的排名也在 11 月 28 日“黑色星期五”飙升至第 96 位。

除了我们的金融服务类别之外，我们还单独跟踪以加密货币为中心的服务。在经历了数年动荡之后，加密生态系统在 2025 年相对稳定了下来。Binance 继续在该类别中领先，而最强劲的势头来自 OKX，从 9 月开始稳步上升，在年底结束时位列第二，超过了 Coinbase，后者在 2024 年保持着该位置。

1. Binance
2. OKX ▲
3. Coinbase ▼
4. CoinGecko ▲
5. 2miners.com ▼
6. CoinMarketCap ▼
7. Bybit
8. MEXC ▲
9. Exodus
10. Bitget ▲

加密货币数据平台 CoinGecko 从第 6 位上升至第 4 位，2miners.com 则下滑至第 5 位。最后三名入榜者都是前十榜单的新晋者：

• MEXC（第 8 位）：一家以现货和期货交易闻名的全球性加密货币交易所。

• Exodus（第 9 位）：一款专注于易用性和自我托管的多资产加密钱包。

• Bitget（第 10 位）：一家加密货币交易所，专门提供衍生产品和跟单交易（用户自动复制经验丰富的交易者的交易）功能。

1 月 20 日，唐纳德·特朗普举行美国总统就职仪式，导致各平台加密货币流量在 2024 年 11 月大选后的高兴趣基础上进一步激增：

• 1 月 20 日，Binance 达到顶峰，排在第 95 位。

• Coinbase 在同一天达到第 121 位。

• OKX 早些时候达到顶峰，在 1 月 19 日达到第 157 位。

CoinGecko 的综合排名呈现明显的下降趋势，年初接近前 200 位，年末位于第 270 位左右。Binance 和 Coinbase 在 2025 年全年保持相对稳定，而 OKX 从 9 月开始呈现显著增长，排名上升至 150 位左右。

在主要类别之外，一些服务显示出显著的流量峰值。

与重大事件、文化热点和季节性行为相关：

危机与实时追踪

• FlightRadar24 在 6 月 13 日至 15 日以色列空袭伊朗核设施期间飙升至第 260 位，反映全球对实时空域中断跟踪的需求增加。

  

• 10 月 27 日，由于威力极强的 5 级飓风“梅利莎”增强并威胁加勒比海，NOAA Tides & Currents 达到了第 300 位。

娱乐与媒体

• 与 2024 年类似，Spotify 在 2025 年全年稳定排名第 16–19 位。该服务在九月和十一月表现最为出色，在那几个月的大部分时间排在第 16 位。（我们的数据集截止到 12 月 2 日，因此 12 月 3 日发布的 Spotify Wrapped 的影响未被收录。）

• IMDb 在 9 月 14 日达到顶峰，与黄金时段艾美奖颁奖典礼同时举行。

• 维基百科排名通常在第 22 位到第 24 位之间，但在 7 月 5 日达到顶峰，排在第 19 位，同一天发生了一个热门事件：一本 1999 年漫画中失败的“2025 年 7 月 5 日灾难预言”，导致“日本什么都没有发生”在中国新浪微博上登上热搜榜首。

运动

• 掘金对阵快船一场激动人心的加时赛让该联盟的排名在 4 月 19 日（NBA 淘汰赛开幕日）达到第 237 位。

• 国际足联罕见地出现在前 500 位中，11 月 17 日，国际足联和美国国务院宣布为 2026 年世界杯门票持有者启用国际足联优先预约安排系统 (FIFA PASS) 时，其排名达到第 373 位的峰值。

• GitHub 在今年大部分时间保持在第 27 位到第 36 位之间，与 2024 年的表现相符，突显了其作为核心开发基础设施的地位。

在我们“年度回顾”微站点上针对特定国家和地区的热门互联网服务榜单中，我们看到 Google 在几乎所有地点都位列榜首（由 Facebook 主导的利比亚成为罕见的例外）。除了我们的综合榜单之外，今年我们还将分享以下特定类别榜单：社交媒体、生成式 AI 和消息传送。

以下是特定国家/地区综合排名中一些其他值得注意的亮点：

AI 在新兴市场的优势

ChatGPT 在传统技术中心以外的地区表现出乎意料地好，在吉尔吉斯斯坦、索马里、阿拉伯联合酋长国和埃塞俄比亚等国家进入了前 30 位，这表明 AI 正在广泛的市场中迅速普及。

Google Gemini 在新兴地区也显示出显著的吸引力。在埃塞俄比亚（第 94 位）、斯里兰卡（第 105 位）、危地马拉（第 118 位）、卢旺达（第 122 位）和泰国（第 124 位）的排名最高；在秘鲁、中国台湾、尼泊尔、越南和马拉维也有类似的情况（Gemini 的排名在第 128-137 位）。 

Facebook 在许多国家/地区占据前两名的位置，但区域性参与者也建立了稳固的地位。快手在巴西位列第三，并在拉丁美洲和中东地区表现出色。Instagram 在中亚和海湾地区的部分区域排名最高，而 TikTok 则在拉丁美洲、非洲和东南亚的广大区域占据主导地位。

Snapchat 在伊拉克、利比亚、巴勒斯坦和巴基斯坦等市场表现最佳。LinkedIn 显示出其双重特性，不仅在澳大利亚和法国等发达经济体中名列前茅，而且在包括孟加拉国、秘鲁和沙特阿拉伯在内的新兴市场中也表现出色。

Netflix 在拉丁美洲的表现最为强劲（在多个国家/地区排名第 8-10 位），但在亚洲和欧洲的大部分地区排名较低，而 Spotify 在这些地区表现最佳，尤其是在北欧和南欧。

消息传送显示出明显的地域差异。WhatsApp 在加勒比地区、非洲和亚洲部分地区占据领先地位；Telegram 在东欧和中亚地区排名最高；Signal 在注重隐私的市场（如乌克兰和瑞士）获得了市场份额；Viber 则继续在巴尔干地区占据主导地位。

按国家/地区划分的 GenAI 亮点包括：

• ChatGPT 在几乎所有国家/地区的生成式 AI 类别中位列第一，只有一个例外：委内瑞拉，Google Gemini 在该国位居榜首。

• Google Gemini 在拉丁美洲（包括巴西、墨西哥和哥伦比亚）和东南亚（泰国、印度尼西亚）位列第二，这反映了 Google 在移动优先的新兴市场中的平台实力。

• Perplexity 在欧洲（德国、法国、西班牙）位列第二，在主要英语市场（美国、英国、澳大利亚）位列第三，表明其对信息搜寻用户具有强大的吸引力。

• Claude 排在第 3-5 位，表现出选择性优势，在西欧（格鲁吉亚、瑞士）以及德国、法国或日本等发达市场表现最佳，这与其对企业和开发者的关注重点相符。

• 瑞典氛围编码平台 Lovable 在安哥拉一个国家的 GenAI 类别中排在第 10 位。该服务在瑞典和斯洛文尼亚排在第 16 位，在巴西排在第 17 位。

ChatGPT 仍是全球市场的领导者，但排在第二位的竞争呈现出高度的区域性：Google Gemini 在新兴市场表现突出，Perplexity 在欧洲市场占据优势，而 Claude 在技术更发达的经济体中更受欢迎。这提醒我们，互联网包含着受文化、基础设施和经济环境塑造的大量本地化行为。

2025 年，互联网的演变既有稳定的一面，也有颠覆性的一面。Google、Facebook 和 Instagram 依旧在我们的综合排名中占据主导地位，但今年最引人注目的事件是生成式 AI 的快速发展。ChatGPT 跻身全球前 40 位，而 Claude、Gemini、Perplexity 和 DeepSeek 成为该领域中可靠的竞争者，该领域在三年前几乎还不存在。到十一月底，Gemini 已经在我们的 GenAI 排名中占据第二的位置，直接与 ChatGPT 争夺领先地位。

社交媒体持续呈现碎片化趋势：Instagram 整体排名上升至第 5 位，而 X 跌出前 20 榜单。同时，快手等新兴平台在拉丁美洲、中东和东南亚等地获得了显著增长。在电子商务领域，Shopee 和 Temu 与亚马逊一同跻身全球前三，取代了老牌的中国电商平台。加密货币在早前波动后趋于稳定，美国总统就职典礼等事件前后流量激增。

全球动态引发了新闻和其他实时信息服务的协同激增，突显了现实世界的事件对在线行为的快速影响。

这些排名反映了我们的团队持续进行的资料验证和方法论的精进。我们欢迎您针对未来版本希望探索的类别提供反馈和建议。

感谢数据科学家 Sabina Zejnilovic，她在收集互联网服务数据的过程中发挥了关键作用。