为 Cloudflare Mesh 配置路由 · Cloudflare One docs

默认情况下，Mesh 节点仅能通过其自身的 Mesh IP 进行访问。要使节点背后子网上的其他设备（例如无法运行 Cloudflare One Client 的服务器、数据库、打印机、IoT 设备）可被访问，请向该节点添加路由。Mesh 节点支持两种类型的路由：

CIDR 路由 — 通过节点转发 IP 范围（私有 IP，例如 10.0.0.0/24；或公共 IP）的流量。
主机名路由 — 将指向主机名而非 IP 的流量引导至节点。这适用于私有主机名（例如 wiki.internal.local），这在应用程序的 IP 未知或为临时 IP 时非常有用；也适用于公共主机名（例如 www.example.com），这会通过节点路由该主机名的流量并从该节点的公共 IP 流出。

当您添加路由时，Mesh 节点将充当网关：发往宣告的 CIDR 或主机名的流量将被转发到该节点，然后该节点将其传送到本地网络上的相应主机（或将其流出到公共互联网）。

支持 IPv4 和 IPv6 CIDR 路由。

何时使用路由

不使用路由 — Mesh 上的设备只能通过其 Mesh IP 访问节点本身。直接运行在节点上的服务可以通过这种方式访问。
使用路由 — Mesh 上的设备可以访问节点背后子网中的任何主机。当您拥有无法运行 Cloudflare One Client 的基础设施时，请使用此选项。

flowchart LR
  subgraph subnet["子网 10.0.0.0/24"]
    node["Mesh 节点 <br> 10.0.0.1"]
    db["数据库 <br> 10.0.0.50"]
    printer["打印机 <br> 10.0.0.100"]
  end
  client["客户端设备 <br> 100.96.0.10"] --> CF((Cloudflare)) --> node
  node --> db
  node --> printer

管理 CIDR 路由

使用 CIDR 路由将流量从您的 Mesh 节点转发到本地网络上的设备。

添加路由

在 Cloudflare 仪表板中，前往 Networking（网络） > Mesh。
Go to Mesh ↗
选择您的 Mesh 节点。
转到 Routes（路由） 选项卡。
选择 Add route（添加路由）。
输入要通过此节点路由的私有 CIDR（例如 10.0.0.0/24）。
（可选）为路由添加描述。
选择 Add route（添加路由）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Create a tunnel routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Staging subnet"
	}'

编辑路由

前往 Networking（网络） > Mesh > 选择您的节点 > Routes（路由） 选项卡。
选择要修改的路由旁边的编辑图标。
更新 CIDR 或描述。
选择 Save（保存）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Update a tunnel routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"comment": "Updated description"
	}'

删除路由

前往 Networking（网络） > Mesh > 选择您的节点 > Routes（路由） 选项卡。
选择路由旁边的删除图标。
确认删除。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Delete a tunnel routebash

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

配置分流隧道

为了让流量到达您宣告的 CIDR，该范围必须在 Mesh 节点和客户端设备上均通过 Cloudflare 进行路由。

在 Mesh 节点上

在 Mesh 节点的设备配置文件中，确保宣告的 CIDR 通过 Cloudflare 进行路由：

包含模式（推荐用于 Mesh 节点）：将 CIDR 添加到您的包含列表中。
排除模式：从排除列表中移除 CIDR（或其父范围）。

例如，如果您宣告的是 10.0.0.0/24，而您的分流隧道排除列表包含 10.0.0.0/8，则需要移除 10.0.0.0/8，并重新添加您不希望通过 Cloudflare 路由的 10.0.0.0/8 范围的部分。

在客户端设备上

在客户端设备使用的设备配置文件上重复相同的分流隧道配置，确保宣告 the CIDR 通过 Cloudflare 进行路由。

返回流量路由

Mesh 节点将来自 Cloudflare 的入站流量转发到子网上的设备。然而，对于返回流量（来自子网设备返回到 Mesh 客户端的响应），子网设备需要有一条回到 Mesh 节点的路由。

flowchart LR
  client["客户端设备 <br> 100.96.0.10"] -- 请求 --> CF((Cloudflare)) -- 请求 --> node["Mesh 节点 <br> 10.0.0.1"]
  node --> db["数据库 <br> 10.0.0.50"]
  db -. "响应: <br> 需要到节点的路由" .-> node -. 响应 .-> CF -. 响应 .-> client

