プライベート IP またはホスト名を保護する

セルフホストの Access アプリケーションを設定し、プライベートネットワーク上の特定の IP またはホスト名へのアクセスを管理できます。

• プライベート IP とホスト名は、Cloudflare One Client、Cloudflare WAN（旧 Magic WAN）、または Browser Isolation 経由で到達できる必要があります。詳細は プライベートネットワークを接続する を参照してください。
• プライベートホスト名は、Local Domain Fallback または Gateway resolver ポリシー を通じて、カスタム DNS リゾルバーへルーティングされます。
• 公開 IP とホスト名でもプライベートアプリケーションを定義できますが、その IP またはホスト名は Cloudflare Tunnel、Cloudflare Mesh、または Cloudflare WAN 経由で Cloudflare を通る必要があります。
• （省略可）Access JWT で HTTPS アプリケーションセッション を管理する場合は、Gateway TLS decryption を有効にします。

1. Cloudflare ダッシュボード ↗ で Zero Trust > Access controls > Applications を開きます。

2. Create new application を選択します。

3. Self-hosted and private を選択します。

4. プライベート IP を使ってアプリケーションを追加するには:

   1. Add private IP を選択します。

   2. IP address に、アプリケーションを表すプライベート IP または CIDR 範囲を入力します（たとえば 10.0.0.1 または 172.16.0.0/12）。

   3. Port に、アプリケーションが使う単一ポートまたはポート範囲を入力します（たとえば 22 または 8000-8099）。

      カンマ区切りのポートリスト（80, 443 など）には対応していません。特定の IP に複数ポートを追加するには、Add private IP を選択し、同じ IP アドレスを別のポートで繰り返します。または、もう一方のポート用に新しい Access アプリケーションを作成します。

5. プライベートホスト名を使ってアプリケーションを追加するには:

   1. Add private hostname を選択します。
   2. Hostname に、アプリケーションのプライベートホスト名を入力します（たとえば wiki.internal.local）。プライベートホスト名では ワイルドカード を使い、同じルートパスを共有するアプリケーションの複数部分を保護できます。
   3. Port に、アプリケーションが使う単一ポートまたはポート範囲を入力します（たとえば 22 または 8000-8099）。

6. Access policies で、既存のポリシーを追加するか、新しいポリシーを作成して、アプリケーションに接続できるユーザーを制御します。Access アプリケーションはデフォルトで拒否です。ユーザーは Allow ポリシーに一致してからアクセスが許可されます。

7. ユーザーの認証方法を設定します。

   1. アプリケーションで有効にする ID プロバイダー を選択します。

   2. （推奨）単一の IdP 経由のアクセスだけを許可する場合は、Apply instant authentication をオンにします。エンドユーザーには Cloudflare Access のログインページ は表示されません。代わりに、Cloudflare はユーザーを SSO ログインイベントへ直接リダイレクトします。

   3. （推奨）Authenticate with Cloudflare One Client をオンにすると、ユーザーは Cloudflare One Client のセッション ID を使ってアプリケーションに認証できます。アプリケーションがブラウザー内になく、302 リダイレクトを扱えない場合にオンにします。

8. （任意）アプリケーション向けに 独立した MFA を設定します。

9. Session Duration で、ユーザーの アプリケーショントークン の有効期限を選びます。

   Cloudflare は、アプリケーションへのすべての HTTP リクエストで、有効なアプリケーショントークンがあるかを確認します。ユーザーのアプリケーショントークン（およびグローバルトークン）の期限が切れている場合は、IdP での再認証を求めます。詳細は セッション管理 を参照してください。

   アプリケーションが非 HTTPS であるか、TLS decryption がオフの場合、セッションはアプリケーションごとに Cloudflare One Client が追跡します。

