So beheben Sie den Jitsi Meet-Fehler „Verbindung zur Bridge fehlgeschlagen“

Sie öffnen einen Jitsi Meet-Raum, die Seite wird normal geladen, und die Signalisierung scheint sogar zu funktionieren – doch die Konferenz stellt keine Medienverbindung her. Stattdessen meldet Jitsi „Verbindung zur Bridge fehlgeschlagen“ oder trennt die Verbindung beim Beitritt wiederholt. Bei einer selbstgehosteten Installation deutet diese Meldung in der Regel auf ein Problem zwischen dem Browser und der Jitsi Videobridge (JVB) oder zwischen Jicofo und der Bridge selbst hin.

Die schnellste Methode zur Fehlerbehebung ist, vom Server auszugehen: Prüfen Sie, ob JVB ausgeführt und registriert ist, ob der Medienport erreichbar ist, ob NAT/öffentliche Adressen korrekt verarbeitet werden und untersuchen Sie erst dann clientseitige Netzwerkbeschränkungen. Die offizielle Jitsi-Anleitung zum Selbsthosting gibt UDP-Port 10000 als Standard-Medienpfad an, während Jicofo für die Auswahl einer Videobridge für jede Konferenz zuständig ist.

Was der Fehler üblicherweise bedeutet

Jitsi Meet besteht aus mehreren Komponenten. Die Weboberfläche und Prosody übernehmen die Signalisierung, Jicofo koordiniert die Konferenzen und Jitsi Videobridge leitet die Audio- und Videostreams weiter. Kann der Browser die Webseite erreichen, aber keine Medienverbindung mit JVB herstellen, oder steht Jicofo keine funktionierende Brücke zur Verfügung, kann das Meeting auf der Brückenebene fehlschlagen.

Für aktuelle Debian/Ubuntu-Installationen dokumentiert Jitsi folgende Netzwerkanforderungen: TCP 80 für Zertifikatsvalidierung und -erneuerung, TCP 443 für Webzugriff, UDP 10000 für allgemeine Audio-/Videoübertragung, UDP 3478 für optionale STUN-Abfragen und TCP 5349 für coturn-basierte Fallback-Medien, falls UDP blockiert ist. Siehe die offizielle Jitsi-Anleitung zum Selbsthosting unter Debian/Ubuntu . Die aktuelle Referenzkonfiguration von JVB zeigt ebenfalls UDP-Port 10000 als Standard-ICE/UDP-Port in der Jitsi Videobridge-Referenzkonfiguration an .

1. Stellen Sie sicher, dass Jitsi Videobridge ausgeführt wird.

Beginnen Sie mit der im Fehler genannten Komponente. Führen Sie bei einer standardmäßigen paketbasierten Installation Folgendes aus:

sudo systemctl status jitsi-videobridge2

Sie möchten Folgendes überprüfen active (running): Wenn das Gerät ausgefallen ist, kann ein Neustart den Dienst vorübergehend wiederherstellen, aber hören Sie dort nicht auf – überprüfen Sie die Protokolle, um die Ursache des Ausfalls zu erfahren:

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

Achten Sie auf Bindungsfehler, Authentifizierungsfehler, XMPP-Verbindungsfehler, wiederholte ICE-Probleme oder Meldungen, die darauf hinweisen, dass keine gültige Adresse verfügbar ist. Gehen Sie nicht davon aus, dass ein aktiver systemd-Status beweist, dass JVB nutzbar ist: Ein Java-Prozess kann laufen, während die Mediennetzwerk- oder XMPP-Registrierung unterbrochen ist.

2. Überprüfen Sie, ob UDP-Port 10000 aktiv ist und die Host-Firewall den Datenverkehr zulässt.

Der Standard-JVB-Medienport von Jitsi ist UDP 10000. Überprüfen Sie zunächst, ob der Server lauscht:

sudo ss -lunp | grep ':10000'

Wenn kein Dienst auf den Port lauscht, überprüfen Sie /etc/jitsi/videobridge/jvb.confdie JVB-Protokolle, bevor Sie die Firewall-Regeln ändern. Wenn der Port aktiv ist, überprüfen Sie die Host-Firewall.

sudo ufw status verbose

Auf einem Ubuntu-Server mit UFW verwendet Jitsis eigene Anleitung Folgendes:

sudo ufw allow 10000/udp
sudo ufw status verbose

Wenn Sie firewalld, nftables, iptables oder eine Cloud-Firewall anstelle von UFW verwenden, fügen Sie dort die entsprechende Regel für eingehende UDP-Verbindungen hinzu. Ein häufiger Fehler ist, UDP-Port 10000 in Ubuntu zu öffnen, ihn aber durch eine AWS-Sicherheitsgruppe, eine Azure-Netzwerksicherheitsgruppe, eine Google Cloud VPC-Firewall, eine Firewall Ihres VPS-Anbieters oder eine Hardware-Firewall des Upstream-Anbieters zu blockieren.

