Jitsi Meetで「接続が切断されました」というエラーメッセージが表示される問題を修正する

Jitsi Meet の通話で「接続が切断されました」と表示されるのは、会議のシグナリング接続が切断された場合、WebRTC メディアトラフィックがビデオブリッジに到達できない場合、またはローカルネットワークやブラウザがセッションを中断した場合です。まず、問題が参加者のうち 1 人だけに影響しているのか、全員に影響しているのかを確認してください。この違いによって、デバイスとネットワークのトラブルシューティングを行うべきか、Jitsi サーバーのトラブルシューティングを行うべきかが判断できます。

迅速なトリアージチェックリスト

複数の設定を一度に変更しないでください。変更内容を一つずつテストし、可能であれば同じ会議に再参加して、症状が変化するかどうかを確認してください。

まず、どの接続が失敗したかを特定します。

Jitsi Meetは、リアルタイムの音声とビデオにWebRTCを使用します。ミーティングはページの読み込みだけでなく、ブラウザがサーバーとのシグナリングを維持し、Jitsi Videobridgeへのメディアパスを確立するなど、多くの要素に依存しています。参加者は、メディアがフリーズしている間もルーム内で表示され続けることがあります。「接続が切断されました」というメッセージが表示される場合は、セッション全体またはシグナリングの中断を示している可能性があります。このメッセージだけでは、正確な原因を特定することはできません。

接続が切断された時刻、ブラウザに再接続を促すメッセージが表示されたかどうか、他の参加者に影響があったかどうか、会議がmeet.jit.siで開催されていたか、それともプライベートなJitsiドメインで開催されていたかを記録してください。プライベートな会議のURL、ルーム名、アクセストークン、編集されていないログを公開しないでください。

ブラウザを使用している参加者を確認します

1. 一度再接続して、会議リンクを確認してください。

画面に再接続ボタンが表示された場合は、それを使用してください。会議が復旧しない場合は、元の招待リンクを新しいタブで再度開き、再参加してください。ルーム名とホストドメインが招待と一致していることを確認してください。入力ミスや古いリンクでは、別のルームやホストに接続されてしまう可能性があります。全員が切断された場合は、しばらく待ってから、会議主催者にサービスがまだ利用可能かどうか問い合わせてから、繰り返し更新してください。

2. サポート対象の最新ブラウザでテストする

ブラウザをアップデートし、完全に終了してから、もう一度ミーティングを試してください。接続が切断される場合は、Jitsiがサポートする別の最新ブラウザをお試しください。Jitsiのサポート対象ブラウザ一覧には、ブラウザのサポート状況とプラットフォームに関する注意事項が記載されています。サポート内容は変更される可能性があるため、必ずこのページをご確認ください。iPhoneとiPadでは、異なるブラウザブランドでも同じ基盤となるブラウザエンジンを使用しているため、別のブランドを試してもブラウザエンジンの問題を特定できない場合があります。

正確な比較を行うには、プライベートウィンドウを使用するか、スクリプトをフィルタリングしたり、トラッカーをブロックしたり、ネットワーク要求を変更したりする拡張機能を一時的に無効にしてみてください。それで問題が解決する場合は、拡張機能を1つずつ有効にして、競合の原因を特定してください。セキュリティ保護を無効にしたままにしておくことは、恒久的な回避策として行わないでください。

3. ネットワークを比較する

Wi-Fiアクセスポイントに近づき、大容量のダウンロードやクラウドバックアップを一時停止し、使用権限のある別のネットワークで一度テストしてください。スマートフォンのホットスポット機能を使用すると、自宅や職場のネットワークの問題とブラウザやサーバーの問題とを区別するのに役立ちます。Jitsiが別のネットワークでは正常に動作するのに、元のネットワークでは繰り返し切断される場合は、ネットワーク管理者にテスト日時を伝え、リアルタイムのWebRTCトラフィックがフィルタリングされているかどうかを尋ねてください。

VPN、プロキシ、キャプティブポータル、またはファイアウォールは、シグナリングやメディアを遮断する可能性があります。組織でVPNが必要な場合は、ポリシーを迂回せず、Jitsiホストが許可されているかどうかをIT部門に確認してください。VPNを切断した状態で比較することが許可されている場合でも、短時間のみ実行し、その後VPNを再度有効にしてください。

4. デバイスとアプリの状態を確認する

スマートフォンでは、テスト中はJitsiアプリまたはブラウザをフォアグラウンドで実行したままにし、デバイスが許可する場合はテスト中のみバッテリー節約機能を無効にしてください。モバイルOSによっては、バックグラウンドでのネットワークアクティビティが一時停止される場合があります。また、アプリとOSが最新の状態であることを確認し、接続が引き続き失敗する場合はデバイスを再起動してください。マイクまたはカメラのアクセス許可の問題は、ネットワークの切断ではなく、デバイスへのアクセスに影響を与えることが多いため、これらの症状は個別に対処してください。

音声/ビデオに障害が発生しても、会議ページが開いたままの場合

