Jitsi Meetの「ブリッジへの接続に失敗しました」エラーを修正する方法

Jitsi Meet ルームを開くと、ページは正常に読み込まれ、シグナリングも正常に機能しているように見えるかもしれませんが、会議でメディアが確立されません。代わりに、Jitsi は「ブリッジへの接続に失敗しました」と報告するか、参加中に繰り返し切断されます。セルフホスト型のデプロイメントでは、このメッセージは通常、ブラウザとJitsi Videobridge (JVB)の間、または Jicofo とブリッジ自体の間の問題を示しています。

トラブルシューティングを迅速に行うには、サーバー側から順に確認していくのが最善です。まず、JVBが実行され、登録されていることを確認し、次にメディアポートにアクセス可能であることを確認し、NAT/パブリックアドレスの処理を検証してから、クライアント側のネットワーク制限を調査してください。Jitsiの公式セルフホスティングガイドでは、デフォルトのメディアパスとしてUDPポート10000が記載されており、各会議のビデオブリッジの選択はJicofoが担当します。

エラーが通常意味すること

Jitsi Meetは複数のコンポーネントで構成されています。WebインターフェースとProsodyがシグナリングを処理し、Jicofoが会議を調整し、Jitsi Videobridgeが音声およびビデオストリームを転送します。ブラウザがWebページにアクセスできてもJVBとのメディア接続を確立できない場合、またはJicofoに正常なブリッジが利用できない場合、会議はブリッジ段階で失敗する可能性があります。

現在の Debian/Ubuntu インストールの場合、Jitsi では次のネットワーク要件を文書化しています。証明書の検証と更新には TCP 80、Web アクセスには TCP 443、一般的なオーディオ/ビデオには UDP 10000、オプションの STUN クエリには UDP 3478、UDP がブロックされている場合の coturn ベースのフォールバック メディアには TCP 5349 を使用します。公式の Jitsi Debian/Ubuntu セルフホスティング ガイドを参照してください。JVB の現在のリファレンス構成でも、 Jitsi Videobridge リファレンス構成のデフォルトの ICE/UDP ポートとして UDP ポート 10000 が示されています。

1. Jitsi Videobridgeが実行されていることを確認します。

エラーメッセージに記載されているコンポーネントから始めます。標準的なパッケージベースのインストールでは、以下を実行します。

sudo systemctl status jitsi-videobridge2

確認したいのはactive (running)、ユニットが故障した場合、再起動することで一時的にサービスが復旧する可能性がありますが、そこで止まらず、ログを確認して停止した理由を調べてください。

sudo systemctl restart jitsi-videobridge2
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

バインドの失敗、認証エラー、XMPP接続の失敗、ICEの問題の繰り返し、または有効なアドレスが利用できないことを示すメッセージを探してください。systemdステータスがアクティブだからといって、JVBが使用可能であるとは限りません。Javaプロセスが実行されている場合でも、メディアネットワークやXMPP登録が壊れている可能性があります。

2. UDP 10000番ポートがリッスンしており、ホストファイアウォールで許可されていることを確認します。

JitsiのデフォルトのJVBメディアポートはUDP 10000です。まず、サーバーがリッスンしていることを確認してください。

sudo ss -lunp | grep ':10000'

何もリッスンしていない場合は、/etc/jitsi/videobridge/jvb.confファイアウォールルールを変更する前にJVBログを確認してください。ポートがリッスンしている場合は、ホストファイアウォールを確認してください。

sudo ufw status verbose

UFWを使用するUbuntuサーバーでは、Jitsiのガイドでは以下のように説明しています。

sudo ufw allow 10000/udp
sudo ufw status verbose

UFWの代わりにfirewalld、nftables、iptables、またはクラウドファイアウォールを使用している場合は、同等の受信UDPルールをそこに追加してください。よくある間違いは、UbuntuでUDP 10000を開放しているにもかかわらず、AWSセキュリティグループ、Azureネットワークセキュリティグループ、Google Cloud VPCファイアウォール、VPSプロバイダーファイアウォール、または上位のハードウェアファイアウォールによってブロックされたままになっていることです。