如何配置这取决于 Mesh 节点的安装位置：

选项 1：Mesh 节点是默认网关

如果 Mesh 节点是子网的默认网关（或安装在路由器上），则不需要额外配置。来自子网设备的所有流量会自然地通过节点路由。

选项 2：Mesh 节点不是默认网关

如果 Mesh 节点是子网中的普通主机，请配置子网的路由器以通过该节点发送 Mesh 流量。添加静态路由：

目标：100.96.0.0/12（Mesh IP 范围）
下一跳：Mesh 节点的本地子网 IP（例如 10.0.0.1）

这可确保将发往 Mesh 客户端的响应转发到 Mesh 节点，以便通过 Cloudflare 进行传送。

站点到站点路由

当您在多个站点拥有 Mesh 节点时，一个子网上的设备可以通过 Cloudflare 访问另一个子网上的设备。

flowchart TD
  subgraph siteA["站点 A — 10.0.0.0/24"]
    serverA["服务器 <br> 10.0.0.50"] --- nodeA["Mesh 节点 <br> 10.0.0.1"]
  end
  subgraph siteB["站点 B — 192.168.1.0/24"]
    serverB["服务器 <br> 192.168.1.50"] --- nodeB["Mesh 节点 <br> 192.168.1.1"]
  end
  nodeA <--> CF((Cloudflare))
  nodeB <--> CF

若要使其工作：

每个 Mesh 节点必须将本地子网宣告为 CIDR 路由，以便 Cloudflare 知道将流量转发到哪个节点。
远程子网 CIDR 必须在每个节点上通过 Cloudflare 进行路由。在 Mesh 节点的分流隧道配置中，将远程站点的 CIDR 添加到包含列表中（或从排除列表中移除）。
每个站点的路由器都需要有指向本地 Mesh 节点的远程子网静态路由：

站点 A 路由器：

目标：192.168.1.0/24 → 下一跳：10.0.0.1（本地 Mesh 节点）
目标：100.96.0.0/12 → 下一跳：10.0.0.1

站点 B 路由器：

目标：10.0.0.0/24 → 下一跳：192.168.1.1（本地 Mesh 节点）
目标：100.96.0.0/12 → 下一跳：192.168.1.1

对于生产环境的站点到站点部署，请考虑在每个节点上启用高可用性。HA 为节点宣告的 CIDR 路由提供了故障转移——如果活动副本发生故障，Cloudflare 会提升一个备用副本，以便流向子网的流量继续流动。

DNS 过滤

要使用 Cloudflare Gateway 过滤来自子网的 DNS 查询：

在路由器上配置 DNS：将路由器的 DNS 指向 Gateway 解析器 IP：
- 172.64.36.1
- 172.64.36.2
向路由器添加 IP 路由：在您的路由器上，添加指向 Gateway 解析器 IP 到您的 Mesh 节点本地 IP 的静态路由。这允许 DNS 流量通过节点到达 Cloudflare。
- 目标：172.64.36.1 → 下一跳：10.0.0.1（本地 Mesh 节点）
- 目标：172.64.36.2 → 下一跳：10.0.0.1
配置分流隧道：确保在您的分流隧道配置中，以下 IP 通过 Mesh 节点进行路由：
- 子网的内部 DNS 解析器 IP
- Gateway 初始解析 IP 范围：100.80.0.0/16（IPv4）和 2606:4700:0cf1:4000::/64（IPv6）

Gateway 会使用发起设备的私有源 IP 记录 DNS 查询。您可以使用它为内部 DNS 记录创建解析器策略。

主机名路由

您可以将特定主机名的流量引导至 Mesh 节点，而不是宣告 IP 范围。当用户请求该主机名时，Cloudflare Gateway 会分配一个初始解析 IP 并通过该节点路由流量。

私有主机名（例如 wiki.internal.local）— 节点将流量传送给本地网络上应用程序的私有 IP。这在应用程序的 IP 未知或为临时 IP 时非常有用。
公共主机名（例如 www.example.com）— 节点使用其自身的公共 IP 将流量流出到公共互联网。这使您可以将 Mesh 节点用作该主机名的专用出口。

