更新日志

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 文档 和 字段参考。

在 2026 年 10 月 5 日，两项变更将在 Zero Trust Networks API 和 Cloudflare Tunnel API 中生效：移除经过 CIDR 编码的路由终点，且 tunnel list 和 get 响应将不再包含 connections 字段。如果您通过 API、cloudflared、Terraform 或其他集成管理私有网络路由或读取 tunnel 连接详情，请阅读以下部分中的变更说明并在移除日期之前完成迁移。

经过 CIDR 编码的路由终点已被弃用，转而使用目前已存在的基于标准 route_id 的终点。这两组终点都是通过 Cloudflare Tunnel 或 Cloudflare Mesh 路由私有网络（API 仍将 Mesh 节点称为 warp_connector）— 仅请求形状（request shape）发生了变化。

已弃用的终点（将于 2026 年 10 月 5 日移除）：

• 创建 tunnel 路由（CIDR 终点）：POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• 更新 tunnel 路由（CIDR 终点）：PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• 删除 tunnel 路由（CIDR 终点）：DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

替代终点：

• 创建 tunnel 路由：POST /accounts/{account_id}/teamnet/routes
• 更新 tunnel 路由：PATCH /accounts/{account_id}/teamnet/routes/{route_id}
• 删除 tunnel 路由：DELETE /accounts/{account_id}/teamnet/routes/{route_id}

1. 通过调用列出 tunnel 路由获取每个路由的 route_id，或者在首次使用替代终点创建路由时从响应中读取它。
2. 更新任何直接调用经过 CIDR 编码的终点的脚本、后端服务或 CI/CD 流水线。
3. 如果您使用 cloudflared tunnel route ip add | delete 命令管理路由，请将 cloudflared 升级到最新版本 ↗。
4. 如果您使用 Terraform 管理路由，请确保您使用的是最新版本的 cloudflare_zero_trust_tunnel_cloudflared_route ↗ 资源以及 Cloudflare Terraform 提供商 ↗。

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"comment": "Updated comment for this route."}'

curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

自同一天起，将从 Cloudflare Tunnel 和 Cloudflare Mesh 节点（cfd_tunnel 和 warp_connector API 资源）的 list 和 get 响应中移除 connections 数组。请查询专用的连接终点，而不是从 tunnel 或节点对象中读取该字段。

这会影响：

• GET /accounts/{account_id}/cfd_tunnel — 从 result 中的每个项目中移除 connections
• GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — 从 result 中移除 connections
• GET /accounts/{account_id}/warp_connector — 从 result 中的每个项目中移除 connections
• GET /accounts/{account_id}/warp_connector/{tunnel_id} — 从 result 中移除 connections

从特定于 tunnel 的连接终点获取连接详情，而不是从 list 或 get 响应中解析。对于 Cloudflare Tunnel，请调用 GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections。对于 Cloudflare Mesh，请调用 GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections。

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

更新任何从 tunnel list 或 get 响应中解析 connections 的仪表板、监控脚本或自动化。cloudflared 和 Cloudflare Terraform 提供商不读取此字段，因此它们的这一部分更新不需要做任何更改。

• 响应更小、速度更快。 具有许多连接的 Cloudflare Tunnel 和 Cloudflare Mesh 节点不再膨胀每次 list 和 get 调用 — 仅在您需要时才获取连接详情。
• 静态或标识路由的单一方式。 统一使用 route_id 消除了对路径中 CIDR 范围进行 URL 编码的需要，并且与 Zero Trust Networks API 中所有其他资源的寻址方式一致。
• 跨 API 的一致性。 这两项变更使这些终点与 Cloudflare 针对资源标识符和嵌套详情终点的标准 REST 约定保持一致。

要了解更多信息，请参阅 Zero Trust Networks API、Cloudflare Tunnel API 和路由文档。

Cloudflare IPsec 现在支持 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ IKEv2 扩展，以防御 IPsec 隧道上的降级攻击。

IKEv2 的原始身份验证设计是让每个端点仅对其自己的出网消息进行签名，而不是对完整的握手脚本进行签名。具有量子计算能力的路径上（on-path）攻击者 ↗可以利用这一点，通过将连接降级为传统密码学，从而绕过后量子密钥交换。IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 扩展通过在身份验证交换期间让双方对整个握手脚本进行签名来解决此问题，从而防止攻击者在不被发现的情况下操纵协商。

关键详情：

