Come risolvere l'errore "Impossibile connettersi al bridge" di Jitsi Meet

Quando si apre una stanza Jitsi Meet, la pagina si carica normalmente e la segnalazione potrebbe anche sembrare funzionare, ma la conferenza non riesce a stabilire la connessione multimediale. Invece, Jitsi segnala "Impossibile connettersi al bridge" o si disconnette ripetutamente durante il tentativo di connessione. In un'installazione self-hosted, questo messaggio di solito indica un problema tra il browser e Jitsi Videobridge (JVB) o tra Jicofo e il bridge stesso.

Il modo più rapido per risolvere il problema è procedere dal server verso l'esterno: verificare che JVB sia in esecuzione e registrato, accertarsi che la sua porta multimediale sia raggiungibile, verificare la gestione del NAT/indirizzo pubblico e solo successivamente esaminare le restrizioni di rete lato client. La guida ufficiale di Jitsi per l'hosting autonomo indica la porta UDP 10000 come percorso multimediale predefinito, mentre Jicofo è responsabile della selezione di un Videobridge per ogni conferenza.

Cosa significa solitamente l'errore

Jitsi Meet è composto da diversi elementi. L'interfaccia web e Prosody gestiscono la segnalazione, Jicofo coordina le conferenze e Jitsi Videobridge inoltra i flussi audio e video. Se il browser riesce a raggiungere la pagina web ma non riesce a stabilire una connessione multimediale con JVB, o se Jicofo non dispone di un bridge funzionante, la riunione potrebbe fallire nella fase di bridge.

Per le attuali installazioni Debian/Ubuntu, Jitsi documenta i seguenti requisiti di rete: TCP 80 per la convalida e il rinnovo dei certificati, TCP 443 per l'accesso web, UDP 10000 per audio/video generici, UDP 3478 per query STUN opzionali e TCP 5349 per i media di fallback basati su coturn quando UDP è bloccato. Consultare la guida ufficiale di Jitsi per l'hosting autonomo su Debian/Ubuntu . La configurazione di riferimento corrente di JVB mostra anche la porta UDP 10000 come porta ICE/UDP predefinita nella configurazione di riferimento di Jitsi Videobridge .

1. Verificare che Jitsi Videobridge sia in esecuzione

Inizia con il componente indicato nell'errore. In un'installazione standard basata su pacchetti, esegui:

sudo systemctl status jitsi-videobridge2

Vuoi vedere active (running). Se l'unità è guasta, riavviarla potrebbe ripristinare temporaneamente il servizio, ma non fermarti qui: controlla i registri per capire perché si è arrestata:

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

Verifica la presenza di errori di binding, errori di autenticazione, errori di connessione XMPP, problemi ICE ripetuti o messaggi che indicano l'assenza di un indirizzo valido. Non dare per scontato che uno stato systemd attivo dimostri che JVB sia utilizzabile: un processo Java può essere in esecuzione anche se la rete multimediale o la registrazione XMPP sono interrotte.

2. Verificare che la porta UDP 10000 sia in ascolto e che il suo traffico sia consentito dal firewall dell'host.

La porta multimediale JVB predefinita di Jitsi è UDP 10000. Innanzitutto, verifica che il server sia in ascolto:

sudo ss -lunp | grep ':10000'

Se nessun dispositivo è in ascolto, controlla /etc/jitsi/videobridge/jvb.confi log di JVB prima di modificare le regole del firewall. Se la porta è in ascolto, controlla il firewall dell'host:

sudo ufw status verbose

Su un server Ubuntu che utilizza UFW, la guida di Jitsi utilizza:

sudo ufw allow 10000/udp
sudo ufw status verbose

Se utilizzi firewalld, nftables, iptables o un firewall cloud al posto di UFW, aggiungi la regola UDP in entrata equivalente. Un errore comune è quello di aprire la porta UDP 10000 in Ubuntu ma lasciarla bloccata da un gruppo di sicurezza AWS, un gruppo di sicurezza di rete Azure, il firewall di Google Cloud VPC, il firewall del provider VPS o il firewall hardware a monte.

3. Verificare l'inoltro delle porte del router quando il server si trova dietro un NAT.

Se Jitsi è in esecuzione su un indirizzo privato come 192.168.x.x, aprire UFW non è sufficiente. Il router di bordo deve inoltrare la porta multimediale UDP esterna alla macchina su cui è in esecuzione JVB. In una semplice installazione a server singolo, ciò significa solitamente inoltrare la porta UDP 10000 alla porta UDP 10000 sul server Jitsi.

Se hai modificato la porta di JVB, utilizza il valore configurato anziché aprire ciecamente la porta 10000. Verifica inoltre che un'altra macchina o un altro container non stia già utilizzando la porta. Le schermate di port forwarding variano a seconda del router, quindi considera l'illustrazione come un esempio di configurazione e non come una mappa esatta dell'interfaccia utente del tuo dispositivo.

4. Correggere la mappatura degli indirizzi pubblici/privati

Il NAT può causare un errore più subdolo: JVB potrebbe pubblicizzare un candidato privato ai client Internet anche se il router inoltra la porta corretta. La documentazione di avvio rapido di Jitsi mostra una mappatura statica per /etc/jitsi/videobridge/jvb.confi sistemi che necessitano di una traduzione esplicita degli indirizzi locali in indirizzi pubblici:

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

Sostituisci i segnaposto con l'indirizzo privato effettivo dell'host JVB e con l'indirizzo pubblico raggiungibile dai client remoti. Quindi riavvia JVB:

sudo systemctl restart jitsi-videobridge2

