Cum să remediați eroarea „Conectarea la Bridge nu a reușit” din Jitsi Meet

Deschizi o cameră Jitsi Meet, pagina se încarcă normal și semnalizarea poate părea chiar să funcționeze, dar conferința nu stabilește niciodată conținut media. În schimb, Jitsi raportează „Conectarea la bridge nu a reușit” sau se deconectează în mod repetat în timpul conectării. Într-o implementare auto-găzduită, acest mesaj indică de obicei o problemă între browser și Jitsi Videobridge (JVB) sau între Jicofo și bridge-ul în sine.

Cea mai rapidă metodă de depanare este să lucrați de la server către exterior: confirmați că JVB rulează și este înregistrat, confirmați că portul său media este accesibil, verificați gestionarea NAT/adreselor publice și abia apoi investigați restricțiile de rețea pe partea clientului. Ghidul oficial de auto-găzduire Jitsi listează portul UDP 10000 ca fiind calea media implicită, în timp ce Jicofo este responsabil pentru selectarea unui Videobridge pentru fiecare conferință.

Ce înseamnă de obicei eroarea

Jitsi Meet are mai multe componente. Interfața web și Prosody gestionează semnalizarea, Jicofo coordonează conferințele, iar Jitsi Videobridge redirecționează fluxurile audio și video. Dacă browserul poate accesa pagina web, dar nu poate stabili conținut media cu JVB sau dacă Jicofo nu are o punte disponibilă, întâlnirea poate eșua în etapa de punte.

Pentru instalările actuale de Debian/Ubuntu, Jitsi documentează aceste cerințe de rețea: TCP 80 pentru validarea și reînnoirea certificatelor, TCP 443 pentru acces web, UDP 10000 pentru audio/video general, UDP 3478 pentru interogări STUN opționale și TCP 5349 pentru medii de rezervă bazate pe coturn atunci când UDP este blocat. Consultați ghidul oficial de auto-găzduire Jitsi Debian/Ubuntu . Configurația de referință actuală a JVB arată, de asemenea, portul UDP 10000 ca port ICE/UDP implicit în configurația de referință Jitsi Videobridge .

1. Confirmați că Jitsi Videobridge rulează

Începeți cu componenta numită în eroare. Într-o instalare standard bazată pe pachete, executați:

sudo systemctl status jitsi-videobridge2

Vrei să vezi active (running). Dacă unitatea se defectează, repornirea acesteia poate restabili temporar serviciul, dar nu te opri aici - verifică jurnalele pentru a afla de ce s-a oprit:

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

Căutați erori de legare, erori de autentificare, erori de conexiune XMPP, probleme ICE repetate sau mesaje care indică faptul că nu este disponibilă nicio adresă validă. Nu presupuneți că o stare systemd activă dovedește că JVB este utilizabil: un proces Java poate rula în timp ce rețeaua media sau înregistrarea XMPP este întreruptă.

2. Verificați dacă UDP 10000 ascultă și are permisiuni prin firewall-ul gazdă

Portul media JVB implicit al Jitsi este UDP 10000. Mai întâi confirmați că serverul ascultă:

sudo ss -lunp | grep ':10000'

Dacă nimic nu ascultă, verificați /etc/jitsi/videobridge/jvb.confjurnalele JVB înainte de a modifica regulile firewall-ului. Dacă portul ascultă, verificați firewall-ul gazdă:

sudo ufw status verbose

Pe un server Ubuntu care folosește UFW, ghidul propriu al lui Jitsi folosește:

sudo ufw allow 10000/udp
sudo ufw status verbose

Dacă utilizați firewalld, nftables, iptables sau un firewall în cloud în loc de UFW, adăugați regula UDP echivalentă de intrare acolo. O greșeală frecventă este deschiderea UDP 10000 în Ubuntu, dar lăsarea lui blocată de un grup de securitate AWS, un grup de securitate de rețea Azure, un firewall Google Cloud VPC, un firewall al furnizorului VPS sau un firewall hardware upstream.

3. Verificați redirecționarea porturilor routerului atunci când serverul este în spatele NAT

Dacă Jitsi rulează pe o adresă privată, cum ar fi 192.168.x.x, deschiderea UFW nu este suficientă. Routerul dvs. de margine trebuie să redirecționeze portul media UDP extern către mașina care rulează JVB. Într-o instalare simplă pe un singur server, aceasta înseamnă de obicei redirecționarea UDP 10000 către UDP 10000 pe serverul Jitsi.

Dacă ați modificat portul JVB, utilizați valoarea configurată în loc să deschideți orbește portul 10000. De asemenea, verificați dacă o altă mașină sau un container nu a preluat portul. Ecranele de redirecționare a porturilor diferă în funcție de router, așa că tratați ilustrația ca un exemplu de configurare, mai degrabă decât ca o hartă exactă a interfeței utilizator pentru dispozitivul dvs.

4. Remediați maparea adreselor publice/private

NAT poate cauza o eroare mai subtilă: JVB poate promova un candidat privat clienților de internet chiar dacă routerul redirecționează portul corect. Documentația actuală de pornire rapidă a Jitsi prezintă o mapare statică pentru /etc/jitsi/videobridge/jvb.confsistemele care necesită o traducere explicită a adreselor locale-publice:

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

Înlocuiți substituenții cu adresa privată reală a gazdei JVB și adresa publică pe care o pot accesa clienții la distanță. Apoi reporniți JVB:

sudo systemctl restart jitsi-videobridge2

Folosește această opțiune doar atunci când se potrivește cu topologia ta. Serverele cu adresare publică directă, implementări Docker, mai multe NIC-uri, IPv6 sau NAT mai complex pot necesita setări diferite. Exemplul autorizat se află în secțiunea NAT de pornire rapidă Jitsi .