3. サーバーがNATの背後にある場合、ルーターのポートフォワーディングを確認してください。

Jitsiがプライベートアドレス（例：）で動作している場合192.168.x.x、UFWを開放するだけでは不十分です。エッジルーターは、外部UDPメディアポートをJVBを実行しているマシンに転送する必要があります。シンプルなシングルサーバー構成の場合、通常はUDP 10000をJitsiサーバー上のUDP 10000に転送することになります。

JVBのポートを変更した場合は、10000番ポートをむやみに開くのではなく、設定済みの値を使用してください。また、他のマシンやコンテナがそのポートを使用していないことを確認してください。ポート転送画面はルーターによって異なるため、この図は設定例であり、お使いのデバイスの正確なUIマップではないことをご了承ください。

4. 公開アドレスと非公開アドレスのマッピングを修正する

NATはより微妙な障害を引き起こす可能性があります。ルーターが正しいポートを転送しているにもかかわらず、JVBがインターネットクライアントにプライベート候補を通知する場合があります。Jitsiの現在のクイックスタートドキュメントでは、/etc/jitsi/videobridge/jvb.conf明示的なローカルアドレスからパブリックアドレスへの変換が必要なシステム向けに静的マッピングが示されています。

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "<Local.IP.Address>"
          public-address = "<Public.IP.Address>"
        }
      ]
    }
  }
}

プレースホルダーを、JVBホストの実際のプライベートアドレスと、リモートクライアントがアクセスできるパブリックアドレスに置き換えてください。その後、JVBを再起動してください。

sudo systemctl restart jitsi-videobridge2

この設定は、お使いのネット​​ワーク構成に合致する場合にのみ使用してください。直接パブリックアドレスを持つサーバー、Docker環境、複数のNIC、IPv6、またはより複雑なNAT構成の場合は、異なる設定が必要になる場合があります。具体的な設定例は、JitsiクイックスタートNATのセクションに記載されています。

5. Dockerの場合、JVB UDPポートが実際に公開されていることを確認します。

Docker環境では、JVBコンテナがメディアポートを公開していない場合、ホスト上のファイアウォールルールが正しくても効果はありません。JitsiのDockerドキュメントでは、JVB_PORTデフォルト値として10000が挙げられており、管理者はホスト上でUDP 10000を開放するように指示されています。実行中のデプロイメントを確認してください。

docker compose ps
docker compose logs --tail=200 jvb

次に、Composeファイルと環境ファイルを調べて、JVBサービスが意図したUDPポートを公開していることを確認してください。 を変更した場合はJVB_PORT、ホストマッピング、ファイアウォールルール、およびNAT転送がすべて一致している必要があります。サードパーティのチュートリアルから古いComposeスニペットをコピーするのではなく、公式のJitsi Dockerセルフホスティングガイドを参照してください。

6. Jicofoがビデオブリッジを認識できることを確認します。

JVBがXMPPコントロールプレーンに登録されない場合、UDPポートが完全にアクセス可能であっても十分ではありません。Jicofoは会議用にビデオブリッジを選択しますが、Jitsiのスケーラブルな展開ガイドでは、ブリッジが接続され、認識されていることを確認するために、サービスを再起動した後、ProsodyとJicofoの両方のログを確認することを推奨しています。

sudo journalctl -u jicofo -n 200 --no-pager
sudo journalctl -u prosody -n 200 --no-pager
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

XMPPドメインをカスタマイズした場合、または複数のノードを実行している場合は、JicofoとJVBが同じブリッジ「brewery」MUCを使用していることを確認してください。Jitsi Videobridgeの公式MUCドキュメントには、Jicofoはjicofo.bridge.brewery-jidVideobridgeインスタンスで使用されているMUCと同じMUCを指している必要があると記載されています。

