Jak naprawić błąd Jitsi Meet „Nie udało się połączyć z mostem”

Otwierasz pokój Jitsi Meet, strona ładuje się normalnie, a sygnalizacja może nawet działać – ale konferencja nigdy nie nawiązuje połączenia. Zamiast tego Jitsi zgłasza błąd „Nie udało się połączyć z mostem” lub wielokrotnie rozłącza się podczas dołączania. W przypadku wdrożenia hostowanego samodzielnie ten komunikat zazwyczaj wskazuje na problem między przeglądarką a Jitsi Videobridge (JVB) lub między Jicofo a samym mostem.

Najszybszym sposobem rozwiązania problemu jest rozpoczęcie pracy od serwera: sprawdzenie, czy JVB działa i jest zarejestrowany, sprawdzenie dostępności portu multimediów, sprawdzenie obsługi NAT/adresów publicznych i dopiero wtedy sprawdzenie ograniczeń sieciowych po stronie klienta. Oficjalny poradnik samodzielnego hostingu Jitsi podaje port UDP 10000 jako domyślną ścieżkę multimediów, natomiast Jicofo odpowiada za wybór Videobridge dla każdej konferencji.

Co zazwyczaj oznacza błąd

Jitsi Meet składa się z kilku komponentów. Interfejs internetowy i Prosody obsługują sygnalizację, Jicofo koordynuje konferencje, a Jitsi Videobridge przekazuje strumienie audio i wideo. Jeśli przeglądarka może połączyć się ze stroną internetową, ale nie może nawiązać połączenia z JVB, lub jeśli Jicofo nie ma sprawnego mostu, spotkanie może zakończyć się niepowodzeniem na etapie mostu.

W przypadku obecnych instalacji Debian/Ubuntu, Jitsi dokumentuje następujące wymagania sieciowe: TCP 80 do walidacji i odnawiania certyfikatów, TCP 443 do dostępu do sieci, UDP 10000 do ogólnych połączeń audio/wideo, UDP 3478 do opcjonalnych zapytań STUN oraz TCP 5349 do zapasowego nośnika danych opartego na coturn, gdy UDP jest zablokowane. Zobacz oficjalny podręcznik samodzielnego hostingu Jitsi w systemie Debian/Ubuntu . Aktualna konfiguracja referencyjna JVB również wskazuje port UDP 10000 jako domyślny port ICE/UDP w konfiguracji referencyjnej Jitsi Videobridge .

1. Sprawdź, czy Jitsi Videobridge działa

Zacznij od komponentu wskazanego w błędzie. W przypadku standardowej instalacji opartej na pakiecie uruchom:

sudo systemctl status jitsi-videobridge2

Chcesz zobaczyć active (running). Jeśli urządzenie uległo awarii, jego ponowne uruchomienie może tymczasowo przywrócić działanie, ale nie zatrzymuj się na tym — sprawdź logi, aby dowiedzieć się, dlaczego przestało działać:

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

Szukaj błędów powiązań, błędów uwierzytelniania, błędów połączenia XMPP, powtarzających się problemów z ICE lub komunikatów wskazujących na brak dostępnego prawidłowego adresu. Nie zakładaj, że aktywny status systemd dowodzi użyteczności JVB: proces Java może być uruchomiony, podczas gdy sieć multimedialna lub rejestracja XMPP są uszkodzone.

2. Sprawdź, czy protokół UDP 10000 nasłuchuje i jest dozwolony przez zaporę hosta

Domyślny port multimedialny JVB Jitsi to UDP 10000. Najpierw sprawdź, czy serwer nasłuchuje:

sudo ss -lunp | grep ':10000'

Jeśli nic nie nasłuchuje, sprawdź /etc/jitsi/videobridge/jvb.conflogi JVB przed zmianą reguł zapory. Jeśli port nasłuchuje, sprawdź zaporę hosta:

sudo ufw status verbose

Na serwerze Ubuntu wykorzystującym UFW, przewodnik Jitsiego zawiera:

sudo ufw allow 10000/udp
sudo ufw status verbose

Jeśli używasz firewalld, nftables, iptables lub zapory chmurowej zamiast UFW, dodaj tam odpowiednią regułę przychodzącą UDP. Częstym błędem jest otwieranie UDP 10000 w Ubuntu, ale pozostawianie go zablokowanego przez grupę zabezpieczeń AWS, grupę zabezpieczeń sieci Azure, zaporę Google Cloud VPC, zaporę dostawcy VPS lub sprzętową zaporę nadrzędną.