5. Pentru Docker, verificați dacă portul JVB UDP este de fapt publicat.

În Docker, o regulă corectă de firewall pe gazdă nu ajută dacă containerul JVB nu își publică portul media. Documentația Docker a Jitsi listează JVB_PORTcu o valoare implicită de 10000 și instruiește administratorii să deschidă UDP 10000 pe gazdă. Verificați implementarea care rulează:

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

Apoi, inspectați fișierele Compose și de mediu și confirmați că serviciul JVB expune portul UDP dorit. Dacă ați modificat JVB_PORT, maparea gazdei, regula firewall și orice redirecționare NAT trebuie să fie toate conforme. Consultați ghidul oficial de auto-găzduire Jitsi Docker în loc să copiați un fragment vechi de fișier Compose dintr-un tutorial terț.

6. Confirmați că Jicofo poate vedea un Videobridge

Un port UDP perfect accesibil nu este suficient dacă JVB nu se înregistrează niciodată cu planul de control XMPP. Jicofo selectează un Videobridge pentru o conferință, iar ghidul de implementare scalabilă Jitsi recomandă verificarea jurnalelor Prosody și Jicofo după repornirea serviciilor pentru a confirma că bridge-urile se conectează și sunt preluate.

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

Dacă ați personalizat domenii XMPP sau ați rulat mai multe noduri, verificați dacă Jicofo și JVB utilizează același MUC „brewery” al bridge-ului. Documentația oficială Jitsi Videobridge MUC precizează că Jicofo jicofo.bridge.brewery-jidtrebuie să indice către același MUC utilizat de instanțele Videobridge.

Acest lucru este important în special după modificări ale numelui de gazdă, migrări, implementări split-host sau modificări manuale ale configurației. Pentru instalările standard de pachete create cu programul de instalare oficial, evitați rescrierea configurației XMPP, cu excepția cazului în care jurnalele dvs. indică o problemă de înregistrare sau autentificare.

7. Excludeți o rețea client restrictivă, un VPN sau un proxy

Dacă serverul funcționează pentru unii utilizatori, dar nu pentru alții, testați dintr-o altă rețea înainte de a modifica configurația serverului. Rețelele corporative, Wi-Fi-ul pentru oaspeți, VPN-urile și proxy-urile stricte pot bloca UDP. Deconectarea temporară a unui VPN sau a unui proxy este un test de diagnosticare util; reconectați-l ulterior dacă organizația dvs. o solicită.

Ghidul Debian/Ubuntu al Jitsi documentează TCP 5349 ca o cale de rezervă coturn pentru audio/video atunci când UDP este blocat. Dacă aveți nevoie ca utilizatorii din rețele restrictive să se conecteze în mod fiabil, verificați configurația TURN/coturn în loc să presupuneți că deschiderea TCP 443 pentru site-ul web oferă automat o cale de rezervă media.

8. Reîncercați cu o sesiune curată de browser numai după ce verificările serverului au trecut cu succes

O sesiune de browser învechită este mai puțin probabilă decât o rută JVB defectă atunci când fiecare participant vede aceeași eroare de bridge, dar este rapid de eliminat. Reîncărcați camera, încercați o fereastră de navigare privată sau ștergeți datele site-ului pentru domeniul dvs. Jitsi și conectați-vă din nou dacă autentificarea este activată.

Dacă eroarea se reproduce în diferite browsere și rețele, reveniți la verificările pe server în loc să ștergeți în mod repetat datele browserului.

Cum să verifici dacă remedierea a funcționat efectiv

Nu considerați problema rezolvată doar pentru că fereastra de eroare a dispărut. Testați întreaga cale media.

• Creează o cameră nouă și alătură-te de pe două dispozitive.
• Puneți dispozitivele în rețele diferite, dacă este posibil, cum ar fi unul pe bandă largă acasă și unul pe date mobile.
• Confirmați că atât sunetul, cât și imaginea video sunt transmise în ambele direcții timp de câteva minute.
• Urmăriți jurnalele JVB și Jicofo în timpul conectării și verificați dacă conferința este atribuită unei punți fără erori repetate de ICE sau de funcționare a punții.
• Reporniți sudo ss -lunp | grep ':10000'și verificați starea firewall-ului după orice repornire sau modificare a firewall-ului.

Pentru instalările cu mai multe punți (bridge), testați mai multe conferințe. Ghidul de configurare scalabilă Jitsi explică faptul că Jicofo selectează un Videobridge pentru conferințe noi, astfel încât un bridge nefuncțional poate produce defecțiuni intermitente chiar și atunci când un alt bridge funcționează.

Tabel de diagnosticare rapidă

Concluzie

Pentru un server Jitsi Meet auto-găzduit, cel mai bine este să tratați eroarea „Conectare la bridge eșuată” ca o problemă de cale media sau de înregistrare a bridge-ului. Verificați dacă Jitsi Videobridge este funcțional, dacă UDP 10000 ascultă și este accesibil prin fiecare strat firewall/NAT, dacă JVB anunță o adresă publică utilizabilă atunci când este implicat NAT și dacă Jicofo vede bridge-ul. Numai după aceste verificări ar trebui să acordați timp setărilor cache ale browserului sau ale setărilor individuale ale clienților.

Soluția exactă depinde de topologia dvs., așa că evitați să aplicați vechile chei de configurare Jitsi doar pentru că apar în postările anterioare de pe forum. Comenzile și setările de mai sus sunt aliniate cu Manualul oficial Jitsi actual și cu sursele de configurare Jitsi Videobridge actuale verificate în octombrie 2026.