3. Überprüfen Sie die Portweiterleitung des Routers, wenn sich der Server hinter einem NAT-Router befindet.

Wenn Jitsi auf einer privaten IP-Adresse wie z. B. 80000 läuft 192.168.x.x, reicht das Öffnen von UFW nicht aus. Ihr Edge-Router muss den externen UDP-Medienport an den Rechner weiterleiten, auf dem JVB ausgeführt wird. Bei einer einfachen Einzelserverinstallation bedeutet dies üblicherweise, UDP 10000 an UDP 10000 auf dem Jitsi-Server weiterzuleiten.

Wenn Sie den Port von JVB geändert haben, verwenden Sie den konfigurierten Wert, anstatt einfach Port 10000 zu öffnen. Stellen Sie außerdem sicher, dass der Port nicht bereits von einem anderen Rechner oder Container belegt ist. Die Einstellungen für die Portweiterleitung unterscheiden sich je nach Router. Betrachten Sie die Abbildung daher als Konfigurationsbeispiel und nicht als exakte Benutzeroberfläche für Ihr Gerät.

4. Korrigieren Sie die Zuordnung von öffentlichen und privaten Adressen.

NAT kann einen subtileren Fehler verursachen: JVB kann Internetclients einen privaten Kandidaten ankündigen, obwohl der Router den korrekten Port weiterleitet. Die aktuelle Schnellstartdokumentation von Jitsi zeigt eine statische Zuordnung /etc/jitsi/videobridge/jvb.conffür Systeme, die eine explizite Übersetzung von lokalen zu öffentlichen Adressen benötigen:

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

Ersetzen Sie die Platzhalter durch die tatsächliche private Adresse des JVB-Hosts und die öffentliche Adresse, die von entfernten Clients erreicht werden kann. Starten Sie anschließend JVB neu.

sudo systemctl restart jitsi-videobridge2

Verwenden Sie diese Einstellung nur, wenn sie Ihrer Topologie entspricht. Server mit direkter öffentlicher Adressierung, Docker-Bereitstellungen, mehreren Netzwerkkarten, IPv6 oder komplexerem NAT benötigen möglicherweise andere Einstellungen. Ein maßgebliches Beispiel finden Sie im Abschnitt „Jitsi Quick-Start NAT“ .

5. Überprüfen Sie für Docker, ob der JVB-UDP-Port tatsächlich veröffentlicht ist.

In Docker hilft eine korrekte Firewall-Regel auf dem Host nicht, wenn der JVB-Container seinen Medienport nicht veröffentlicht. Die Docker-Dokumentation von Jitsi gibt JVB_PORTden Standardwert 10000 an und weist Administratoren an, UDP 10000 auf dem Host zu öffnen. Überprüfen Sie Ihre laufende Bereitstellung:

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

Überprüfen Sie anschließend Ihre Compose- und Umgebungsdateien und stellen Sie sicher, dass der JVB-Dienst den gewünschten UDP-Port freigibt. Falls Sie Änderungen vorgenommen haben JVB_PORT, müssen Host-Mapping, Firewall-Regel und NAT-Weiterleitung übereinstimmen. Verwenden Sie die offizielle Jitsi-Docker-Anleitung zum Selbsthosting, anstatt einen veralteten Compose-Codeausschnitt aus einem Tutorial eines Drittanbieters zu kopieren.

6. Bestätigen Sie, dass Jicofo eine Videobrücke erkennen kann.

Ein einwandfrei erreichbarer UDP-Port reicht nicht aus, wenn JVB sich nicht bei der XMPP-Steuerungsebene registriert. Jicofo wählt eine Videobrücke für eine Konferenz aus, und Jitsis Leitfaden für skalierbare Bereitstellungen empfiehlt, nach dem Neustart der Dienste sowohl die Prosody- als auch die Jicofo-Protokolle zu überprüfen, um sicherzustellen, dass die Brücken verbunden und erkannt werden.

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

Wenn Sie XMPP-Domänen angepasst oder mehrere Knoten betrieben haben, überprüfen Sie, ob Jicofo und JVB denselben Bridge-MUC („Brewery“) verwenden. Die offizielle Jitsi Videobridge MUC-Dokumentation besagt, dass Jicofo jicofo.bridge.brewery-jidauf denselben MUC verweisen muss, der von den Videobridge-Instanzen verwendet wird.

Dies ist besonders wichtig nach Hostnamenänderungen, Migrationen, Split-Host-Bereitstellungen oder manuellen Konfigurationsänderungen. Bei Standardpaketinstallationen mit dem offiziellen Installationsprogramm sollten Sie die XMPP-Konfiguration nicht überschreiben, es sei denn, Ihre Protokolle weisen tatsächlich auf ein Registrierungs- oder Authentifizierungsproblem hin.

