トラブルシューティング

このガイドでは、Cloudflare Gateway ポリシーでよくある問題の切り分け方法を説明します。

Gateway のセキュリティカテゴリまたは脅威インテリジェンスによってドメインが誤ってブロックされていると思われる場合は、Cloudflare Radar のカテゴリ分類フィードバックフォーム ↗ でレビューを依頼できます。

Gateway は、オリジンとのセキュアな接続を確立できないときに 526 エラーページを表示します。よくあるのは次の 2 つのケースです。

• 信頼できないオリジン証明書: オリジンサーバーが提示する証明書が期限切れ、失効済み、または不明な認証局の発行です。
• 安全でないオリジン接続: オリジンが最新の暗号スイートに対応していないか、HTTPS リクエストをすべて HTTP にリダイレクトしています。

詳細は Error 526 を参照してください。

HTTP/2 を部分的にしかサポートしていないオリジンと通信するときに発生することがあります。オリジンが HTTP/1.1 へのダウングレードを要求した場合（例: HTTP_1_1_REQUIRED 付きの RST_STREAM フレーム）、Gateway は HTTP/1.1 でリクエストを自動的に再送せず、代わりに 502 Bad Gateway を返します。解決するには、オリジンサーバーで HTTP/2 を無効にしてください。

すべてのページで証明書の警告が出る場合は、デバイスに Cloudflare ルート証明書 がインストールされ、信頼されていることを確認してください。Gateway が HTTPS トラフィックを検査するには、この証明書が必要です。

Gateway Overview ページに分析が表示されない場合は、次を確認してください。

• DNS トラフィックを確認する: デバイスが実際に Gateway へクエリを送っていることを確認します。DNS locations を確認し、送信元 IPv4 アドレスを照合します。
• ほかのリゾルバーを確認する: デバイスに別の DNS リゾルバーが設定されていると、Gateway をバイパスしていることがあります。
• 処理完了を待つ: ダッシュボードに分析が表示されるまで、最大 5 分かかることがあります。

エグレスポリシーの症状には、専用エグレス IP が使われない、フェイルオーバーが正しく動かない、Gateway が離れたデータセンター経由でトラフィックをルーティングしてレイテンシが高くなる、などがあります。

有効なエグレスポリシーがあっても、専用エグレス IP ではなく、デフォルトの Cloudflare IP アドレスからエグレスしていることがあります。

プライマリの専用エグレス IP が使えなくなっても、設定したセカンダリの専用 IP ではなく、デフォルトの Cloudflare 共有 IP へフェイルオーバーします。

Gateway が、ある国（例: オーストラリア）のユーザーを別の地域（例: ドイツ）にある専用エグレス IP 経由でルーティングし、レイテンシが高くなったり、地域制限のあるコンテンツにアクセスできなくなったりします。

よく混乱するのは、Gateway がポリシーの種類と、その中のルールをどう評価するかです。

特定のアプリケーション向けの優先度が高い Allow または Do Not Scan ポリシー（例: Allow finance.example.com）があるのに、優先度が低い Block ポリシー（例: Block All High-Risk Sites）でトラフィックがブロックされます。

最も重要な概念は Gateway ポリシーの優先度 です。Gateway はポリシーの順序番号に基づいて適用します。一覧の順序番号が小さいほど、優先度は高くなります。Gateway は、最初に一致したルールで以降のポリシー処理を止めます。

Gateway ポリシーの優先度の問題を解決するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Traffic policies > Firewall policies を開きます。
2. DNS、Network、HTTP ポリシーの順序を確認します。
3. より具体的な Allow、Do Not Scan、Do Not Inspect ポリシーの順序番号が、一般的な Block ポリシーより小さくなるようにします。
4. 必要に応じてポリシーをドラッグアンドドロップして並べ替えます。teams.microsoft.com 向けの Allow ポリシーは、すべてのファイル共有アプリケーションを対象とする一般的な Block ポリシーより前に置きます。

TLS decryption をオンにすると、Data Loss Prevention (DLP)、Browser Isolation、アプリケーションを認識する HTTP ポリシーなどの Gateway 機能が使えます。ただし、一部のソフトウェアで問題が起きることがあります。

TLS decryption をオンにしたあと、コマンドラインツール（git、aws、kubectl、terraform など）やデスクトップアプリケーション（ChatGPT や Docker など）が動かなくなる場合、証明書エラーが原因のことがあります。アプリケーションは SSL: CERTIFICATE_VERIFY_FAILED、self-signed certificate in certificate chain、または類似の TLS エラーを返すことがあります。

これらのアプリケーションは OS のトラストストアを使わないため、インストールした Cloudflare ルート証明書を信頼しません。独自の証明書トラストストアを持つか、証明書ピンニングを使っており、Cloudflare が再署名した証明書ではなく、サーバー本来の証明書を期待します。

この問題を解決するには:

HTTP ポリシーがユーザーのリクエストをブロックすると、設定した Gateway ブロックページではなく、一般的なエラー（ERR_SSL_PROTOCOL_ERROR）がブラウザーに表示されます。

これは、ブロックページが提示する証明書（Cloudflare ルート証明書で署名）をブラウザーが信頼していないためです。デバイスに証明書がインストールされていないか、信頼されていません。

この問題を解決するには:

1. デバイスに Cloudflare ルート証明書 がインストールされていることを確認します。
2. 証明書が正しいシステムレベルのトラストストアに配置されていることを確認します（例: macOS の Keychain の System ストア、Windows のローカルコンピューター向け Trusted Root Certification Authorities）。
3. MDM を使っている場合は、デプロイスクリプトが証明書を正しくインストールして信頼していることを確認します。

Gateway で内部ホスト名を解決するよう設定しているのに、ユーザーがアクセスできません。たとえば、Cloudflare One Client に接続しているユーザーが jira.mycompany.local のような内部サービスにアクセスしようとすると、DNS クエリが失敗します。