--- title: "ネットワークルール評価トラブルシューティング" slug: "network-rule-evaluation-troubleshooting" updated: 2026-11-08T00:07:26Z published: 2026-11-08T00:07:26Z canonical: "knowledge.catonetworks.com/network-rule-evaluation-troubleshooting" --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.catonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # ネットワークルール評価トラブルシューティング ## 概観 正確なネットワークルール評価の確保は、情報に基づいたルーティング決定を行うために重要です。このトラブルシューティングガイドは、さまざまな一般的な症状を包括的に解決し、潜在的な原因を探り、ネットワークルール評価に関連する課題を解決する体系的な手順を提供することを目指します。 ## 症状 ネットワークルールに対するトラフィックの評価失敗は、さまざまな形で現れる可能性があります。管理者は次の症状を指摘することがあります： - 不正なパブリック送信元IP - ネットワークルール不一致 - 誤ったWANインタフェースが選択されました - TCPアクティブなアクセラレーションが適用されているかスキップされています - QoS優先度不一致 - オフクラウドまたはアルタナティブWANがトラフィック接続を中断します ## 可能な原因 - カスタムまたはビルトインアプリケーションの不一致 - ドメイン不一致 - 誤った出力PoPが選ばれた - 健康でないWAN接続 - ブロックまたは未識別アプリが固定されたQoS優先度につながる - 誤ったネットワークルール順序 ## 初期評価 > [!NOTE] > 注記: > > ファイアウォールルールが必ず作成されていることを確認してください（例えトラブルシューティング目的で一時的に作成された場合でも）。このルールには**イベントトラッキングが有効**であり、設定済みのネットワークルールと一致するトラフィックを含む必要があります。 CMAで**インターネットファイアウォール**または**WANファイアウォール**プリセットを選択してファイアウォールイベントを確認します。興味のあるトラフィックを絞り込むフィルターを設定します。問題の可能性のある根本原因を特定するために役立つ**関連アプリ**、**アプリケーション**、**フローで使用されているアプリケーション**、**出力PoP名、パブリック送信元IP、宛先IP**、**ドメイン名**、**ネットワークルール、およびTCPアクセラレーション**のような関連分野を分析します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/18216056658973.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D)![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/18216076632733.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) ユーザーによって報告された症状を特定して、適切なトラブルシューティングセクションを確認することを確認してください： - ウェブアプリケーションはネットワークルールに構成されたものと異なる公共送信元IPアドレスを報告する可能性があります。ファイアウォールイベントの**出力PoP名**および**公共送信元IP**フィールドが期待されたものではない場合、[不正な公共送信元IPのトラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-incorrect-public-source-ip)を参照してください - ファイアウォールイベントの**ネットワークルール**フィールドが予想されるものであるか確認します。そうでない場合は、[ネットワークルールの不一致トラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-network-rule-mismatch)を続行してください - トラフィックフローが設定されたプライマリWANリンクを使用していない場合、またはネットワークルールのプライマリトランスポートセクションで設定されたようにバランスが取れていない場合は、[誤って選択されたWANインタフェースのトラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-incorrect-wan-interface-selected)を参照してください - ファイアウォールイベントの**TCPアクセラレーション**フィールドがネットワークルールで設定された期待される値ではない場合は、[強制またはスキップされたTCPアクセラレーショントラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-tcp-acceleration-being-enforced-or-skipped)を参照してください - トラフィックにファイアウォールイベントに従って誤った**QoS優先度**255が割り当てられている場合は、[QoS優先度の不一致トラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-qos-priority-mismatch)を参照してください - ネットワークルールでトラスポートとしてオフクラウドまたはアルタナティブWANが選択されている場合に**TLS接続**が失敗する場合は、[オフクラウドまたはAlt-WANがトラフィック接続を遮断するトラブルシューティング](/v1/docs/network-rule-evaluation-troubleshooting#troubleshooting-offcloud-or-altwan-breaking-traffic-connections)を参照してください。 ## 問題解決 ### 誤ったパブリック送信元IPのトラブルシューティング 制限付きインターネットサービスにアクセスするために特定の送信元パブリックIPを定義する必要がある場合があり、その方法については[イグレスルールの設定方法](/v1/docs/how-to-configure-a-network-rule-to-egress-traffic)をご参照ください。サービスが予期しない送信元パブリックIPを報告する場合は、以下の手順に従ってください。 #### 複数のイグレスIPのレビュー 複数のイグレスIPアドレスを持つネットワークルールについては、Cato Cloudは地理的に送信元に最も近いPoPのイグレスIPアドレスを使用します。最初の出力IPアドレスが利用不可の場合、Cato Cloudは自動的に2番目の出力IPアドレスへの移行します。次のスクリーンショットは、2つのイグレスIPアドレスを持つネットワークルールの例を示しています。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17001204168733.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) この例では、ネットワークルールはニューヨークPoPまたはシカゴPoPからトラフィックをイグレスすることができます。送信元が物理的にニューヨークPoPに近い場合、CatoはニューヨークのPoPから特定のトラフィックをイグレスしようとします。ニューヨークPoPから目的地に到達できない場合、CatoはシカゴPoPからトラフィックをイグレスします。 この動作を変更するには、[イグレスPoP選択の変更](/v1/docs/network-rule-evaluation-troubleshooting#egress-pop-selection-change)を参照してください。 #### 利用不可のイグレスIP ネットワークルールに単一の出力IPが含まれる場合、設定されているものとは異なるCatoのパブリックIPを使用してトラフィックが出力される可能性があります。このような場合、メンテナンスウィンドウ中に出力IPに関連付けられたPoPが一時的に利用不可能になることがあります。この状況は、特にVoIPアプリケーションにとって重大である可能性があります。 この動作を変更するには、[イグレスPoP選択の変更](/v1/docs/network-rule-evaluation-troubleshooting#egress-pop-selection-change)を参照してください。 #### ネットワークルールの変更を確認 ネットワークルールが最近出力IPアドレスで編集された場合。新しく生成されたトラフィックフローのみが新しい出力IPを使用することを念頭に置いてください。既存のトラフィックフローは、フローが作成された時点で関連付けられた出力IPを保持します。 上記の動作は、SIPフローが長時間アクティブな状態を保つVoIPトラフィックで一般的です。この問題を解決するには、VoIP電話を再起動することで、新しいSIPフローの作成がトリガーされ、更新されたネットワークルールの出力IPに従ってルーティングされるようにします。 ### ネットワークルールの不一致のトラブルシューティング ネットワークルールを設定する際、トラフィックが誤ったネットワークルールに対して評価される可能性があります。このセクションでは、すべての可能性のある不一致のシナリオとこの問題のトラブルシューティング方法について説明します。 > [!NOTE] > **ヒント**: ルール評価をトラッキングするためにヒット数カウンター列を使用します。ヒット数カウンターは、トラフィックがCatoのセキュリティ検査エンジン (例: TLSインスペクション、マルウェア対策、インターネットファイアウォールなど) によって処理されるたびに増加します #### ファイアウォールイベント分析 ファイアウォールイベントから、**関連アプリケーション**、**アプリケーション**、**Cato アプリ**、**宛先IP**、**ドメイン名**、および**ネットワークルール**などの関連項目を特定します。この情報は、ネットワークルールの不一致の理由をトラブルシューティングするのに役立ちます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16968276860189.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### ネットワークルールの例外を確認 ネットワークルールに追加された例外を特定します。トラフィックフローが追加された例外と一致する場合、ネットワークルールは無視され、ルールの見つけるまでルールベースの残り部分が継続されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17201282391197.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### カスタムアプリケーションの確認 興味のあるトラフィックがカスタムアプリケーションと一致することを期待され、FWイベントで見つかった**アプリケーション**フィールドが一致しない場合、カスタムアプリが正しく構成されていることを確認してください。重なるカスタムアプリケーションが存在する場合、Catoはトラフィックを**カスタムアプリケーションの1つのみ**として識別します。 この問題を防ぐには、[重複するカスタムアプリケーションの解決](/v1/docs/network-rule-evaluation-troubleshooting#resolving-overlapping-custom-application)セクションを表示してください。 #### ビルトインアプリケーションの確認 興味のあるトラフィックがビルトインアプリケーションに一致することを期待しており、トラフィックが誤ったネットワークルールに一致している場合、次を確認してください： - どのアプリケーションが「間違った」一致ネットワークルールに設定されていますか。 - これらのアプリケーションのいずれかがファイアウォールイベントの**関連アプリ**フィールドにリストされているかどうか。 アプリ識別は複数のステップからなるプロセスであり、プロトコルの識別から始まり、その後は**関連アプリ**フィールドに含まれるすべての可能な一致アプリケーションを含みます。フロー内で識別された「関連アプリ」アプリケーションは、最終アプリ（**アプリケーション**フィールド）の決定に関係なく、ネットワークルールと一致します。 以下の例では、*portal.azure.com*へのアクセスは、ルール#7ではなくルール#8と一致します。これは、最終アプリケーション（**アプリケーション**フィールド）が*Azure Front Door*であるにもかかわらず、ルール#7に*Microsoft Azure*アプリケーション（**関連アプリ**に含まれる）が含まれているためです。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16996731261725.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D)![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16996324879133.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) この予想される動作を解決するには、[ネットワークルールの順序](/v1/docs/network-rule-evaluation-troubleshooting#network-rule-ordering)を参照してください #### ドメイン名の確認 ネットワークルールにドメインまたはFQDNオブジェクトが含まれている場合、ファイアウォールイベントの**ドメイン名**フィールドが何かを確認してください。ネットワークルールのドメイン/FQDNオブジェクトはこのフィールドと同じでなければなりません。 **FQDN**は完全な修飾ドメイン名の正確な一致であることを忘れないでください。例えば、FQDN *example.com* は *example.com.* だけに一致します。 一方、**ドメイン**は、すべてのサブドメインに一致するトップレベル（TLD）またはセカンドレベルドメイン（SLD）です。例えば、ドメイン*example.com*はwww.*と一致します。example.com*と*host.example.com*。 CatoがHTTP、TLS、またはDNSフローから正しいドメイン名を判断できない場合がある。このタイプの問題を解決するには、[ドメイン名問題の解決](/v1/docs/network-rule-evaluation-troubleshooting#resolving-domain-name-issues)を参照してください ### 選択された誤ったWANインターフェースのトラブルシューティング このセクションでは、Catoがトランスポートとして選択され、アクティブ/アクティブの展開で両方のWANインターフェースが構成されているシナリオについて説明します。ポリシーベースのルーティングに関する詳細については、[Catoがベストトランスポートまたはリンクを選択する方法](/v1/docs/part-2-pbr-and-network-rules-within-the-socket)を参照してください。 > [!NOTE] > 注記: > > 注意: ファイアウォールルールの**ISP名**および**送信元ISP IP**フィールドは、トラフィックが使用するWANリンクを判断するための良い指標とは限りません。これは、トラフィックフローがそのライフタイム中に複数回トンネルを変更できるためです。 #### ネットワークルールトランスポート設定の確認 アクティブ/アクティブ配置を達成するためには、プライマリインタフェースの役割を**自動**に設定するか、以下のスクリーンショットに示されているように両方のプライマリおよびセカンダリインタフェースの役割を構成する必要があります。セカンダリインタフェースの役割を**なし**に設定すると、プライマリインタフェースが利用不可になった場合にトラフィックフェイルオーバーが発生しません。[ソケットインタフェースを介したトラフィックのルーティング](/v1/docs/part-2-pbr-and-network-rules-within-the-socket)を参照してください。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17220226170781.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### ネットワークアナリティクスの確認 **平均スループット**ウィジェットでは、各WANリンクの平均帯域幅利用率が表示されます。これは、ネットワークルールが正しいWAN接続を選択しているか、トラフィックを適切にバランスさせていることを確認する指標として機能します。下のスクリーンショットでは、ネットワークルールがWAN2をプライマリトランスポートとして選択するように変更されています。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17009865461789.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) 特にパケットロス、ジッター、距離に関してWANリンクのパフォーマンスをモニタリングすることが重要です。[アクティブ/アクティブトラフィック分散](/v1/docs/active-active-traffic-distribution)で説明されているように、あるリンクが最小リンク品質のしきい値を満たしていない場合、健康でないと見なされ、トラフィック分散には選ばれません。たとえそのWANリンクがプライマリトランスポートとして選ばれていてもです。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17009865472925.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### ソケットWebUIの確認 ソケットがリンクを健康でないと考えているかどうかを確認する簡単な方法は、ソケットWebUIのモニタリングページをチェックすることです。レイテンシー、ジッター、またはパケットロスのメトリックが最低要件を満たしていない場合、不健康な値は赤でマークされます。 以下の例では、WAN1のレイテンシーが非常に高く、これによりソケットはリンクを健康でないと見なします。この問題はあなたのISPに話し合うべきです。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17009881093917.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### WANリンク設定の確認 すべてのアクティブ/アクティブリンクが健康であるなら、各WANリンクの帯域幅設定をCMAで確認してください。以下の例では、WAN1リンクは100 Mbpsの下り/上り帯域幅で構成され、WAN2リンクは20 Mbpsの下り/上りで構成されています。これにより、WAN1に100:20または5:1の比率で、双方の下りと上り方向により多くのトラフィックが送信されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17009865495965.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) ### TCPアクセラレーションの強制またはスキップのトラブルシューティング [Cato TCPアクセラレーションの説明](/v1/docs/explaining-the-cato-tcp-acceleration-and-best-practices)で議論されているように、ネットワークルールでTCPアクセラレーションが有効にされると、WAN越しにTCP接続を加速できます。この機能は通常、特定のシナリオで強制され、たとえルール内の**アクティブTCPアクセラレーション**オプションがチェックオフされても、管理者は無効化できない場合があります。このセクションでは、これらのシナリオと、必要に応じて機能を無効にする方法について説明します。 #### TCPアクセラレーションが強制される場合 ネットワークルールで出力IPまたは出力ロケーションを使用する場合、TCPアクセラレーションが適用されます。これにより、PoPがプロキシとして機能するよう強制され、その結果、ルールに一致するすべてのトラフィックフローにTCPアクセラレーションが適用されます。ネットワークルール内のチェックボックスはグレーアウトされます。 次の場合、ネットワークルールでTCPアクセラレーションを無効にしても機能が無効になりません： - アカウントにTLSインスペクションが有効化されており、TLSバイパスされている場合でもすべてのTLSトラフィックにTCPアクセラレーションが有効になります。これは、PoPがトラフィックを検査し、悪意のあるファイルや脅威を検出するためにプロキシとして機能する必要があるためです。 - TCPアクセラレーションが無効になっている一致するネットワークルールの上に、複雑なネットワークルールが存在します - TCPアクセラレーションが無効になっているネットワークルール自体が複雑です。 複雑なネットワークルール（NGルールとも呼ばれる）は、Socket自体が評価できないネットワークルールです。したがって、SocketはトラフィックをPoPに送信する必要があり、その結果、TCPアクセラレーションを有効にする正しいネットワークルールが選択されます。含むことができるのは: アプリケーション, アプリケーションカテゴリ, サービス, カスタムアプリケーション, またはドメイン/FQDNオブジェクト。 一方、単純なルールには、Socketによって評価され、PoPからの関与を必要としない以下のエンティティを含めることができます： - **送信元/宛先**フィールドには、サイト、IPアドレス、ネットワークインターフェース、IP範囲、またはすべてを含めることができます。 - **アプリ/カテゴリ**フィールドには、ポート範囲またはカスタムサービスを含めることができます。 #### TCP加速をスキップする場合 TCP加速はTCPトラフィックにのみ適用されます。ネットワークルールでTCP加速が有効であり、前のセクションで説明されているように強制されている場合、しかしCMAイベントで**TCP加速**フィールドが**0**の時、Catoクラウド上で非対称ルーティングが発生し、トラフィックフローが**オープンモード**として検出された可能性があります [Catoクラウド上の非対称ルーティング](/v1/docs/asymmetric-routing-over-cato-and-mpls)で説明されているように、**オープンモード**はTCPフローの開始時（3ウェイハンドシェイク）をCatoクラウドが認識していない接続モードであり、そのためTCP加速が適用されません。オープンモードフローの生成の根本原因を特定するために、Catoサポートと協力することをお勧めします。 #### TCP加速を無効化する TCP加速を無効にするためには、Egress IPまたはロケーションを含まない単純なルールをネットワークルールベースの最上部に配置することができます。詳細は[ネットワークルールの注文](/v1/docs/network-rule-evaluation-troubleshooting#network-rule-ordering)を参照してください。上述したように、トラフィックがTLSの場合、TLSインスペクションはアカウント全体で無効化されなければなりません。 ### QoS優先度のミスマッチをトラブルシューティングするため [フローがQoS優先度255に割り当てられる場合](/v1/docs/when-is-a-flow-assigned-qos-priority-255)で説明されているように、ネットワークルールで設定されたQoS優先度がFWイベントで表示される優先度と異なる場合があります。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17201082768797.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) QoS優先度255はBW管理のデフォルトの優先度と呼ばれています。ネットワークルールの帯域幅優先度設定に関係なく、フローにQoS優先度255が割り当てられる理由はいくつかあります： - Catoは各フローのネットワークプロファイルを評価し、特定のアプリケーションがまだ識別されていない場合、QoS優先度255が割り当てられます。 - (**フローが識別される前の最初のパケットには、QoS優先度255が割り当てられています。** - ブロックされたフローには、QoS優先度255が割り当てられています。 ### オフクラウドまたはアルトWANでトラフィック接続が断続する問題のトラブルシューティング このセクションでは、WANネットワークルールがオフクラウドまたはアルトWANをプライマリトランスポートとして設定された際に、サイト間でTLS接続が確立できないシナリオに対処します。この問題をトラブルシューティングするには、次の手順に従ってください。 #### フロー分析 トラフィックが正しくオフクラウドまたはアルトWAN経由でルーティングされている場合、それらのトラフィックフローはCMAでFWイベントを生成しません。なぜならこのトラフィックはPoPを通過しないからです。 オフクラウドまたはアルトWAN経由でトラフィックが成功裏にルーティングされていることを確認する方法のひとつは、[Socket WebUI](/v1/docs/accessing-the-socket-webui)のSDWANタブから確認することです。アクティブなトラフィックフローを識別し、**選択されたNIC**の下で興味のあるトラフィックのための選択されたトランスポートが表示されます。予想されるトランスポートが選択されていない場合、[オフクラウド](/v1/docs/routing-traffic-to-an-off-cloud-link)または[アルトWAN](/v1/docs/integrating-cato-with-an-alt-wan-network)が正しく設定されていることを確認してください。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17140100662173.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) #### ネットワークルールの注文の確認 [オフクラウドまたはアルトWANリンク上のTLS接続失敗](/v1/docs/tls-connection-failure-over-off-cloud-or-alt-wan-links)で説明されているように、トラフィックがTLSであってTLSインスペクションが有効になっている場合、ネットワークルールの注文がオフクラウドまたはアルトWANリンクを介してトラフィックフローを確保するための重要な要素です。 ネットワークルールが複雑なルールの下にあるとき、ソケットはネットワークルールを評価し、パケットをオフクラウドまたはアルトWAN経由でルートすることができません。この予想される動作を解決するには、[ネットワークルール注文](/v1/docs/network-rule-evaluation-troubleshooting#network-rule-ordering)を参照してください ## 見つかった問題の解決 ### 重複するカスタムアプリケーションの解決 カスタムアプリケーションには正しいIPアドレス、ドメイン、ポート、プロトコルを含めることを確認してください。識別のために選ばれるカスタムアプリには論理がないため、カスタムアプリは他のカスタムアプリとの重複を避けるために、ユニークに定義されなければなりません。詳細は[カスタムアプリケーションの使用](/v1/docs/working-with-custom-apps)を参照してください ### ネットワークルールの注文 ネットワークルールはその順序に従って評価されることを念頭に置いてください。そのため、より一般的なルールの上により詳細なルールを定義することが重要です。例えば、カスタムアプリケーション、ビルトインアプリケーション、ドメイン、FQDN、カスタムサービスを定義するネットワークルールは、カテゴリ、カスタムカテゴリ、またはサービスを含むネットワークルールの上に配置する必要があります。 下のスクリーンショットでは、ルール#1はtwitter.com用のIP範囲を含むカスタムサービスを含んでおり、アプリケーションカテゴリを含むルール#2の上に配置されています。ルール#1はルール#2よりも具体的であり、*twitter.com*に向けられたトラフィックに対してより適した一致となりますこれにより、ルール#1が単純なルールであるため、TCP加速が無効化され、オフクラウドまたはアルトWANルーティングの問題が解決されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16997600002845.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A41%3A16Z&se=2026-11-10T17%3A41%3A16Z&sr=c&sp=r&sig=pQKVCqF9%2FhiFmfnLdGKoIl%2Free1pT94WdUCcAvXRMao%3D) ### ドメイン名の問題の解決 ドメイン/FQDNに基づくネットワークルールの一致問題は、以下のように解決できます： - HTTP/Sのようなプロトコルの場合、Catoは次のソースを使用して宛先ドメインを特定できます： - **HTTPホスト名ヘッダー**（TLSインスペクションが有効になっている場合） - TLSハンドシェイク中の**SNI**フィールド - **DNS解決**では、DNSクエリとレスポンスからドメイン名が学習されます - ネットワークルールに指定されたドメインがこれらのすべてのソースで一貫していることを確認することが重要です。唯一最適に一致したドメイン名（トップからボトムまで評価）がファイアウォールイベントで**ドメイン名**として表示されます。 - SSHやSMBなどのプロトコルでプレーンテキストでドメインを送信しないものについては、Catoは専ら**DNSインターセプション**に頼ってトラフィックをドメインやFQDNと関連付けます。プライベートDNSを使用している場合、特に重要です。DNSクエリ/レスポンスがCatoを通過する必要があります。 [DNSとCatoアカウントのベストプラクティス](/v1/docs/best-practices-for-dns-and-your-cato-account)を参照してください ### Egress PoP選択の変更 アカウントのすべてのEgressルールを宛先に最も近いPoP（標準の動作では送信元に近いPoPではなく）経由でルートしたい場合は、[ケースをCatoサポートへ立ち上げる](/v1/docs/network-rule-evaluation-troubleshooting#raising-a-case-to-cato-support)ことでCato Networks Supportにお問い合わせください。 SIPプロトコルを利用するVoIPアプリケーションで常に同じEgress IPを使用する必要がある場合は、事前設定の詳細で[SIPトラフィック用優先IP](/v1/docs/working-with-advanced-configuration-for-the-account)オプションを有効にします。 異なるVoIPプロトコルまたはその他のアプリケーションで常に同じEgress IPを使用する必要がある場合は、[ケースをCatoサポートへ立ち上げる](/v1/docs/network-rule-evaluation-troubleshooting#raising-a-case-to-cato-support)ことでCato Networks Supportにお問い合わせください。 ## ケースをCatoサポートへ立ち上げる 上記のトラブルシューティングステップの結果を使用して[サポートチケット](/v1/docs/submitting-a-support-ticket)を提出してください。チケットに以下の情報を含めてください： - 経験された問題の詳細とユーザーへの全体的な影響。 - 関連するファイアウォールイベントとネットワークルールの設定。 - 問題を再現し、[サポートセルフサービス](/v1/docs/support-self-service-supportme-portal)を実行します。ツールによって生成されたチケット番号を含めてください。