3. Sprawdź przekierowanie portów routera, gdy serwer znajduje się za NAT-em

Jeśli Jitsi działa na prywatnym adresie, takim jak 192.168.x.x, otwarcie UFW nie wystarczy. Router brzegowy musi przekierować zewnętrzny port multimedialny UDP do komputera z uruchomionym JVB. W prostej instalacji jednoserwerowej zazwyczaj oznacza to przekierowanie UDP 10000 do UDP 10000 na serwerze Jitsi.

Jeśli zmieniłeś port JVB, użyj skonfigurowanej wartości, zamiast bezmyślnie otwierać 10000. Sprawdź również, czy inny komputer lub kontener nie zajął tego portu. Ekrany przekierowania portów różnią się w zależności od routera, dlatego traktuj ilustrację jako przykład konfiguracji, a nie dokładną mapę interfejsu użytkownika dla swojego urządzenia.

4. Napraw mapowanie adresów publicznych i prywatnych

NAT może powodować subtelniejsze awarie: JVB może reklamować prywatnego kandydata klientom internetowym, mimo że router przekierowuje prawidłowy port. Aktualna dokumentacja szybkiego startu Jitsi przedstawia statyczne mapowanie dla /etc/jitsi/videobridge/jvb.confsystemów wymagających jawnej translacji adresów lokalnych na publiczne:

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

Zastąp symbole zastępcze rzeczywistym prywatnym adresem hosta JVB i adresem publicznym, do którego mogą dotrzeć klienci zdalni. Następnie uruchom ponownie JVB:

sudo systemctl restart jitsi-videobridge2

Używaj tego tylko wtedy, gdy pasuje do Twojej topologii. Serwery z bezpośrednim adresowaniem publicznym, wdrożeniami Dockera, wieloma kartami sieciowymi, IPv6 lub bardziej złożonym NAT mogą wymagać innych ustawień. Autorytatywny przykład znajduje się w sekcji szybkiego startu NAT w Jitsi .

5. W przypadku Dockera sprawdź, czy port UDP JVB jest rzeczywiście opublikowany

W Dockerze poprawna reguła zapory sieciowej na hoście nie pomoże, jeśli kontener JVB nie publikuje swojego portu multimediów. Dokumentacja Dockera Jitsi podaje JVB_PORTwartość domyślną 10000 i instruuje administratorów, aby otworzyli port UDP 10000 na hoście. Sprawdź swoje działające wdrożenie:

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

Następnie sprawdź pliki Compose i środowiskowe i upewnij się, że usługa JVB udostępnia zamierzony port UDP. Jeśli zmieniłeś JVB_PORT, mapowanie hosta, reguła zapory sieciowej i przekierowanie NAT muszą być zgodne. Zapoznaj się z oficjalnym poradnikiem samodzielnego hostingu Jitsi Docker zamiast kopiować stary fragment kodu Compose z zewnętrznego samouczka.

6. Sprawdź, czy Jicofo widzi Videobridge

Idealnie dostępny port UDP nie wystarczy, jeśli JVB nigdy nie zarejestruje się na płaszczyźnie sterowania XMPP. Jicofo wybiera Videobridge do konferencji, a poradnik skalowalnego wdrażania Jitsi zaleca sprawdzenie logów Prosody i Jicofo po ponownym uruchomieniu usług, aby upewnić się, że mosty łączą się i są odbierane.

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

Jeśli dostosowałeś domeny XMPP lub uruchomiłeś wiele węzłów, sprawdź, czy Jicofo i JVB używają tego samego mostu MUC „brewery”. Oficjalna dokumentacja Jitsi Videobridge MUC stwierdza, że ​​Jicofo jicofo.bridge.brewery-jidmusi wskazywać na ten sam MUC używany przez instancje Videobridge.

Jest to szczególnie ważne po zmianie nazwy hosta, migracjach, wdrożeniach z podziałem hosta lub ręcznych edycjach konfiguracji. W przypadku standardowych instalacji pakietów utworzonych za pomocą oficjalnego instalatora należy unikać przepisywania konfiguracji XMPP, chyba że logi faktycznie wskazują na problem z rejestracją lub uwierzytelnianiem.

