更新日志

Cache Rules 现在在表达式过滤器中支持 Bot management 字段和 ip.src.asnum 字段。您现在可以构建区分自动流量和人类流量的缓存策略，或者根据自治系统编号（ASN）对缓存行为进行细分。

这允许您对已验证的 Bot、高风险流量或特定网络运营商应用不同的缓存策略，而不会影响合法的用户请求。例如，您可以为怀疑是 Bot 流量的请求设置较短的缓存 TTL，或者对来自特定 ASN 的请求完全绕过缓存。

以下字段现在在 Cache Rules 表达式中可用：

Cache Rules 表达式支持将这些字段与其他标准结合使用。以下示例为来自高风险 Bot 或意外 ASN 的 API 请求设置较短的缓存 TTL：

(http.request.uri.path contains "/api/" and cf.bot_management.score lt 30)
or
(http.request.uri.path contains "/api/" and not ip.src.asnum in {12345 67890})

要了解更多信息，请参阅 Cache Rules 文档 和 字段参考。

内部 DNS 现在已正式发布。内部 DNS 在您已用于公共 DNS、Zero Trust 和应用程序服务的同一个全球网络和控制平面上，为私有网络提供权威和递归 DNS 服务。

• 整合 DNS 运营。 公共和私有 DNS 运行在同一个平台上，拥有统一的 API、审计跟踪和策略设置入口。
• 简化水平分割 DNS。 内部和外部解析被定义为共享区域上独立的视图，并从单个控制平面进行管理 — 因此无需排查配置偏差。
• 将 Zero Trust 扩展到 DNS。 解析器策略决定哪些用户和设备针对哪个视图进行解析，并由已经监管您其余流量的同一个 Gateway 来执行。

设置内部 DNS 需要三个步骤：创建区域、创建视图并定义解析器策略。

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

内部 DNS 已包含在面向企业级客户的 Cloudflare Gateway 中。要开始使用，请参阅 Internal DNS documentation。

Cloudflare Web Analytics (真实用户监控) 已经推出了性能优化，以显著提高账户级仪表板的稳定性和加载速度。

对于较大的账户（拥有超过 100 个 Web Analytics 站点），加载聚合的账户级视图通常会失败，因为大规模的并行查询处理会导致超时或意外的界面错误。此更新优化了如何查询大容量多站点数据，以减少错误并提供更敏捷的仪表板体验。

拥有最多 1,000 个站点的账户现在将能够加载此账户级聚合视图，而不会遇到误导性的错误。

如果您的账户拥有超过 1,000 个站点，由于处理限制，我们目前无法对此数量进行聚合，但您现在将看到清晰的错误提示和说明，引导您过滤到您希望查看其数据的相关站点。

Cloudflare 仪表板中的 DNS Firewall 页面已焕然一新，将以前仅限 API 的多项设置引入到 UI 中，并使您查看和管理 DNS Firewall 集群的方式更加现代化。

• 仪表板中提供更多设置：以前只能通过 API 配置的集群选项（如攻击缓解、速率限制、否定 TTL 和解析器子网）现在可直接在仪表板中使用。
• 更佳的表格体验：重新设计了 DNS Firewall 集群表格以一目了然地呈现集群详细信息，支持调整列大小，以及显示或隐藏列以根据您的工作流定制视图。
• 全新的创建和编辑 UX：添加和编辑集群现在使用现代化的表单，将相关设置分在组里，使配置更快速、更清晰。

作为现有订阅的一部分，向所有 DNS Firewall 客户提供。

在 Cloudflare 仪表板中，转到 DNS Firewall 页面。

有关更多信息，请参阅 DNS Firewall。

您的源站可以通过返回 Vary ↗ 响应标头，为同一个 URL 提供不同的响应 —— 例如根据 Accept-Language 提供不同的语言，或者根据 Accept 提供不同的格式。Cloudflare 的缓存现在直接在 缓存规则（Cache Rules） 中遵循该标头，因此同一个 URL 可以保存多个缓存版本，并且每个请求都与正确的版本进行匹配。以前必须绕过缓存以保持正确性的内容现在可以被缓存，遵循标准的 HTTP 缓存行为 ↗。