7. Schließen Sie restriktive Client-Netzwerke, VPNs oder Proxys aus.

Wenn der Server für einige Benutzer funktioniert, für andere jedoch nicht, testen Sie ihn in einem anderen Netzwerk, bevor Sie die Serverkonfiguration ändern. Firmennetzwerke, Gast-WLANs, VPNs und strikte Proxys können UDP blockieren. Das vorübergehende Trennen einer VPN- oder Proxy-Verbindung ist ein hilfreicher Diagnosetest; stellen Sie die Verbindung anschließend wieder her, falls dies von Ihrer Organisation gefordert wird.

Die Jitsi-Anleitung für Debian/Ubuntu beschreibt TCP 5349 als Ausweichpfad für Audio/Video von coturn, wenn UDP blockiert ist. Falls Benutzer in restriktiven Netzwerken eine zuverlässige Verbindung benötigen, überprüfen Sie Ihre TURN/coturn-Konfiguration, anstatt anzunehmen, dass die Öffnung von TCP 443 für die Website automatisch einen Medienausweichpfad bereitstellt.

8. Versuchen Sie es erst dann mit einer neuen Browsersitzung, wenn die Serverprüfungen erfolgreich waren.

Eine veraltete Browsersitzung ist zwar unwahrscheinlicher als eine fehlerhafte JVB-Route, wenn alle Teilnehmer denselben Bridge-Fehler sehen, lässt sich aber schnell beheben. Laden Sie den Raum neu, versuchen Sie es mit einem privaten Browserfenster oder löschen Sie die Website-Daten Ihrer Jitsi-Domain und melden Sie sich erneut an, falls die Authentifizierung aktiviert ist.

Wenn der Fehler in verschiedenen Browsern und Netzwerken auftritt, sollten Sie die serverseitigen Prüfungen wieder aufnehmen, anstatt die Browserdaten wiederholt zu löschen.

So überprüfen Sie, ob die Reparatur tatsächlich funktioniert hat

Betrachten Sie das Problem nicht als gelöst, nur weil die Fehlermeldung verschwunden ist. Testen Sie den gesamten Medienpfad.

• Erstellen Sie einen neuen Raum und treten Sie von zwei Geräten aus bei.
• Verbinden Sie die Geräte nach Möglichkeit mit unterschiedlichen Netzwerken, z. B. eines mit dem Heim-Breitbandanschluss und eines mit mobilen Daten.
• Vergewissern Sie sich, dass Audio und Video mehrere Minuten lang in beide Richtungen übertragen werden.
• Beobachten Sie während des Beitritts die JVB- und Jicofo-Protokolle und vergewissern Sie sich, dass die Konferenz einer Bridge zugewiesen ist, ohne dass es zu wiederholten ICE- oder Bridge-Health-Fehlern kommt.
• Führen Sie den Vorgang erneut aus sudo ss -lunp | grep ':10000'und überprüfen Sie den Status Ihrer Firewall nach jedem Neustart oder jeder Änderung der Firewall.

Bei Installationen mit mehreren Brücken sollten Sie mehrere Konferenzen testen. Die skalierbare Einrichtungsanleitung von Jitsi erklärt, dass Jicofo für neue Konferenzen eine Videobrücke auswählt. Daher kann eine fehlerhafte Brücke zu zeitweiligen Ausfällen führen, selbst wenn eine andere Brücke funktioniert.

Schnelldiagnosetabelle

Fazit

Bei einem selbstgehosteten Jitsi Meet-Server sollte die Fehlermeldung „Verbindung zur Bridge fehlgeschlagen“ zunächst als Problem mit dem Medienpfad oder der Bridge-Registrierung behandelt werden. Stellen Sie sicher, dass Jitsi Videobridge fehlerfrei funktioniert, UDP 10000 erreichbar ist und alle Firewall-/NAT-Schichten durchlaufen kann, JVB eine nutzbare öffentliche Adresse bereitstellt (falls NAT im Spiel ist) und Jicofo die Bridge erkennt. Erst nach diesen Prüfungen sollten Sie sich mit dem Browser-Cache oder den Client-Einstellungen befassen.

Die genaue Lösung hängt von Ihrer Systemarchitektur ab. Verwenden Sie daher keine alten Jitsi-Konfigurationsschlüssel, nur weil sie in älteren Forenbeiträgen auftauchen. Die oben genannten Befehle und Einstellungen entsprechen dem aktuellen offiziellen Jitsi-Handbuch und den aktuellen Jitsi-Videobridge-Konfigurationsquellen (Stand: Oktober 2026).