• 在 Cloudflare WAN 和 Magic Transit IPsec 隧道中提供 Beta 版。
• 启用该功能标志后，Cloudflare 会作为响应方（responder）无条件发送 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知。
• 发起方（您的设备）和响应方（Cloudflare）都必须支持该扩展，降级保护才能生效。
• 此功能目前由每个账户的功能标志控制。请联系您的账户团队将其开启。

请参阅降级保护了解更多详情。

您现在可以直接从仪表板注册 Cloudflare One 虚拟 Appliance 并生成其许可证密钥，而无需联系您的账户团队。

• 在 Connectors（连接器） 页面上，选择 Add an appliance（添加设备） 并选择 Virtual appliance（虚拟设备） 以注册虚拟 Appliance 并生成其身份验证密钥。
• 从虚拟 Appliance 连接器的菜单中，使用 Regenerate authentication key 来轮换其密钥。先前的密钥会立即且不可逆地撤销。
• 身份验证密钥仅显示一次——请复制并妥善保存。

这对现有的用于配置虚拟 Appliance 的 API 和 Terraform 自助服务工作流进行了补充。硬件 Appliance 继续使用现有的账户团队履行工作流。

有关详细信息，请参阅配置 Cloudflare One 虚拟 Appliance。

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 仪表板中的 **Routes（路由）**页面现在在单个表格中显示您所有连接器的路由——包括 Cloudflare Mesh 和 Cloudflare Tunnel 路由，以及 Cloudflare WAN 和 Magic Transit 静态路由，而不是每个产品分别显示独立的路由视图。

在统一的 Routes 页面中，您可以：

• 通过交互式地图可视化您的网络，该地图显示了您的目的地如何流向您的连接器——包括由多个连接器提供相同前缀服务的等价多路径（ECMP）路由。选择一个节点以过滤表格以显示其后面的路由。
• 在单个表格中查看每条路由，及其目的地、类型、连接器、优先级和来源，并进行过滤或排序以找到您需要的内容。
• 创建、编辑和删除路由（支持任何受支持的类型），而无需离开页面。添加 Cloudflare WAN 或 Magic Transit 静态路由时，您现在可以通过连接器名称选择下一跳，而无需输入其 IP。
• 在专用选项卡中管理虚拟网络。
• 测试路由，以便在提交更改之前查看目的地解析为哪个连接器和下一跳。

要找到它，请前往仪表板侧边栏中的 Networking（网络） > Routes（路由）。

您现有的路由、API 和配置保持不变——这是一个将它们聚集在一个地方的仪表板体验。了解如何添加路由和管理虚拟网络。

用于 Cloudflare WAN 的 Cisco IOS XE 第三方集成指南已更新，包含以下内容：

• 后量子密码学 (PQC)
• 策略路由 (PBR)
• IP 服务水平协议 (IP SLA)

此链接将直接带您进入已更新的 Cisco IOS XE 指南。

从 cloudflared 版本 2026.5.2 ↗ 开始，Cloudflare Tunnel 直接在二进制文件内部自动执行整个连接性预检查工作流程。以前，客户必须安装 dig 和 netcat 并手动运行这些命令来验证其环境。现在 cloudflared 在启动时以原生方式执行此操作 — 并在某些内容被阻止时提供可操作的修正提示。

在每次运行 cloudflared tunnel run（以及 cloudflared tunnel diag）时，二进制文件现在都会原生检查：

• DNS 解析 — region1.v2.argotunnel.com 和 region2.v2.argotunnel.com 解析为有效的 Cloudflare IP。
• 传输连接性 — 端口 7844 上的出站 UDP (QUIC) 和 TCP (HTTP/2)。
• Management API — 发往 api.cloudflare.com 的出站 TCP/443，用于软件更新。

结果将以可扫描的 CLI 表格形式打印，包含以下三种状态：

• ✅ 通过 — 检查成功。
• ⚠️ 警告 — 非阻塞问题，例如 Management API 无法访问，因此自动更新将无法工作，但 Tunnel 仍会启动。
• ❌ 失败 — 阻塞问题，并附有具体的修正提示（例如 Allow outbound UDP on port 7844）。

如果 DNS 无法解析，或者端口 7844 上的 UDP 和 TCP 双双失败，cloudflared 将提前退出并报告失败，而不是在不透明的 failed to dial 错误中循环。

现在每次启动都会自动运行预检查，这还能捕获诸如通宵防火墙策略变更之类的问题退化 — 无需记得重新运行故障排除指南。