您的源站现在通过在其 Vary 响应中列出哪些请求标头重要来决定它们，而您则控制 Cloudflare 如何处理每一个。当您使用缓存规则启用了 Vary 且响应包含 Vary 标头时，列出的请求标头将成为缓存键的一部分。

对于您的源站变化所依赖的每个标头，选择以下三个操作之一：

• 更高的缓存命中率：normalize 将语义上等效的标头视为一个版本。例如，Accept-Language: en-US, fr;q=0.8 和 Accept-Language: fr;q=0.8, en-GB 都解析为相同的缓存键，因此您可以从缓存而非源站提供更多请求的服务。
• 正确的内容协商：请求始终接收与其标头相匹配的缓存版本，从而使语言和格式变体保持准确。
• 无需更改源站或 Worker：如果您的源站已经发送 Vary，您完全可以在缓存规则（Cache Rules）中配置该行为。
• 符合标准：缓存键计算遵循 RFC 9111，并且 Vary: * 像 RFC 9110 要求的那样继续绕过缓存。

缓存规则中的 Vary 适用于所有计划（免费版、专业版、商业版和企业版）。对于 Workers 子请求中的每个请求控制，请使用 cf.vary 属性。

在 Cloudflare 仪表板 ↗ 的 Cache（缓存） > Cache Rules（缓存规则） 下配置 Vary，或通过 Rulesets API 进行配置。要了解 Vary 如何影响缓存键以及每个操作的工作原理，请参阅 Vary 和 缓存规则 Vary 设置。

Regional Services 现在支持 Regionalized IP Bindings，让您能够针对通过 Bring Your Own IP (BYOIP) 引入 Cloudflare 的前缀在 IP 层实现流量区域化。

Regional Hostnames 是按主机名对流量进行区域化，而 Regionalized IP Bindings 允许您将来自前缀之一的 CIDR 绑定（binding）到某个区域 —— 这非常适合地址映射部署以及任何您通过 IP 而非主机名寻址的服务。然后，Cloudflare 会在 TLS 终止后，仅在该区域的数据中心内处理发往这些地址的流量。

Regionalized IP Bindings 需要 Regional Services 和 Regional Services for BYOIP 的授权。请联系您的账户团队以启用它们。

要开始使用，请参阅 Regionalized IP Bindings。

Cloudflare 加速移动页面（AMP）和签名交换（SXG）支持已达生命周期终点。这些功能自 2025 年 10 月起就已被禁用，因此配置了这些功能的客户应该不会看到其流量有任何变化。

客户将无法再通过 API 或规则集配置 AMP/SXG。Zone API 将开始报错。包含 SXG 配置的规则集在移除 SXG 之前将无法保存。

当遇到无效路径或意外运行时错误时，Cloudflare Fonts 现在会将 /cf-fonts 请求转发到您的源站服务器，而不是直接返回 4xx 或 5xx 响应。此更新还添加了附加的输入验证以增强安全性。

Cloudflare 现在在 Cloudflare 边缘与您的源站服务器之间的连接上接受 ML-DSA ↗ (FIPS 204) 后量子证书。结合我们现有的 X25519MLKEM768 密钥协商，这使您能够在 Cloudflare 到源站的连接上建立端到端后量子身份验证。

ML-DSA 在两个面向源站的功能中得到支持：

• 经身份验证的源站拉取 (AOP) — 上传一个 ML-DSA 客户端证书，Cloudflare 将在向您的源站进行 mTLS 握手期间出示该证书。可在区域（zone）级别和每个主机名范围内使用。
• 自定义源站信任存储 (COTS) — 上传一个 ML-DSA 证书颁发机构，Cloudflare 在完全（严格）加密模式 下验证您的源站服务器证书时将信任该机构。

有关证书生成和设置指导，请参阅后量子签名；有关 Cloudflare 当前后量子部署状态，请参阅 Cloudflare 产品中的 PQC。

Cloudflare 现在针对企业级（Enterprise）账户在账户级别执行 DNS 记录配额。这些账户不再限制每个区域的配额，而是对其所有区域的记录总数设立配额，允许您根据需要随意在各个区域之间分配记录，而无需考虑每个区域的计划。公共区域和内部区域分别计算，每个区域的默认配额为 1,000,000 条记录。

没有账户级配额的账户不受影响：现有的每个区域配额与以前完全相同。

有关更多详细信息，请参阅 DNS records quota。