主机名路由取代了虚拟网络作为访问资源的方式：因为主机名是全球唯一的，所以不支持重叠的主机名，并且一个主机名一次只能路由到一个节点或隧道。

Client device
Requests wiki.internal.local
DNS query
Cloudflare Gateway
Returns a token IP, then rewrites the destination to the real private IP.
100.80.0.0/16
Hostname route
Mesh node
Forwards traffic to the host on the local network
↓
Private host
wiki.internal.local · 10.0.0.50

要深入了解主机名路由背后的数据包流向，请参阅公告博客文章 ↗。

前提条件

运行受支持的 Mesh 节点版本。 主机名路由需要 Mesh 节点运行 Linux Cloudflare One Client 版本 2026.6.822.0 或更高版本。
启用 Gateway 代理（支持 TCP、UDP 和 ICMP）：
1. 转到 Traffic policies（流量策略）> Traffic settings（流量设置）。
2. 在 **Proxy and inspection（代理和检查）**中，开启 Allow Secure Web Gateway to proxy traffic（允许 Secure Web Gateway 代理流量）。
3. 选择 TCP。
4. 选择 UDP（将流量代理到内部 DNS 解析器所必需）。
5. （推荐）要代理 ping 和 traceroute 等诊断工具的流量，请选择 ICMP。您可能还需要更新您的系统以允许 ICMP 流量通过 cloudflared。
1. 向您的 cloudflare_api_token ↗ 添加以下权限：
  
  Zero Trust Write
2. 使用 cloudflare_zero_trust_device_settings ↗ 资源启用 TCP 和/或 UDP 代理：
  
  resource "cloudflare_zero_trust_device_settings "global_warp_settings" { account_id = var.cloudflare_account_id gateway_proxy_enabled = true gateway_udp_proxy_enabled = true }
Cloudflare 现在将代理来自注册设备的流量，但在您的 Split Tunnel 设置中排除的流量除外。有关 Gateway 如何转发流量的更多信息，请参阅 Gateway 代理。

在 Mesh 节点的设备配置文件和您的客户端设备配置文件的分流隧道配置中，通过 Cloudflare 路由以下所有范围。在包含模式下，添加每个范围；在排除模式下，确保没有排除其中任何一个（或其父范围）。

用途	IPv4	IPv6
Mesh 设备 IP 范围	`100.96.0.0/12`	`2606:4700:cf1:1000::/64`
Cloudflare 源 IP 范围	`100.64.0.0/12`	`2606:4700:cf1:5000::/64`
主机名路由（令牌 IP）	`100.80.0.0/16`	`2606:4700:0cf1:4000::/64`

客户端设备上从本地域回退中移除主机名的顶级域，以便将 DNS 查询发送到 Cloudflare Gateway 进行解析。

添加主机名路由

在 Cloudflare 仪表板中，前往 Networking（网络） > Mesh。
Go to Mesh ↗
选择您的 Mesh 节点。
转到 Routes（路由） 选项卡。
选择 Add route（添加路由），然后选择 Private hostname（专用主机名）。
输入您要通过此节点路由的完全限定域名（FQDN）（例如 wiki.internal.local）。
主机名格式限制
- 字符限制：必须少于 255 个字符。
- 支持的通配符：允许使用单个通配符（*），且它必须代表一个完整的 DNS 标签。示例：*.internal.local
- 不支持的通配符：不支持以下通配符格式：
  - 部分通配符，例如 *-dev.internal.local 或 dev-*.internal.local。
  - 中间的通配符，例如 foo*bar.internal.local 或 foo.*.internal.local。
  - 主机名中的多个通配符，例如 *.*.internal.local。
- 通配符修剪：前导通配符（*）会被修剪掉，并假定有一个隐式的点（.）。例如，*.internal.local 会保存为 internal.local，但会匹配通配符级别的所有子域名（涵盖 foo.internal.local，但不涵盖 foo.bar.internal.local）。
- 点修剪：允许前导点和尾随点（.），但会被修剪掉。
（可选）为路由添加描述。
选择 Add hostname（添加主机名）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Create hostname routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/zerotrust/routes/hostname" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "wiki.internal.local",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Internal wiki"
	}'

配置 DNS 解析

对于私有主机名，Gateway 必须能够将主机名解析为其私有 IP。如何配置取决于 DNS 解析和应用程序流量是使用相同的连接器还是不同的连接器。

