主机选择器

出口策略在 OSI 模型的第 4 层进行评估，在此层仅 IP 地址可用，而没有主机名。Application、Content Categories、Domain 和 Host 选择器需要按主机名匹配流量，因此 Gateway 采用两步流程：

1. 当 Gateway 收到针对与这些选择器之一匹配的主机名的 DNS 查询时，它最初会将该查询解析为临时 初始解析 IP。默认情况下，该 IP 来自 Cloudflare 自有的公网范围（IPv4 为 172.64.128.0/20，IPv6 为 2606:4700:0cf1:4000::/64）。如果与现有网络冲突，你可以配置自定义 IPv4 范围。
2. 当使用此临时目的 IP 的流量到达时，Gateway 可以识别该连接所属的主机名，应用正确的出口策略，然后在转发流量之前将临时 IP 替换为真实目的地 IP。

这些选择器在起作用前需要额外的配置。

要为您的账户启用这些选择器：

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/configuration" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"settings": {
				"host_selector": {
						"enabled": true
				}
		}
	}'

流量必须通过以下方法接入到 Gateway：

来自不支持的接入方法的流量将使用您的默认 Gateway 设置进行解析。如果您使用 DNS 位置向 Gateway 发送 DNS 查询（通过 IPv4、IPv6、DNS over TLS 或 DNS over HTTPS），Gateway 不会返回初始解析 IP，且主机选择器不适用。

要将您的 Zero Trust 组织配置为将主机选择器与出口策略结合使用：

1. 确保在您用户的设备上部署了以下版本的 Cloudflare One Client：

   • 桌面端：Cloudflare One Client 版本 2025.4.929.0 或更高版本
   • iOS：Cloudflare One Client 版本 1.11 或更高版本
   • Android 和 Chrome OS：Cloudflare One Client 版本 2.4.2 或更高版本。

   如果您需要支持运行旧版本 WARP 的设备，请将以下键值对添加并部署到您设备的 WARP 配置文件中（Windows 和 Linux 上为 mdm.xml，macOS 上为 com.cloudflare.warp.plist）：

   <array>
   	<dict>
   +		<key>doh_in_tunnel</key>
   +		<true/>
   	</dict>
   </array>

2. 在您的 WARP 设备配置文件中，配置分流隧道（Split Tunnels），使 初始解析的 IP 通过 WARP 隧道进行路由。配置取决于您的分流隧道模式：

   • 排除模式：从您的分流隧道列表中删除 100.64.0.0/10。我们建议重新添加未明确用于 Cloudflare One 服务的 IP 范围。这可以减少与可能使用 CGNAT 地址空间的现有私有网络配置发生冲突的风险。
   • 包含模式：为以下 IP 地址添加分流隧道条目：
     • IPv4：172.64.128.0/20
     • IPv6：2606:4700:0cf1:4000::/64

     这是默认范围。如果与现有网络冲突，你可以配置自定义 IPv4 初始解析 IP 范围。

Cloudflare One Client 必须设置为 Traffic and DNS 模式 才能使受这些选择器影响的流量正确路由。

对于 Application、Content Categories、Domain 和 Host 选择器，Gateway 会在上述初始 DNS 解析步骤中捕获目的地 IP 地址。出口策略不会更改此 IP 地址，因此 Gateway 连接的目的地与您选择的出口数据中心或专用出口 IP 的位置无关。

如果解析的目的地 IP 与出口 IP 位于不同区域，则发往基于连接源执行地理限制或 IP 白名单的目标站点的连接可能会被拒绝。

如果您使用 Domain 或 Host 出口选择器，而您的用户位于与您的出口 IP 关联的区域之外，且目的地应用了地理限制或基于 IP 的访问控制，这可能会对您产生影响。

从 Chrome 142 ↗ 起，本地网络访问（LNA）会限制网站向本地 IP 地址发出的请求。LNA 在 Chromium 引擎层面实现，因此会影响所有基于 Chromium 的浏览器（例如 Microsoft Edge、Brave 和 Opera），不只是 Google Chrome。如果账户的 Gateway 初始解析 IP 范围仍来自运营商级 NAT（CGNAT）地址空间（100.64.0.0/10），就可能受到影响，例如旧版默认范围 100.80.0.0/16，或在 CGNAT 空间中配置的自定义范围。这些浏览器会将此类地址归类为本地网络地址。当从公共 IP 加载的网站向解析为此空间内初始解析 IP 的域名发起子请求时，浏览器会将其视为从公共网络到本地网络的请求，并提示用户允许访问本地网络上的设备。用户接受提示前，浏览器会阻止向这些域名发出的请求。

当出口策略匹配广泛使用的域名（例如 cloudfront.net 或 github.com），导致公共页面的子请求解析到 CGNAT 空间时，通常会发生这种情况。

使用当前默认初始解析 IP 范围（172.64.128.0/20）的账户不受影响，因为此范围属于 Cloudflare 公共地址空间，而非 CGNAT。如果账户在默认范围变更前创建，或配置了自定义 CGNAT 空间范围，请参阅配置初始解析 IP，迁移到非 CGNAT 范围，无需依赖以下浏览器变通方法。

以下变通方法使用 Google Chrome 企业策略。如果组织管理其他基于 Chromium 的浏览器，请查阅该浏览器的企业策略文档，寻找等效控制项。

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

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

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

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

• 覆盖 IP 地址空间分类（Chrome 146+）：使用 LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome 企业策略，将 CGNAT 空间中的初始解析 IP 范围（例如 100.80.0.0/16）重新归类为公共地址。这是最有针对性的修复方式，因为它只更改初始解析 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。此方法适用于个人用户，但不适用于企业级部署。

如果某个域名匹配 DNS Override 策略，Gateway 将不会对该域名应用初始解析 IP 映射。这意味着基于主机的出口选择器（Application、Content Categories、Domain 和 Host）将不会针对发往被覆盖域名的流量进行评估。发往这些域名的流量将使用默认的 Cloudflare 出口方式。

主机选择器不支持 HTTPS DNS 记录类型。当域名使用 HTTPS 记录来建立连接时，Gateway 无法将 DNS 查询映射到主机名以进行出口策略评估。发往这些域名的流量将使用默认的 Cloudflare 出口方法，而不会匹配基于主机的出口策略。

如果您需要向使用 HTTPS 记录的域名应用出口策略，请改用基于 IP 的选择器（例如 Destination IP）。