これは、ホスト名の変更、移行、スプリットホスト展開、または手動による設定編集を行った後に特に重要です。公式インストーラーで作成された標準パッケージのインストールでは、ログに登録または認証の問題が実際に示されている場合を除き、XMPP設定を書き換えることは避けてください。

7. 制限的なクライアントネットワーク、VPN、またはプロキシを除外する

サーバーが一部のユーザーには正常に動作するのに他のユーザーには動作しない場合は、サーバー設定を変更する前に別のネットワークからテストしてください。社内ネットワーク、ゲストWi-Fi、VPN、および厳格なプロキシはUDPをブロックする可能性があります。VPNまたはプロキシを一時的に切断することは、診断テストとして有効です。組織の要件に応じて、テスト後に再接続してください。

JitsiのDebian/Ubuntuガイドでは、UDPがブロックされている場合の音声/ビデオのcoturnフォールバックパスとしてTCP 5349が記載されています。制限のあるネットワーク上のユーザーが確実に接続できるようにする必要がある場合は、Webサイトに対してTCP 443を開放すれば自動的にメディアフォールバックが提供されると想定するのではなく、TURN/coturnの設定を確認してください。

8. サーバーチェックに合格した後、クリーンなブラウザセッションで再試行してください。

参加者全員が同じブリッジエラーを目にする場合、ブラウザセッションの不具合よりもJVBルートの破損の方が可能性は低いですが、この問題はすぐに解決できます。ルームを再読み込みするか、プライベートブラウジングウィンドウを試すか、認証が有効になっている場合はJitsiドメインのサイトデータをクリアして再度サインインしてください。

エラーが異なるブラウザやネットワークで再現する場合は、ブラウザデータを繰り返しクリアするのではなく、サーバー側のチェックに戻ってください。

修正が実際に機能したことを確認する方法

エラーポップアップが消えたからといって、問題が解決したとみなさないでください。メディアパス全体をテストしてください。

• 新しいルームを作成し、2台のデバイスから参加してください。
• 可能であれば、デバイスを異なるネットワークに接続してください。例えば、一方を自宅のブロードバンドに、もう一方をモバイルデータに接続するなどです。
• 音声と映像が数分間、双方向で正常に流れていることを確認してください。
• 会議参加中はJVBとJicofoのログを監視し、ICEまたはブリッジの状態に関するエラーが繰り返し発生していないブリッジに会議が割り当てられていることを確認してください。
• sudo ss -lunp | grep ':10000'再起動後またはファイアウォールに変更を加えた後は、ファイアウォールの状態チェックを再度実行してください。

複数のブリッジを使用するインストール環境では、複数の会議をテストしてください。Jitsiのスケーラブルなセットアップガイドによると、Jicofoは新しい会議用にビデオブリッジを選択するため、1つのブリッジに不具合があると、他のブリッジが正常に動作していても断続的な障害が発生する可能性があります。

クイック診断表

結論

セルフホスト型の Jitsi Meet サーバーの場合、「ブリッジへの接続に失敗しました」というエラーは、まずメディアパスまたはブリッジ登録の問題として対処するのが最善です。Jitsi Videobridge が正常に動作していること、UDP 10000 がリッスンしており、すべてのファイアウォール/NAT レイヤーで到達可能であること、NAT が関係する場合に JVB が使用可能なパブリック アドレスを通知していること、そして Jicofo がブリッジを認識していることを確認してください。これらの確認が完了してから初めて、ブラウザのキャッシュや個々のクライアント設定に時間を費やすべきです。

具体的な修正方法はトポロジーによって異なりますので、過去のフォーラム投稿に記載されているからといって、古いJitsi設定キーを適用しないでください。上記のコマンドと設定は、2026年10月に確認された最新の公式Jitsiハンドブックおよび最新のJitsi Videobridge設定ソースに準拠しています。