Host セレクター

エグレスポリシーは OSI モデルのレイヤー 4（https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/）で評価されます。ここでは ↗ IP アドレスだけが使え、ホスト名は使えません。Application、Content Categories、Domain、Host セレクターはホスト名でトラフィックを一致させる必要があるため、Gateway は 2 段階の処理を使います。

1. Gateway がこれらのセレクターのいずれかに一致するホスト名の DNS クエリを受け取ると、まず一時的な initial resolved 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 は initial resolved IP を返さず、Host セレクターは適用されません。

Zero Trust 組織で Host セレクターをエグレスポリシーと使うための設定は次のとおりです。

1. ユーザーデバイスに、次のバージョンの Cloudflare One Client を導入します。

   • Desktop: 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 の デバイスプロファイル で、初期解決 IP が WARP トンネル経由でルーティングされるよう Split Tunnels を設定します。設定内容は Split Tunnels のモード によって異なります。

   • Exclude mode: Split Tunnels のリストから 100.64.0.0/10 を削除します。Cloudflare One サービスで明示的に使っていない IP 範囲を戻す ことを推奨します。これにより、CGNAT アドレス空間を使う既存のプライベートネットワーク設定との衝突リスクを下げられます。
   • Include mode: 次の IP アドレスを Split Tunnel のエントリとして追加します。
     • IPv4: 172.64.128.0/20
     • IPv6: 2606:4700:0cf1:4000::/64

     これがデフォルトの範囲です。既存ネットワークと衝突する場合は、IPv4 向けに カスタムの初期解決 IP 範囲を設定 できます。

これらのセレクターの影響を受けるトラフィックが正しくルーティングされるには、Cloudflare One Client を Traffic and DNS mode にする必要があります。

Application、Content Categories、Domain、Host セレクターでは、Gateway は上述の最初の DNS 解決ステップで宛先 IP アドレスを取り込みます。エグレスポリシーはこの IP アドレスを変えないため、Gateway が接続する宛先は、選んだエグレスデータセンターや専用エグレス IP の場所とは独立です。

解決済みの宛先 IP とエグレス IP が別リージョンにある場合、接続元に基づく地域制限や IP 許可リストを適用する宛先では、接続が拒否されることがあります。

Domain または Host のエグレスセレクターを使い、ユーザーがエグレス IP に紐づくリージョンの外にいて、宛先が地域制限や IP ベースのアクセス制御を適用する場合に影響します。

Chrome 142 ↗ 以降、ローカルネットワークアクセス（Local Network Access、LNA）は、Web サイトからローカル IP アドレスへのリクエストを制限します。LNA は Chromium エンジン層で実装されているため、Google Chrome だけでなく、Chromium ベースのすべてのブラウザー（例: Microsoft Edge、Brave、Opera）に影響します。Gateway の 初期解決 IP 範囲が、まだキャリアグレード NAT（CGNAT）アドレス空間（100.64.0.0/10）から割り当てられているアカウントで、この問題が起きることがあります。例として、レガシーのデフォルト範囲 100.80.0.0/16 や、CGNAT 空間内に設定したカスタム範囲です。これらのブラウザーは、該当アドレスをローカルネットワークに属すると分類します。公開 IP から読み込んだ Web サイトが、この空間の初期解決 IP 経由で解決したドメインへサブリクエストを送ると、ブラウザーは公開ネットワークからローカルネットワークへのリクエストとして扱い、ローカルネットワーク上のデバイスへのアクセスを許可するようユーザーに確認します。ユーザーがこのプロンプトを許可するまで、ブラウザーはこれらのドメインへのリクエストをブロックします。

この問題は、広く使われるドメイン（cloudfront.net や github.com など）に Egress ポリシーが一致し、公開ページからのサブリクエストが CGNAT 空間へ解決されるときに、よく起きます。

現在のデフォルトの初期解決 IP 範囲（172.64.128.0/20）を使っているアカウントは影響を受けません。この範囲は CGNAT ではなく、Cloudflare の公開アドレス空間だからです。このデフォルトが変わる前に作成したアカウント、またはカスタムの CGNAT 空間範囲を設定したアカウントでは、次のブラウザー回避策に頼るのではなく、初期解決 IP を設定する を参照して、CGNAT 以外の範囲へ移してください。

以下の回避策は Google Chrome Enterprise ポリシーを使います。組織が別の 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 Enterprise ポリシーを使い、CGNAT 空間の初期解決 IP 範囲（例: 100.80.0.0/16）を公開として再分類します。セキュリティチェック全体を無効にするのではなく、初期解決 IP 範囲の分類だけを変えるため、いちばん対象を絞った対処です。
• 特定の URL を許可する（Chrome 140 以降）: LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise ポリシーを使い、特定の Web サイトをローカルネットワークアクセスのチェックから除外します。すべての URL でチェックを無効にする場合、https://* も有効なエントリです。
• 特定の URL を許可する（Chrome 146 以降）: LocalNetworkAllowedForUrls ↗ Chrome Enterprise ポリシーを使います。Chrome 146 以降、LocalNetworkAccessAllowedForUrls の代わりになります。
• ローカルネットワークアクセス制限をオプトアウトする（Chrome 142〜152）: LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise ポリシーを使い、ローカルネットワークアクセス制限を完全にオプトアウトします。一時的なポリシーで、Chrome 152 以降は削除されます。
• Chrome の機能フラグを無効にする: chrome://flags を開き、Local Network Access Checks フラグを Disabled にします。個人ユーザー向けの方法で、エンタープライズ全体への展開には向きません。

ドメインが DNS Override ポリシー に一致すると、Gateway はそのドメインに initial resolved IP のマッピングを適用しません。つまり、ホストベースのエグレスセレクター（Application、Content Categories、Domain、Host）は、上書きされたドメインへのトラフィックに対して評価されません。これらのドメインへのトラフィックは、デフォルトの Cloudflare エグレス方法を使います。

Host セレクターは HTTPS DNS レコードタイプに対応しません。ドメインが接続確立に HTTPS レコードを使う場合、Gateway は DNS クエリをホスト名にマッピングできず、エグレスポリシーを評価できません。これらのドメインへのトラフィックは、ホストベースのエグレスポリシーに一致せず、デフォルトの Cloudflare エグレス方法を使います。

HTTPS レコードを使うドメインにエグレスポリシーを適用する必要がある場合は、代わりに Destination IP などの IP ベースのセレクターを使います。