Utilizzate questa impostazione solo se corrisponde alla vostra topologia. Server con indirizzamento pubblico diretto, implementazioni Docker, più schede di rete, IPv6 o NAT più complesso potrebbero richiedere impostazioni diverse. L'esempio più completo si trova nella sezione NAT della guida rapida di Jitsi .

5. Per Docker, verificare che la porta JVB UDP sia effettivamente pubblicata.

In Docker, una regola firewall corretta sull'host non è sufficiente se il container JVB non pubblica la sua porta multimediale. La documentazione Docker di Jitsi indica JVB_PORTun valore predefinito di 10000 e raccomanda agli amministratori di aprire la porta UDP 10000 sull'host. Verifica la tua implementazione in esecuzione:

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

Controlla quindi i file Compose e di ambiente e verifica che il servizio JVB esponga la porta UDP prevista. Se hai apportato modifiche JVB_PORT, il mapping degli host, la regola del firewall e qualsiasi inoltro NAT devono essere tutti coerenti. Fai riferimento alla guida ufficiale di Jitsi per l'hosting Docker autonomo anziché copiare un vecchio snippet di Compose da un tutorial di terze parti.

6. Verificare che Jicofo possa visualizzare un Videobridge

Una porta UDP perfettamente raggiungibile non è sufficiente se JVB non si registra mai con il piano di controllo XMPP. Jicofo seleziona un Videobridge per una conferenza e la guida alla distribuzione scalabile di Jitsi raccomanda di controllare i log di Prosody e Jicofo dopo aver riavviato i servizi per confermare che i bridge si connettano e vengano rilevati.

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

Se hai personalizzato i domini XMPP o esegui più nodi, verifica che Jicofo e JVB utilizzino lo stesso MUC "brewery" del bridge. La documentazione ufficiale del MUC di Jitsi Videobridge afferma che Jicofo jicofo.bridge.brewery-jiddeve puntare allo stesso MUC utilizzato dalle istanze di Videobridge.

Ciò è particolarmente importante dopo modifiche al nome host, migrazioni, implementazioni su host separati o modifiche manuali alla configurazione. Per le installazioni di pacchetti standard create con il programma di installazione ufficiale, evitare di riscrivere la configurazione XMPP a meno che i log non indichino effettivamente un problema di registrazione o autenticazione.

7. Escludere una rete client restrittiva, una VPN o un proxy

Se il server funziona per alcuni utenti ma non per altri, prima di modificare la configurazione del server, esegui un test da una rete diversa. Le reti aziendali, le reti Wi-Fi per gli ospiti, le VPN e i proxy restrittivi potrebbero bloccare il protocollo UDP. Disconnettere temporaneamente una VPN o un proxy è un utile test diagnostico; ricollegali in seguito se richiesto dalla tua organizzazione.

La guida di Jitsi per Debian/Ubuntu documenta la porta TCP 5349 come percorso di fallback coturn per audio/video quando UDP è bloccato. Se hai bisogno che gli utenti su reti con restrizioni si connettano in modo affidabile, verifica la configurazione di TURN/coturn anziché presumere che l'apertura della porta TCP 443 per il sito web fornisca automaticamente un fallback multimediale.

8. Riprova con una sessione del browser pulita solo dopo che i controlli del server sono andati a buon fine

Un errore di connessione non funzionante è meno probabile di un problema con il percorso JVB quando tutti i partecipanti visualizzano lo stesso errore di connessione, ma è comunque facile da eliminare. Ricarica la stanza, prova una finestra di navigazione in incognito oppure cancella i dati del sito per il tuo dominio Jitsi e accedi di nuovo se l'autenticazione è abilitata.

Se l'errore si ripresenta su browser e reti diversi, è preferibile tornare ai controlli lato server piuttosto che cancellare ripetutamente i dati del browser.

Come verificare che la soluzione abbia effettivamente funzionato

Non considerate il problema risolto solo perché il messaggio di errore è scomparso. Verificate l'intero percorso del file multimediale.

• Crea una nuova stanza e unisciti da due dispositivi.
• Se possibile, collega i dispositivi a reti diverse, ad esempio uno alla connessione a banda larga domestica e l'altro alla rete dati mobile.
• Verificate che il flusso audio e video avvenga in entrambe le direzioni per diversi minuti.
• Monitora i log di JVB e Jicofo durante la connessione e verifica che la conferenza sia assegnata a un bridge senza errori ICE ripetuti o problemi di integrità del bridge.
• Esegui nuovamente sudo ss -lunp | grep ':10000'il controllo dello stato del firewall dopo ogni riavvio o modifica del firewall.

Per le installazioni multi-bridge, testare più di una conferenza. La guida alla configurazione scalabile di Jitsi spiega che Jicofo seleziona un Videobridge per le nuove conferenze, quindi un bridge non funzionante può causare guasti intermittenti anche quando un altro bridge funziona correttamente.

Tabella di diagnosi rapida

In conclusione

Per un server Jitsi Meet self-hosted, l'errore "Impossibile connettersi al bridge" va inizialmente considerato come un problema di percorso multimediale o di registrazione del bridge. Verificate che Jitsi Videobridge funzioni correttamente, che la porta UDP 10000 sia in ascolto e raggiungibile attraverso ogni livello del firewall/NAT, che JVB pubblicizzi un indirizzo pubblico utilizzabile in caso di NAT e che Jicofo rilevi il bridge. Solo dopo aver effettuato queste verifiche, dedicatevi alla cache del browser o alle impostazioni dei singoli client.

La soluzione esatta dipende dalla topologia in uso, quindi evitate di applicare vecchie chiavi di configurazione di Jitsi solo perché compaiono in vecchi post del forum. I comandi e le impostazioni sopra riportati sono conformi al manuale ufficiale di Jitsi e alle fonti di configurazione di Jitsi Videobridge aggiornate a ottobre 2026.