7. Wyklucz restrykcyjną sieć klienta, VPN lub serwer proxy

Jeśli serwer działa u niektórych użytkowników, ale nie u innych, przed zmianą konfiguracji serwera przetestuj go w innej sieci. Sieci korporacyjne, sieci Wi-Fi dla gości, sieci VPN i serwery proxy obsługujące ścisłe protokoły mogą blokować protokół UDP. Tymczasowe rozłączenie sieci VPN lub serwera proxy to przydatny test diagnostyczny; podłącz go ponownie, jeśli będzie to wymagane w Twojej organizacji.

Przewodnik Jitsi po Debianie/Ubuntu dokumentuje protokół TCP 5349 jako ścieżkę zapasową coturn dla audio/wideo, gdy UDP jest zablokowane. Jeśli chcesz, aby użytkownicy w sieciach z ograniczeniami mieli niezawodne połączenie, zweryfikuj konfigurację TURN/coturn, zamiast zakładać, że otwarcie TCP 443 dla strony internetowej automatycznie zapewnia ścieżkę zapasową dla multimediów.

8. Spróbuj ponownie z czystą sesją przeglądarki dopiero po sprawdzeniu poprawności działania serwera

Nieaktualna sesja przeglądarki jest mniej prawdopodobna niż uszkodzona trasa JVB, gdy wszyscy uczestnicy widzą ten sam błąd mostu, ale można go szybko wyeliminować. Odśwież pokój, spróbuj otworzyć okno przeglądarki prywatnej lub wyczyść dane witryny dla swojej domeny Jitsi i zaloguj się ponownie, jeśli uwierzytelnianie jest włączone.

Jeśli błąd powtarza się w różnych przeglądarkach i sieciach, powróć do sprawdzeń po stronie serwera, zamiast ciągle czyścić dane przeglądarki.

Jak sprawdzić, czy poprawka faktycznie zadziałała

Nie uważaj problemu za rozwiązany tylko dlatego, że zniknęło okienko z błędem. Przetestuj całą ścieżkę multimediów.

• Utwórz nowy pokój i dołącz do niego z dwóch urządzeń.
• Jeśli to możliwe, podłącz urządzenia do różnych sieci, np. jedno do łącza szerokopasmowego, a drugie do sieci komórkowej.
• Sprawdź, czy dźwięk i obraz płyną w obu kierunkach przez kilka minut.
• Podczas dołączania śledź logi JVB i Jicofo i sprawdź, czy konferencja jest przypisana do mostu bez powtarzających się awarii ICE lub stanu mostu.
• Po każdym ponownym uruchomieniu lub zmianie zapory należy ją ponownie uruchomić sudo ss -lunp | grep ':10000'i sprawdzić jej stan.

W przypadku instalacji wielomostowych należy przetestować więcej niż jedną konferencję. Skalowalny przewodnik konfiguracji Jitsi wyjaśnia, że ​​Jicofo wybiera Videobridge dla nowych konferencji, więc jeden niesprawny most może powodować sporadyczne awarie, nawet gdy inny most działa.

Szybka tabela diagnostyczna

Podsumowanie

W przypadku serwera Jitsi Meet hostowanego samodzielnie, komunikat „Nie udało się połączyć z mostem” najlepiej najpierw potraktować jako problem ze ścieżką multimediów lub rejestracją mostu. Sprawdź, czy Jitsi Videobridge działa prawidłowo, czy UDP 10000 nasłuchuje i jest dostępny przez każdą warstwę zapory sieciowej/NAT, czy JVB ogłasza użyteczny adres publiczny w przypadku NAT oraz czy Jicofo widzi most. Dopiero po tych sprawdzeniach powinieneś poświęcić czas na sprawdzenie pamięci podręcznej przeglądarki lub indywidualnych ustawień klienta.

Dokładne rozwiązanie zależy od topologii, dlatego unikaj stosowania starych kluczy konfiguracyjnych Jitsi tylko dlatego, że pojawiają się w historycznych postach na forum. Powyższe polecenia i ustawienia są zgodne z aktualnym oficjalnym podręcznikiem Jitsi i aktualnymi źródłami konfiguracji Jitsi Videobridge, sprawdzonymi w październiku 2026 roku.