节点解析主机名（默认）

默认情况下，Mesh 节点使用其主机上配置的 DNS 解析器（例如 Linux 上的 /etc/resolv.conf）来解析主机名，这与 cloudflared 的工作方式相同。如果节点已经能够通过该解析器将主机名解析为其私有 IP，则不需要进一步配置。

如果节点自身无法解析主机名，最简单的选择是在节点的 hosts 文件（例如 Linux 上的 /etc/hosts）中添加一个条目，将主机名映射到其私有 IP。与 Cloudflare Tunnel 不同，Mesh 节点不要求您运行专用的 DNS 服务器：

/etc/hoststxt

10.0.0.50 wiki.internal.local

分割 DNS：DNS 和应用程序流量使用不同的连接器

只有当 DNS 查询必须发送到与应用程序流量不同的连接器时，您才需要 Gateway 解析器策略——例如，内部 DNS 服务器位于一个 Mesh 节点或 Cloudflare Tunnel 后面，而应用程序通过另一个访问。在那种情况下：

为 DNS 服务器的 IP 添加 CIDR 路由，以便 Gateway 可以通过 DNS 服务器所在的连接器（Mesh 节点或 Cloudflare Tunnel）访问它。
创建一个解析器策略，将该主机名（或其域）的 DNS 查询发送到该内部 DNS 服务器。

对于公共主机名，Mesh 节点会处理解析：Gateway 将 DNS 查询发送给节点，节点通过其上游 DNS 提供商进行解析，然后将数据包路由到目的地，并使用其自身的公共 IP 流出。不需要内部 DNS 服务器或解析器策略。

安全保护主机名流量

添加主机名路由后，使用 Access 自托管应用程序或 Gateway 网络策略将其安全保护。有关详细信息和示例，请参阅连接私有主机名。

局限性

从 Chrome 142 ↗ 开始，浏览器会限制来自网站对本地 IP 地址的请求，包括 Gateway 初始解析的 IP（initial resolved IP） CGNAT 范围（100.80.0.0/16）。由于该范围属于 100.64.0.0/10，Chrome 将这些地址归类为属于本地网络。当从公共 IP 加载的网站向通过初始解析 IP 解析的域发出子请求时，Chrome 会将此视为“公共到本地网络”请求，并显示提示要求用户允许访问本地网络上的设备。在用户接受此提示之前，Chrome 将拦截对这些域的请求。

这通常发生在出站（Egress）策略与广泛使用的域（例如 cloudfront.net 或 github.com）匹配时，导致来自公共页面的子请求解析为 100.80.0.0/16 范围。

Iframe

如果受影响的请求源自 iframe 内部（例如嵌入在第三方门户中的应用程序），则 iframe 必须声明 local-network-access 权限，以便在父框架中显示浏览器提示：

Chrome 142-144：在 iframe 元素上使用 allow="local-network-access" 属性。
Chrome 145+：该权限被拆分为 allow="local-network" 和 allow="loopback-network"。

如果 iframe 是嵌套的，则链中的每个 iframe 都必须包含相应的属性。由于第三方应用程序控制着它们自己的 iframe 属性，这可能无法由最终用户进行配置。

规避方法

为避免此问题，请选择以下选项之一：

Chrome 146+（覆盖 IP 地址空间分类）：使用 LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome 企业版策略将 100.80.0.0/16 范围重新归类为公共（public）。这是最具针对性的修复，因为它仅更改初始解析 IP 范围的分类，而不是完全停用安全检查。
Chrome 140+（允许特定 URL）：使用 LocalNetworkAccessAllowedForUrls ↗ Chrome 企业版策略使特定网站免受本地网络访问检查。请注意，https://* 是停用所有 URL 检查的有效条目。
Chrome 146+（允许特定 URL）：使用 LocalNetworkAllowedForUrls ↗ Chrome 企业版策略，从 Chrome 146 开始，该策略会替换 LocalNetworkAccessAllowedForUrls。
Chrome 142-152（选择退出本地网络访问限制）：使用 LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome 企业版策略完全退出本地网络访问限制。这是一项临时策略，将在 Chrome 152 之后移除。
停用 Chrome 功能标志：转到 chrome://flags，然后将 Local Network Access Checks 标志设置为 Disabled。此方法适用于个人用户，但不适用于企业级部署。