--- title: "ソケットサイトトンネル接続トラブルシューティング" slug: "socket-site-tunnel-connectivity-troubleshooting" updated: 2026-07-30T01:29:53Z published: 2026-07-30T01:29:53Z canonical: "knowledge.catonetworks.com/socket-site-tunnel-connectivity-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. # ソケットサイトトンネル接続トラブルシューティング ## 概要 サイトの接続は、ソケットの背後にいるホストが、Catoクラウド経由でWANにアクセスするために最も重要です。 サイトの接続が欠如すると、ビジネス機能に支障をきたす可能性があります。 このプレイブックは、このシナリオについてのトラブルシューティングの指針を提供します。 ## 症状 ソケット接続の失敗は、いくつかの方法で現れることがあります。 管理者は次のような症状を確認することができます： - CMAでサイトが切断されています - サイトが予期しないPoPに接続しています - ネットワークアナリティクスがトンネルが不安定であることを示しています ## 可能性のある原因 トラブルシューティング中に特定できる可能性のある原因が以下に示されています - ソケット接続なし - 一方向のみのDTLSトラフィック - 低パフォーマンスのアンダーレイ - IPジオロケーション制限 - 不適切なPoP選択設定 - 誤ったベースラインでのSLA設定 - ソケットの前のNATデバイス ## 問題のトラブルシューティング 管理者が遭遇する可能性のある症状をトラブルシューティングするための手順は以下の通りです。 これらの手順は直面する問題の可能性を特定することを目的としています。 解決手順は後のプレイブックで詳述します。 ### CMAで切断されたサイトのトラブルシューティング #### イベントから情報を収集する CMAで**ホーム** > **イベントページ**を使用して、アカウント内のサイトの接続イベント履歴を迅速に確認できます。 「サイト接続状態」プリセットを選択するか、イベントタイプ「接続性」とサブタイプ「切断」をフィルタリングすることによって、関連するイベントに絞り込むことができます。 「ソースサイト」フィールドを使用して、問題のサイトの名前でさらにフィルタリングすることができます。 ![Monosnap Cato｜Liam-lab - イベント 🔊 2024-02-22 13-28-40.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16955207476125.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 問題のサイトからの関連する切断イベントのタイムスタンプを確認すると、調査の焦点を絞るのに役立ちます。 この時点でどのようなネットワーキングイベント、もしくはローカルの電力イベントが発生しているか、知っていることがありますか？ この監査証跡に関連する[変更](https://support.catonetworks.com/hc/en-us/articles/4413273463953-Using-the-Admin-Audit-Trail)があるか確認して関連付けることができますか？ #### ソケット接続の確認 ソケットの接続要件を理解するために、[Cato Socket Connection Prerequisites](/v1/docs/cato-socket-connection-prerequisites-and-known-limitations)をご覧ください。 ソケットの接続状況は、ローカルWebUIを介して表示することができます。[ソケットのWebUIへのログインをご覧ください。](/v1/docs/accessing-the-socket-webui#logging-in-to-the-socket-webui-locally-for-a-new-or-reimaged-socket)ソケットが接続されるには、Catoクラウドへの接続に使用されるWANポートが緑のステータスアイコンを示す必要があります。 緑以外のアイコンは接続の問題を示唆しています。 異なるステータスアイコンの色の意味は、[リンクステータスアイコンの理解](/v1/docs/accessing-the-socket-webui)で説明されています ![サムネイル_images.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16955175451165.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 赤色のアイコンの場合、ソケットとISPデバイス間に動作する物理的なリンクがあることを確認してください。 これには、ケーブルが確実に接続されていることと、ポートLEDが予想通りに点灯することが含まれます。 IP競合もソケット接続ステータスで検出されます。 IP競合の警告は、[このKB](/v1/docs/ip-address-conflict-reported-on-socket-ui-even-after-it-s-resolved)で説明されているように、競合が最初に検出されてから24時間表示され続けます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/18529219826461.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) **ツール**内の**インターネットバイパスによるフォースリカバリー**ステータスが通常であることを確認してください。 「フォースバイパス」ボタンを押すと、LANトラフィック全体がCatoをバイパスし、Catoトンネルを停止し、CMAでサイトが切断されていることを示します。 したがって、このデバイスへのすべてのリモート構成とアクセスは失敗します。 HAセットアップでは、プライマリソケットが「フォースバイパス」を有効にしている場合、セカンダリソケットは引き続きバックアップソケットとして残り、ソケット背後のトラフィックはインターネットに直接ルーティングされます。 次のスクリーンショットは、プライマリソケットで「フォースバイパス」が有効になっており、セカンダリソケットが待機中の状態であることを示しています ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/28642248797725.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 強制リカバリーステータスがアクティブな場合、「強制バイパス終了」ボタンをクリックしてこの状態から抜けます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22610138722845.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 接続の問題が発生した場合、**ツール**タブを使用してさらにテストを行うことができます。 Catoに接続するには、ソケットがCatoのパブリックIPアドレスへのL3アクセスを必要とします。 WANポートを介してソケットがCato IPアドレスやドメイン、および8.8.8.8のような著名で到達可能なIPアドレスに到達できることを確認するために、pingツールを使用します。 どれも到達できない場合、[ソケット接続なしの解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-no-socket-connectivity)セクションをご覧ください。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16955207509917.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) #### パケットキャプチャを実行中 [パケットキャプチャ](/v1/docs/how-to-capture-traffic-on-a-socket)を実施して、ソケットのDTLSトンネルの接続要求がPoPに応答されることを確認できます。 問題のWANポートでキャプチャする際には、PoPへのUDP/443の双方向パケットが確認されるべきです。 次のスクリーンショットは、成功したDTLSハンドシェイクと、**アプリケーションデータ**パケットの交換を示しています。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/19742398244637.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) アウトバウンドDTLSパケットが検出されたり、DTLSハンドシェイクが完了していない場合は、[不完全なDTLSハンドシェイクの解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-incomplete-dtls-handshake)を参照ください。 #### NATデバイスがソケットの前にあるためにトンネルの確立ができない 複数のWANリンクを使用するソケットの場合、ソケットとPoPの間にNATデバイスがあると、一部のWANリンクがPoPに接続できない可能性があります。 これによって接続の問題が発生する可能性があり、例えば、サイトのHAステータスが準備完了ではないという状態になります。 PoPは各着信DTLS接続の送信元ポートを使用して、各WANリンクを同じロジカルトンネルに接続します。 NATデバイスが送信元ポートを変更し、WANリンクが他のWANリンクと同じロジカルトンネルに接続できない場合があります。 #### LTE/5GプロバイダーでのDTLS接続の失敗 この[ケーススタディ](/v1/docs/socket-site-is-disconnected-with-lte-5g-providers)で述べたように、LTE/5GプロバイダーがCatoに接続するために使用されている場合、ISPがUDP/443ポートでのDTLSハンドシェイクに干渉する可能性があり、このハンドシェイク中にキャリア固有のデータ（例えば、APN）が見られることがあります。 双方向のDTLS通信が行われているにもかかわらず、ハンドシェイクが完了していないため、Catoトンネルは起動しません ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/20255496885661.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) この問題を解決するには、DTLSポートをUDP/1337に変更してください。[不完全なDTLSハンドシェイクの解決をご覧ください。](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-incomplete-dtls-handshake) ### 予期しないPoP選択のトラブルシューティング #### ISPのIPアドレスと現在選択されているPoPを確認 モニタリングの下で、サイトを選択し、そのサイトの概要ペインを開きます。 サイトソケットセクションで「ログを表示」をクリックして最近のすべての接続を確認します。 ISPのパブリックIP（リモートIP）がCatoに接続していることを確認し、ISPの名前と場所を確認します。 「PoP」列は、サイトが現在接続されているPoPを表示します。 リモートIPとISPの場所が期待されるものであることを確認し、ISPが予期しない場所を経由して接続をバイパスしていないことを確認することが重要です。 ISPの場所（都市）がサイトの一般設定内で指定された国/都市に一致するか、または近接する必要があります。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21454560091549.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) #### CMAでのPoP選択設定を確認 サイトの古いまたは誤った設定されたPoPの優先位置が不適切なPoPへの接続を強制させる可能性があります。 PoP選択設定は、**ネットワーク** > **サイト** > **サイト設定** > **一般**ページを通じてサイトごとに表示できます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16958089925533.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) ここに設定されている場所が、最適な接続には適さない場合、またはCato PoP選択メカニズムに最適なPoPを決定させることを希望する場合は、[不適切なPoP選択設定の解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-unsuitable-pop-selection-config)を参照してください。 #### ソケットでのPoP選択設定の確認 ソケット設定にも古いまたは適切でないPoP選択の設定が存在する可能性があります。 これがケースであるか確認するには、ソケットのWebUIにあるクラウド接続設定に移動し、[ソケットWebUIの使用](/v1/docs/accessing-the-socket-webui)をご覧ください ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16959394681629.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) ここに設定が存在し、Cato PoP選択メカニズムに最適なPoPを決定させることを希望する場合は、[不適切なPoP選択設定の解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-unsuitable-pop-selection-config)セクションをご覧ください。 #### PoPステータスの確認 最寄りの地理的PoPがメンテナンスや他の問題によって影響を受けているため、ソケットが予期しないPoPへの接続を行う可能性があります。 [PoPステータス](https://status.catonetworks.com/)ページをご覧になり、これがケースかどうかを確認してください。 #### ジオロケーション用のロケーション制限を確認 Cato MSAによれば、一部のジオロケーションにあるソケットサイトは、他の場所のPoPへの接続が制限されています。 MSAはCatoサービスの購入時に定められています。 一部のジオロケーションにあるソケットサイトは利用可能なPoPのプールに制限されます。例えば、中国のソケットサイトは中国内のPoPに接続し、ベトナムのソケットサイトはアジア内のPoPのプールに接続します。 これに関する詳細情報については、[MSA](https://www.catonetworks.com/msa/)を参照してください。 #### ソケットがPoP間を移動する兆候を確認 イベントページを使用して、接続の問題のためにソケットが元々の最適なPoPにない可能性を判断できます。 フィールドの選択を使用して、異なるPoPへのソケット接続のタイムラインを作成します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16960514306333.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 「サイト再接続」イベントプリセットを使用し、問題のサイトにさらにフィルタリングし、「イベントメッセージ」フィールド値を「パフォーマンス問題検出、Cato Cloud内の別のサービスノードに再接続」に設定することで、トンネル接続パラメーターが設定されたSLAしきい値を超えたためにソケットサイトがPoPを移動したすべてのインスタンスを見ることができます。 複数のPoPに対してSLAしきい値を超えているソケットサイトがある場合は、接続SLA設定を確認するためにトラブルシューティングフローを続けてください。 #### 接続SLAが厳しすぎないことを確認 [接続SLA](/v1/docs/configuring-the-connection-sla-settings-for-active-passive-socket-sites)は、動的ネットワーク環境での最適なPoPへのサイト接続を保証する上で重要な役割を果たします。また、ISPインターネット接続のようなパブリックアンダーレイを含む場合にも重要です。 しかし、接続SLAが厳しすぎると、管理者の希望する場所以外のPoPへの不必要な再接続を引き起こす可能性があります。 サイトごとの接続SLA設定は、**ネットワーク** > **サイト** > **サイト設定** > **接続SLA**で表示できます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16960411903517.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) [ネットワークアナリティクス](/v1/docs/showing-the-site-network-analytics)を使用してラストマイルパフォーマンスメトリクスのベースラインを作成し、このサイトにとってSLAメトリクスが適切であるか考慮してください。 これらのパラメーターが適切でない場合、[誤ったベースラインでのSLA設定の解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-sla-configuration-at-incorrect-baselines)をご覧ください パラメーターが適切であるにもかかわらず、一部のPoPで再最適化イベントが頻繁に発生する場合は、[低パフォーマンスのアンダーレイの解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-poor-underlay-performance)を参照してください。 上記の手順を確認後、ソケットが依然として不適切なPoPへの接続を続ける場合は、[サポートへのチケットを開き](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#raising-cases-to-cato-support)、現在と期待されるPoPを明確にしてください。 ### 不安定なトンネルのトラブルシューティング #### ラストマイルとサイト接続のパフォーマンスの相関関係を確認 特定のサイトがPoPへの接続においてパフォーマンスが悪い場合、パケットロスが基となるISPラインのパフォーマンスによる可能性が高いかどうかを分離することが重要です。 これを行うためには、特定のパフォーマンス問題を時間枠全体で関連づけ、同じ時間枠内のラストマイル全体のパフォーマンスを見てパターンを確認します。 これを行うには、[ネットワークアナリティクス](/v1/docs/showing-the-site-network-analytics)を使用します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16961296090909.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 上の例は、PoPへのサイトトンネルで検出されたアップストリームパケット損失を示しています。 我々は、約10％のスパイクと、時間全体にわたって一定の低レベルの損失を確認することができます。 これを同じ期間のラストマイルのパフォーマンスと比較すると、次のことが確認できます： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16961296096669.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D)ラストマイルにも同じ期間のパフォーマンスの変動が見られますが、10％から20％の一定の損失レベルに影響されていることがわかります。 これから、ソケットからCato PoPへのトンネルのパケットロスは、アンダーレイのパフォーマンスが低いことが原因である可能性が高いことが明らかです。 パフォーマンス問題をトラブルシューティングする際にこれが事実である場合は、[低パフォーマンスのアンダーレイの解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-poor-underlay-performance)をご覧ください #### 類似サイトのクロスリファレンス サイト間で共有されている特性を使用して、問題についての事実を推測する試みができます。 例えば、以下のサイトは接続問題があります。 接続されたPoPがロンドンであることに注意してください： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/19376778301213.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) この情報を使用して、ロンドンに接続されている他のサイトを参照し、問題を共有しているか確認することができます。 これは以下のスクリーンショットで確認できます： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/19376787823261.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) クロスリファレンスがCato PoPに問題があることを示唆している場合は、セクション[PoPステータスの確認](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#check-pop-status)をご覧ください。 クロスリファレンスは、共有されているISPがあるサイトにも有用です。 以下の例で行われています： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/19376778317341.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) この相互参照によりISPに接続の問題がある場合、[接続性の低い基盤の性能を解決する](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-poor-underlay-performance)セクションを表示してください。 #### 接続SLAが甘すぎないか確認する [接続SLA](/v1/docs/configuring-the-connection-sla-settings-for-active-passive-socket-sites)は、特にISPインターネット接続のような公開下敷きのある動的ネットワーク環境で、サイトが最適なPoPに接続されていることを確保する重要な役割を果たします。 ただし、甘すぎる接続SLAは、ソケットがPoPへの最適でない接続を管理者が望むよりも長く保持する原因となり、敏感なアプリケーションに影響します。 サイトごとの接続SLA構成は、ネットワーク > サイト > サイト設定 > 接続SLAで確認できます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16961513519389.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) [ネットワークアナリティクス](/v1/docs/showing-the-site-network-analytics)を使用して最後のマイルのパフォーマンス測定の基準を構築し、このサイトにSLA測定基準が適しているかを考慮してください。 これらのパラメータが適していない場合、[不適切な基準でのSLA構成の解決](/v1/docs/socket-site-tunnel-connectivity-troubleshooting#resolving-sla-configuration-at-incorrect-baselines)を表示してください。 ## 発見された問題の解決 ### ソケット接続性がないことの解決 接続の問題がソケットのみに影響を与えるかどうかを特定することが重要です。 同じISP接続にラップトップを接続した場合、同じDNS解決またはアドレスpingの問題に直面しますか？ その場合、ISPに連絡して進行させてください。 テスト用のラップトップのIPv6が無効になっていることを確認し、静的IPアドレス割り当ての場合、テスト時にソケットと同じIPを割り当ててください。 接続の問題がソケットに限定されている場合、WebUIの**ネットワーク設定**タブの下でIP設定が正しいことを確認してください： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16955207519773.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) ### 不完全なDTLSハンドシェイクの解決 プロバイダにUDPポート443でのDTLSトラフィックがインターネットへの出力を許可されていることを確認してください。 必要に応じて、このポートを[Cato PoPに接続するための別ポートの設定](/v1/docs/setting-a-different-port-to-connect-to-the-cato-pop)で説明されているようにUDP/1337に変更できます。 ### 接続性の低い基盤の性能を解決する 基盤のパフォーマンスが低いと、その基盤の上に構築された任意のトンネルに影響します。 基盤はISPの領域ではありますが、パフォーマンスの問題が発生している場所を特定するためのツールや、可能な限り問題の緩和を試みるツールがあります。 ソケットのWebUIには、ISP接続を介して公開アクセス可能なホストにpingを通じて行うことができる[トレースルートツール](/v1/docs/using-the-socket-webui-tools)があります。 公開アクセス可能なホスト名にpingを送信すると、ソケットとサービスの間のl3パスで損失や過剰な遅延が導入されるホップを確認できます。 ![モノスナップ Catoネットワーク - ツール 🔊 2024-02-23 09-52-45.png](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16982481871517.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 上記のインスタンスでは、ISPが提供するL3境界から直接パケット損失が発生していることが明らかです。 最終的には、基盤の問題はISPに持ち込む必要がありますが、CMAの設定が正確であることを確認することで、パフォーマンス問題の影響を緩和できます。 線によって提供される帯域幅に対してソケットインタフェースの帯域幅設定が正確であることを確認してください。 ソケットWebUIのスピードテストツールは、接続のベンチマークを行うために実行できます。 さらに、[バーストパラメータの削減](/v1/docs/troubleshooting-socket-site-packet-loss#18-checking-for-microbursts)がCatoのQoSエンジンを早期に稼働させ、より重要なアプリケーションに有利なように優先度の低いトラフィックを除外することを可能にします。 ### 不適切なPoP選択設定の解決 PoP選択設定を手動で元に戻し、Catoが最適なPoPを選択できるようにするため、まずCMAに手動PoP位置設定がないことを確認し、次にソケットについて同様に行ってください。 CMAでは、ネットワーク > サイト > 一般 > 優先PoPロケーションで行うことができます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16982718414493.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 「自動」が選択されていることを確認してください。 ソケットWebUIで**クラウド接続設定**に移動します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/16982747125917.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A49%3A49Z&se=2026-11-10T17%3A49%3A49Z&sr=c&sp=r&sig=z4f6cua2I6L%2BpBUfJX4fj3K461kKyYVWJQZgcEN0q50%3D) 宛先が「ステアリング」に設定されていることを確認してください。 ### 不適切な基準でのSLA構成の解決 SLA構成が適していることを確認する最初のステップは、サイトから使用される重要なアプリケーションのために必要な閾値または条件を理解することです。 これを拡張するために、例を検討します。 - アプリケーションAは、低レベルのパケットロスに対処可能で、優れたパケット再排序機能を持ちますが、サービスが機能するためにはセッションを維持する必要があります。フローを中断して再作成すると、アプリケーション内に問題が発生します。 - アプリケーションBは、スプロラディックなパケットロスに非常に敏感です。 わずかなレベルでさえも損失がデータ転送を中断させ、転送を最初から再開する必要があります。 とはいえ、制御チャネルはセッションの終了と再接続に非常に強靭です。 アプリケーションAのプロファイルでは、長時間のウィンドウでも低レベルのロスを許容するSLA構成を作成します。PoPへの接続を保持することが好まれます。たとえサービスに影響がある場合でもセッションを維持します。 対照的に、アプリケーションBはより厳しいSLA構成が必要です。 わずかなパケットロスが検出された場合でも、転送の整合性を保護するためにPoPを移動することが好ましいです。 サイトは明らかに、異なるプロファイルおよび要求を持つアプリケーションの混合を使用します。 管理者は、適切なSLAポリシーのためにこれらのニーズをバランスよく考慮する必要があります ## Catoサポートにケースを挙げる このプレイブックに従ったが問題が解決されない場合は、[サポートチケット](/v1/docs/submitting-a-support-ticket)を提出してください。 要請に対する最も役立つ回答を得るために、管理者はこのプレイブックを使用して行った問題解決手順の結果を提供する必要があります。 例えば、以下のものを含む： - 特定のイベントに注意を引くための関連フィルター。 - WebUIテストの結果。 - ネットワーク解析の所見。 - SLA構成の要件。