只要响应不可缓存，Cloudflare 现在就会返回 BYPASS 缓存状态，而不是像以前那样根据 Cloudflare 选择不缓存响应的原因而混合返回 BYPASS 和 MISS。

Cloudflare 可能拒绝缓存响应有多种原因 —— 例如，响应超出了您计划的 最大可缓存文件大小、源站发送了 Cache-Control: no-cache、private 或 max-age=0、响应包含 Set-Cookie 标头，或者请求包含 Authorization 标头。

以前，只有其中一些情况会返回 BYPASS。其他情况（例如响应超出最大可缓存文件大小）在每次请求时都会返回 MISS，无论 源站缓存控制（Origin Cache Control） 是开启还是关闭。因为该响应永远无法被缓存，所以每个随后的请求也会返回 MISS，这看起来与损坏的缓存没有什么区别，很难区分 Cloudflare 是在尝试缓存资产但失败了，还是故意选择不缓存它。

BYPASS 现在一致地表示 Cloudflare 拒绝缓存该响应，无论出于何种原因。MISS 专门保留用于在请求时未在本地缓存中的可缓存响应。

在此更改部署后，您应该会看到：

• MISS 率下降：不可缓存的响应不再计为缓存未命中。
• BYPASS 率上升：这些相同的响应现在报告为绕过（bypass）。
• 缓存命中率上升：命中率计算不再包含永远无法被缓存的不可缓存流量，从而为您提供更准确的缓存效果视图。

您的总请求量和源站流量没有变化 —— 只有缓存状态标签不同。

缓存状态标签是唯一发生改变的内容 —— 针对任何给定的响应，浏览器缓存 TTL 的处理与以前完全相同：

• 历史上因为 Cloudflare 拒绝缓存而返回 MISS 的响应（例如，超过最大可缓存文件大小的响应）现在返回 BYPASS，但继续应用浏览器缓存 TTL —— 就像它们被标记为 MISS 时一样。
• 历史上返回 BYPASS 并跳过浏览器缓存 TTL 的响应继续跳过浏览器缓存 TTL。

在两种情况下，应用浏览器缓存 TTL 的决定取决于 Cloudflare 不缓存响应的深层原因，而不是取决于新的 BYPASS 标签。

从今天开始，每个人都可以在 Cloudflare 仪表板中选择加入焕然一新的 DNS 记录页面。在接下来的几周内，这一新体验将首先成为 Free 计划用户的默认体验，随后是付费计划。

• 更佳的表格体验：可调整大小和隐藏的列、行固定、带有逻辑运算符 (AND/OR) 的高级筛选器、可配置的分页以及展开的输入字段（长值不再被截断）。
• 一流的移动端体验：响应式布局，配有触摸友好的卡片式 UI 以及适用于小屏幕的紧凑型控件。
• DNS 快速参考：直接在产品中提供有关 DNS、代理状态和 TTL 的简短解释，帮助用户在不离开页面的情况下配置记录。
• 现代前端：重构到 Cloudflare 的新 UI 框架上，这提高了性能并为未来的改进奠定了基础。

日期可能会根据推出期间收到的反馈而有所变化。

• 5 月 20 日 - 6 月 5 日：逐步推出到 Free 计划，然后是 Pro 和 Business 计划。
• 6 月 8 日 - 7 月 3 日：逐步推出到 Enterprise 计划。

一旦为您的账户启用了新体验，请在 Cloudflare 仪表板中的 DNS 记录页面顶部寻找反馈链接，并告诉我们您的想法。您的意见将帮助我们确定下一轮改进的优先顺序。

/cdn-cgi/rum 信标（beacon）端点现在对非 POST 请求返回 405 Method Not Allowed，而不是 404 Not Found。根据 RFC 9110 §15.5.6 ↗，响应中包含 Allow: POST, OPTIONS 标头。

以前，向此端点发送 GET 或其他非 POST 请求会返回 404，这具有误导性，因为它表明该端点不存在。新的 405 响应明确指出该端点存在，但仅接受 POST 请求。

Web Analytics 信标（beacon.min.js）已经对所有指标提交使用 POST，因此此更改不会影响信标的正常运行。针对 CORS 预检的 OPTIONS 请求继续照常工作。

欲了解更多信息，请参阅 Web Analytics FAQ。