このガイドでは、Cloudflare Gateway ポリシーのよくある問題をトラブルシュートします。発生頻度の高い順に並べています。
エグレスポリシーは、Gateway でいちばん多い問題カテゴリです。症状には、専用エグレス IP を使わないトラフィック、誤ったフェイルオーバー、Gateway が遠いデータセンターへルーティングすることによる高いレイテンシがあります。
有効なエグレスポリシーがあるのに、専用エグレス IP ではなく Cloudflare のデフォルト IP から出ていくことがあります。
| よくある原因 | 対処 |
|---|---|
| 初期解決 IP への DNS 解決 | エグレスポリシーで Domain または Host セレクターを使う場合、Gateway はまずそのドメインを 初期解決 IP に解決する必要があります。アカウントがまだ CGNAT（キャリアグレード NAT）アドレス空間内のレガシー範囲を使っていると、この IP は Cloudflare ネットワーク内部として扱われ、ネットワークから出ていくトラフィックに適用されるエグレスポリシーの対象外になることがあります。エグレスポリシーのセレクターを Domain または Host から Destination IP（到達したいサービスのパブリック IP）へ変更するか、初期解決 IP 範囲を CGNAT から外して ください。 |
| ポリシーの優先順位 | より高い優先度（小さい番号）の別のエグレスポリシーが、先にトラフィックに一致しています。エグレスポリシーも、最初に一致したルールが勝つロジックです。 |
| Split Tunnel の設定 | 宛先 IP またはドメインが、Split Tunnel 設定（特定の IP やドメインのトラフィックを WARP トンネル経由にするか除外するかを制御します）で WARP トンネルから除外されています。トンネルから除外したトラフィックは、エグレスを含むすべての Gateway ポリシーの対象外です。 |
| エグレスログがない | エグレスログは Logpush の Gateway Egress データセットで確認できます。トラブルシュートに必須です。テストデバイスからサードパーティの IP 確認サービスを使い、エグレス IP を確認することもできます。 |
プライマリの専用エグレス IP が使えなくなったとき、設定したセカンダリ専用 IP ではなく、Cloudflare のデフォルト共有 IP へフェイルオーバーします。
| よくある原因 | 対処 |
|---|---|
| Cloudflare 側のルーティングまたは設定の問題 | 発生時刻を記録し、影響を受けたユーザーの Gateway HTTP または DNS ログから Request ID を集めます。サポートチケットを開き、この情報を提供してください。一時的な対処として、エグレスポリシーを編集し、セカンダリ IP をプライマリに設定してサービスを復旧できます。 |
ある国（オーストラリアなど）のユーザーを、別リージョン（ドイツなど）にある専用エグレス IP 経由で Gateway がルーティングし、高いレイテンシや地域制限コンテンツへのアクセス障害が起きます。
よくある原因と対処:
| よくある原因 | 対処 |
|---|---|
| 単一のエグレスポリシー | 所在地に関係なく全ユーザーに適用する、広いエグレスポリシーが 1 つだけある可能性があります。所在地を意識したエグレスポリシーを作成してください。ポリシーの User Location セレクターで、特定のユーザー所在地を最寄りの専用エグレス IP に紐づけます。たとえば、User Location が United Kingdom のときはロンドンの IP でエグレスするポリシーと、User Location が Australia のときはシドニーの IP でエグレスするポリシーを作成します。 |
| 誤った地理位置情報 | ユーザーの ISP の IP アドレスの地理位置が正しくないことがあります。Gateway ログで Cloudflare が見ているユーザーの所在地を確認してください。誤っている場合は、Cloudflare Support へ報告できます。 |
よくある混乱は、Gateway が異なるポリシータイプと、その中のルールをどう評価するかです。
特定アプリケーション向けの優先度の高い Allow または Do Not Scan ポリシー（Allow finance.example.com など）があるのに、優先度の低い Block ポリシー（Block All High-Risk Sites など）で Gateway がトラフィックをブロックします。
いちばん重要な考え方は Gateway ポリシーの優先順位 です。Gateway はポリシーの順序番号に基づいて適用します。一覧の番号が小さいほど優先度は高くなります。Gateway は、最初に一致したルールで以降のポリシー処理を止めます。
Gateway ポリシーの優先順位の問題を解消するには、次の手順を行います。
- Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Firewall policies を開きます。
- DNS、Network、HTTP ポリシーの順序を確認します。
- いちばん具体的な Allow、Do Not Scan、Do Not Inspect ポリシーの順序番号が、一般的な Block ポリシーより小さくなるようにします。
- 必要に応じてポリシーをドラッグアンドドロップして並べ替えます。
teams.microsoft.com向けの Allow ポリシーは、すべてのファイル共有アプリケーションを対象とする一般的な Block ポリシーより前に置きます。
TLS 復号 をオンにすると、Data Loss Prevention（DLP）、Browser Isolation、アプリケーション認識の HTTP ポリシーなど、Gateway の機能に必要です。ただし、一部のソフトウェアで問題が起きることがあります。
TLS 復号をオンにしたあと、git、aws、kubectl、terraform などのコマンドラインツールや、ChatGPT や Docker などのデスクトップアプリケーションが動かなくなる場合、証明書エラーが原因であることがあります。アプリケーションは SSL: CERTIFICATE_VERIFY_FAILED、self-signed certificate in certificate chain、または類似の TLS エラーを返すことがあります。
これらのアプリケーションは OS の信頼ストアを使わないため、インストールした Cloudflare ルート証明書を信頼しません。独自の証明書信頼ストアを持つか、証明書ピンニングを使い、Cloudflare が再署名した証明書ではなく、サーバー本来の証明書を期待します。
この問題を解消するには、次のいずれかを行います。
これらのツールがアクセスする特定ドメイン向けに、復号を迂回する対象を絞った HTTP ポリシーを作成します。このポリシーは、メインの TLS 復号ポリシーより高い優先度（小さい順序番号）に置きます。
github.com、*.amazonaws.com、*.docker.io などのホストを含む リスト を作成します。
| セレクター | 演算子 | 値 | アクション |
|---|---|---|---|
| Domain | in list | CLI Tool Domains | Do Not Inspect |
一部のツールは、カスタム CA を信頼するか、SSL 検証を無効にするよう設定できます。この方法は安全性が低く、大規模運用も難しくなります。詳細は 証明書を手動でインストールする を参照してください。
HTTP ポリシーがユーザーのリクエストをブロックしたとき、設定した Gateway ブロックページではなく、ブラウザーが一般的なエラー（ERR_SSL_PROTOCOL_ERROR）を返します。
これは、ブロックページが提示する証明書（Cloudflare ルート証明書で署名）をブラウザーが信頼しないためです。ユーザーのデバイスに証明書がインストールされていないか、信頼されていません。
この問題を解消するには、次の手順を行います。
- デバイスに Cloudflare ルート証明書 がインストールされていることを確認します。
- 証明書が正しいシステムレベルの信頼ストアにあることを確認します（macOS では Keychain の System ストア、Windows ではローカルコンピューターの Trusted Root Certification Authorities など）。
- MDM（モバイルデバイス管理）ツールを使っている場合は、デプロイスクリプトが証明書を正しくインストールし、信頼していることを確認します。
内部ホスト名を解決するよう Gateway を設定したのに、ユーザーがアクセスできません。たとえば、Cloudflare One Client に接続したユーザーが jira.mycompany.local のような内部サービスへアクセスしようとしても、DNS クエリが失敗します。
| よくある原因 | 対処 |
|---|---|
| リゾルバーポリシーがない、または誤っている | Traffic policies > Resolver policies を開きます。内部ドメインのサフィックスに一致し、内部 DNS サーバーの IP アドレスへクエリを転送するポリシーを作成します。 |
| Split Tunnel がプライベート IP 範囲を除外している | 内部リソースがプライベート IP 範囲（10.0.0.0/8 など）にある場合、その範囲をトンネルに含める必要があります。Split Tunnel 設定の Exclude リストにあると、Cloudflare One Client はそのトラフィックをプロキシしません。 |
| Local Domain Fallback の設定誤り | 社内 DNS にはリゾルバーポリシーを使います。Local Domain Fallback は、ユーザーの直近の物理ネットワーク固有のドメインにだけ使います。 |