10. （省略可）Additional settings タブを開き、アプリケーション体験をカスタマイズします。

    • App Launcher customization: App Launcher でこのアプリケーションがユーザーにどう表示されるかを設定します。

    • Allow clientless access: Cloudflare One Client なしで、このプライベートホスト名または IP へのアクセスを許可します。Access ポリシーを通過したユーザーは、App Launcher にタイルを見ます。タイルは https://<your-teamname>.cloudflareaccess.com/browser/https://wiki.internal.local/ のようなプレフィックス付き URL を指します。リンクは Clientless Web Isolation 経由でアプリケーションへトラフィックをルーティングします。この設定は、管理対象外デバイスのユーザーや、デバイスクライアントをインストールできない契約者に便利です。

    • Custom block pages: アプリケーションへのアクセスを拒否されたときに、ユーザーへ表示する内容を選びます。

      • Cloudflare default: ログインページ を再読み込みし、Cloudflare Access のロゴの下にブロックメッセージを表示します。既定のメッセージは That account does not have access です。カスタムメッセージを入力することもできます。
      • Redirect URL: 指定した Web サイトへリダイレクトします。
      • Custom page template: Cloudflare One でホストする カスタムブロックページ を表示します。

    • 次の設定はプライベートホスト名にだけ適用され、Gateway TLS decryption が必要です。

      • クロスオリジンリソース共有（CORS）の設定
      • Cookie settings
      • 401 Response for Service Auth policies: 正しい サービストークン なしでユーザー（またはマシン）がアプリケーションへリクエストした場合に、401 レスポンスコードを返します。

11. Create を選択します。

ユーザーは Cloudflare Access で認証したあと、プライベートアプリケーションに接続できます。

認証体験は、アプリケーションのプロトコルによって異なります。

Gateway TLS decryption がオンで、ユーザーがポート 443 の HTTPS アプリケーションにアクセスする場合、Cloudflare Access はブラウザーにログインページを表示し、オリジンに アプリケーショントークン を発行します。これは セルフホストの公開アプリ と同じ Cookie ベースの認証フローです。

Gateway TLS decryption がオフの場合、セッション管理はブラウザーではなく Cloudflare One Client が扱います。

ポート 80 の平文 HTTP で提供されるアプリケーションでは、Cloudflare Access はブラウザー内のログインページを表示し、アプリケーショントークン を発行します。Gateway TLS decryption が有効な HTTPS アプリケーションと同じです。トラフィックはすでに暗号化されていないため、Gateway TLS decryption は不要です。

HTTP または HTTPS ではないアプリケーション（SSH、RDP、任意の TCP/UDP など）では、Cloudflare One Client がセッションを管理します。認証が必要なとき、オペレーティングシステムは Cloudflare One Client からの Authentication required 通知を表示します。Cloudflare One Client の通知は、オペレーティングシステムの設定で許可する必要があります。ユーザーが通知を選択すると、Cloudflare One Client は Access のログインページをブラウザーウィンドウで開きます。

オペレーティングシステムが Cloudflare One Client の通知を許可していることを確認してください。集中モード、おやすみモード、画面共有の設定がオンだと、デバイスに通知が表示されないことがあります。DisplayLink ソフトウェアを実行している macOS デバイスでクライアント通知をオンにするには、ディスプレイのミラーリング中にシステム通知を許可する必要がある場合があります。詳細は macOS のドキュメント ↗ を参照してください。

認証待ちのあいだ、macOS メニューバーまたは Windows システムトレイの Cloudflare アイコンは、操作が必要であることを示します。通知を見逃した場合、ユーザーは Cloudflare One Client を開き、Profile > Account information > Re-authenticate を選択できます。バージョン 2026.1 以前では、Preferences > Account > Re-Authenticate Session を選択します。認証後、接続を再試行します。

デフォルトでは、Cloudflare はすべての Gateway ネットワークポリシー を評価したあとに Access アプリケーションポリシーを評価します。特定の Gateway ポリシーの前または後に Access アプリケーションを評価するには:

1. Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Firewall policies を開きます。Network で、次の設定の ネットワークポリシーを作成 します。

   Selector	Operator	Value	Action
   Self-hosted Access App with Private Address	is	Present	Allow

2. ダッシュボードまたは API を使い、ポリシーの 優先順位 を更新します。

プライベートホスト名で定義した Access アプリケーションは、プライベート IP で定義した Access アプリケーションより優先されます。たとえば、App-1 が wiki.internal.local を指し、App-2 が 10.0.0.1 を指すが、wiki.internal.local が 10.0.0.1 に解決されるとします。wiki.internal.local へ行くユーザーは App-2 には一致しません。App-1 の Access ポリシー（と Gateway ポリシー）だけに基づいて許可またはブロックされます。

Browser Isolation は、443 以外のポートでプライベート IP またはホスト名を使う セルフホストのプライベートアプリケーション とは互換性がありません。443 以外のポートでセルフホストアプリケーションにアクセスしようとすると、Gateway のブロックページが表示されます。

プライベート IP アドレス上の 443 以外のポートのアプリケーションで Browser Isolation を使うには、代わりに プライベートネットワークアプリケーション を設定します。

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 にします。個人ユーザー向けの方法で、エンタープライズ全体への展開には向きません。