カメラを一時的にオフにして、音声が安定するかどうかを確認してください。これにより帯域幅の使用を削減できますが、壊れたサーバー経路は修復されません。 1 つのネットワークで音声とビデオが同時に失敗し、他の場所では機能する場合は、ファイアウォールまたは NAT の制限を調査してください。 Jitsi のセルフホスティングガイドでは、一般的な Web アクセスには TCP 443、通常の音声/ビデオ会議には UDP 10000、UDP がブロックされた場合の coturn フォールバックには TCP 5349 が指定されています。オプションの STUN の使用には、UDP 3478 も含まれる場合があります。 これらはサーバー側の展開要件であり、参加者が個人デバイスで開くべきポートではありません。最新のJitsi ファイアウォールおよび NAT ガイダンスを参照してください。

会議が別の接続で正常に動作する場合は、その比較結果をネットワーク管理者に報告してください。ファイアウォールの全面的な停止を要求するのではなく、Jitsiホスト名とWebRTCトラフィックに関する組織のルールを見直すよう依頼してください。

自己ホスト型のJitsi管理者を確認します

到達可能性とメディア経路を確認してください

パブリックDNS名が想定されるサーバーに解決されること、TLS証明書が有効であること、および必要なトラフィックが正しいホストに到達することを確認してください。サーバーがルーターまたはクラウドファイアウォールの背後にある場合は、ホストファイアウォールとアップストリームのセキュリティグループまたはポートフォワーディングルールの両方を確認してください。クラウドファイアウォールが同じトラフィックをブロックしている場合、UFWのルールは役に立ちません。

sudo ufw status verbose
sudo ss -lntup

これらのコマンドはローカルファイアウォールルールとリスニングソケットを表示するものであり、外部参加者がサービスにアクセスできることを証明するものではありません。外部ネットワークからテストを行い、ルーターまたはプロバイダが関連するトラフィックをJitsi Videobridgeに転送していることを確認してください。Jitsiは、NATの背後にある環境では、外部からの通話が機能しない場合、パブリックアドレスとローカルアドレスのマッピングを正しく行う必要がある場合があると指摘しています。

TLS、リバースプロキシ、およびDockerの設定を確認してください。

リバースプロキシ環境の場合、HTTPSが正しく動作し、プロキシがWebSocketシグナリングを正しく転送していることを確認してください。公式のDockerガイドには、Nginxの例で必要なルートとヘッダーが記載されています/xmpp-websocket。ページは配信するもののWebSocketを破棄するプロキシでは、ユーザーが会議セッションを維持できなくなる可能性があります。

Docker Composeを使用する場合は、PUBLIC_URLパブリックドメインの訪問者が実際に使用するものと一致すること、および公開されているホストポートがファイアウォールとプロキシの設定と一致していることを確認してください。Jitsiガイドでは、HTTPSではなくHTTPで直接実際の会議を提供するとWebRTCに問題が発生する可能性があると警告しています。実行しているバージョンとデプロイ方法を確認せずに、別のJitsiリリースから構成スニペットをコピーすることは避けてください。

サーバーログとインシデント発生時刻を関連付ける

切断時刻をサービスログと比較してください。DebianまたはUbuntuパッケージのインストールでは、Jitsiは/var/log/jitsi/jvb.log、、、/var/log/jitsi/jicofo.logなどのログファイルを記録します/var/log/prosody/prosody.log。Dockerデプロイメントでは、ログはコンテナ内に保存されるため、インストールしたリリースの関連するコンテナ出力と構成ディレクトリを確認してください。

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

インシデントのタイムスタンプ付近で、サービスの再起動、ブリッジ登録の変更、WebSocketの失敗、証明書のエラー、または接続タイムアウトの繰り返しなどを検索してください。ログを共有する前に、参加者識別子、ルーム名、IPアドレス、トークンは削除してください。Debian /Ubuntuのセルフホスティングガイドでは、基本的なデバッグ手順として、別のブラウザを試したり、WebRTCのサポート状況を確認したり、ファイアウォール/NATルールを見直したりすることも推奨しています。

エスカレーションチェックリスト

• Jitsiホスト、おおよそのタイムスタンプとタイムゾーン、デバイス、オペレーティングシステム、ブラウザまたはアプリのバージョン、そして問題が特定の個人に影響しているのか、会議全体に影響しているのかを記録してください。
• 別のブラウザやネットワークを使用した場合に結果が変わるかどうかを記録してください。
• 自社サーバーの場合は、最近のプロキシ、ファイアウォール、DNS、証明書、またはJitsiのアップグレードを含めてください。
• 個室の詳細や認証情報は削除し、必要最低限​​の診断情報のみを共有してください。
• meet.jit.siまたはその他のマネージドホストを使用している場合は、会議の主催者またはサービスサポートにレポートを送信してください。参加者は、そのホストのファイアウォールやサーバー設定を変更することはできません。

修正を確認する方法

元のデバイスとネットワークからテストミーティングに参加し、通常障害が発生する期間をカバーするのに十分な時間接続を維持し、音声とビデオが引き続き使用できることを確認してください。問題が全員に影響している場合は、別の参加者と再度テストを繰り返してください。セルフホスト型のデプロイメントの場合は、サーバーのネットワーク外からブラウザのシグナリングとメディアの両方を確認してください。ページの読み込みが成功するだけでは不十分です。ミーティングは接続が維持され、参加者は音声とビデオをやり取りできる必要があります。