要获取这一新行为，请将 cloudflared 升级到版本 2026.5.2 或更高版本。欲了解更多细节，请参阅连接性预检查文档。

您现在可以将 Cloudflare 权限范围限定为单个 Cloudflare Tunnel 实例和 Cloudflare Mesh 节点。管理员可以委派对特定 Tunnel 或 Mesh 节点的访问权限，而无需授予对整个账户中私有网络的控制权。

当您添加成员或创建权限策略时，资源选择器现在将 Cloudflare Tunnel 实例和 Cloudflare Mesh 节点列为可限定范围的资源类型。您可以：

• 向支持操作人员授予对单个 Cloudflare Tunnel 实例的只读角色，以进行日志流传输和诊断，而不会暴露其他 Tunnel 或允许破坏性操作。
• 向应用程序团队授予对特定 Cloudflare Mesh 节点的写入角色，而无需让他们访问私有网络的其余部分。
• 将单个策略的范围同时限定为一个或多个 Tunnel 以及 Mesh 节点。

细粒度权限是与现有账户级别角色平行的层，它们不会取代后者。

• 现现的账户级别角色继续有效。 拥有 Cloudflare Access 或 Cloudflare Zero Trust 的成员将保留对账户中每个 Tunnel 和 Mesh 节点的写入访问权限。这确保了与现有自动化和令牌的向后兼容性。
• 细粒度权限是累加的。 对于针对特定 Tunnel 或 Mesh 节点的任何 API 请求，如果主体具有账户级别角色或该资源的细粒度权限，则将授予访问权限。
• 资源枚举是感知授权的。 列表端点（GET /accounts/{id}/cfd_tunnel，GET /accounts/{id}/warp_connector）仅返回主体至少具有只读访问权限的资源。

• 配置 Cloudflare Tunnel 的细粒度权限。
• 配置 Cloudflare One 中 Cloudflare Tunnel 和 Cloudflare Mesh 的细粒度权限。
• 查看 Cloudflare 角色参考上的资源范围角色。

使用 Unified Routing 模式的账户现在已完全支持 Network Analytics。通过 Unified Routing onramp 和 offramp 的流量现在可以在 Network Analytics 中可见，其维度和过滤器与标准数据平面上的流量相同。

这弥补了已将隧道迁移到 Unified Routing 但在 Network Analytics 仪表板中失去对其数据平面流量可视性的客户的功能差距。无需更改配置——所有启用了 Unified Routing 的账户都会自动收集分析数据。

有关其余的 Beta 限制，请参阅流量引导 Beta 限制。

默认情况下，现在为新的 Magic Transit 和 Cloudflare WAN 账户分配单个 IPv4 Anycast 地址。

Cloudflare 会通过从全球许多分布式数据中心内的多个节点广播您的端点 IP，从而自动处理其网络上的故障。要处理您网络上的故障，请从不同的路由器配置两个隧道。

如需为您的账户申请额外的 Anycast IP 地址，请联系您的账户团队。

有关隧道配置指南，请参阅 Cloudflare WAN 的配置隧道端点或 Magic Transit 的配置隧道端点。

Cloudflare IPsec 现在支持标准 NAT 穿透（NAT-T，NAT traversal）流程，其中 IKE 在 UDP 端口 500 上启动，并在检测到 NAT 后切换到 UDP 端口 4500。

以前，必须将 NAT 后面的设备配置为直接在 UDP 端口 4500 上发起 IKE。当路径中存在 NAT 时，在 UDP 端口 500 上启动的设备无法完成 IKE 握手。这需要在 VeloCloud SD-WAN 边缘、Cisco IOS-XE 路由器和 Juniper SRX 防火墙等设备上进行自定义配置，而且并非在所有平台上都可行。

已发生的变化：

• NAT 后面的设备现在可以在 UDP 端口 500 或 UDP 端口 4500 上发起 IKE。
• 在 UDP 端口 500 上启动 IKE 并在检测到 NAT 后切换到 UDP 端口 4500 的设备现在可以成功完成握手。
• Cloudflare 上不需要更改配置。此更改适用于 Cloudflare WAN 和 Magic Transit 上的所有 IPsec 隧道。

此更改不影响现有隧道：

• 未检测到 NAT 且使用 UDP 端口 500 的隧道继续像以前一样运行。
• 配置为在 UDP 端口 4500 上启动 IKE 的隧道继续像以前一样运行。
• NAT 检测逻辑未发生变化。

有关配置详细信息，请参阅GRE 和 IPsec 隧道。