Una chiamata Jitsi Meet può mostrare il messaggio "Sei stato disconnesso" quando la connessione di segnalazione della riunione si interrompe, quando il traffico multimediale WebRTC non riesce a raggiungere il bridge video o quando una rete locale o un browser interrompono la sessione. Inizia verificando se il problema riguarda un solo partecipante o tutti. Questa distinzione di solito ti permette di capire se il problema riguarda il dispositivo e la rete o il server Jitsi.
| Ciò che osservi | Prima verifica | Area probabile da investigare |
|---|---|---|
| Solo una persona si disconnette | Riconnettiti da un'altra rete o dispositivo | Wi-Fi del partecipante, VPN, browser, app o firewall locale |
| Diverse persone si disconnettono contemporaneamente | Chiedi se utilizzano lo stesso host Jitsi | Server, proxy inverso, firewall, connessione Internet o problema di servizio |
| La riunione rimane aperta, ma l'audio/video si blocca. | Spegni brevemente la telecamera e verifica se l'audio riprende. | Percorso multimediale, larghezza di banda, filtro UDP o carico del dispositivo |
| La disconnessione si verifica solo sulla rete di un'azienda o di una scuola. | Ripeti l'operazione una volta utilizzando un hotspot approvato. | Criteri di rete, proxy, VPN o traffico WebRTC bloccato |
| Il problema inizia dopo una modifica del server o del proxy. | Controlla i registri di configurazione e di servizio più recenti. | Impostazioni di segnalazione, TLS, NAT o firewall di Jitsi self-hosted |
Non modificare più impostazioni contemporaneamente. Prova una sola modifica, se possibile ricollegati alla stessa riunione e verifica se il problema persiste.
Jitsi Meet utilizza WebRTC per audio e video in tempo reale. Una riunione non dipende solo dal caricamento della pagina: il browser deve mantenere la comunicazione con il server e stabilire un percorso multimediale verso Jitsi Videobridge. A volte un partecipante può rimanere visibile nella stanza anche se il flusso multimediale si blocca; un messaggio completo "Sei stato disconnesso" può indicare un'interruzione più ampia della sessione o della comunicazione. La causa esatta non può essere determinata solo da questo messaggio.
Annota l'ora della disconnessione, se il browser ha visualizzato un messaggio di riconnessione, se altri partecipanti sono stati interessati e se la riunione era ospitata su meet.jit.si o su un dominio privato di Jitsi. Evita di pubblicare URL di riunioni private, nomi di stanze, token di accesso o log non anonimizzati.
Utilizza l'azione di riconnessione visualizzata sullo schermo. Se la riunione non si ripristina, apri nuovamente il link di invito originale in una nuova scheda e ricollegati. Verifica che il nome della sala e il dominio dell'organizzatore corrispondano a quelli dell'invito; un errore di battitura o un link obsoleto potrebbero indirizzarti a una sala o a un organizzatore diversi. Se tutti i partecipanti risultano disconnessi, attendi qualche istante e chiedi all'organizzatore della riunione se il servizio è ancora disponibile prima di aggiornare ripetutamente la pagina.
Aggiorna il browser, chiudilo completamente e riprova la riunione. Se la disconnessione si ripete, prova un altro browser attualmente supportato da Jitsi. La pagina di riferimento di Jitsi sui browser supportati elenca i browser compatibili e le note sulla piattaforma; controlla quella pagina perché i dettagli di supporto possono cambiare. Su iPhone e iPad, diversi browser utilizzano lo stesso motore di base, quindi provare un altro browser potrebbe non escludere un problema relativo al motore del browser.
Per un confronto più accurato, prova ad utilizzare una finestra di navigazione in incognito o a disabilitare temporaneamente le estensioni che filtrano gli script, bloccano i tracker o modificano le richieste di rete. Se in questo modo il problema si risolve, riattiva le estensioni una alla volta per identificare la causa del conflitto. Non lasciare le protezioni di sicurezza disabilitate come soluzione temporanea permanente.
Avvicinati al punto di accesso Wi-Fi, metti in pausa i download di grandi dimensioni o i backup sul cloud e prova a connetterti a una rete diversa a cui hai accesso. L'hotspot del telefono può aiutare a distinguere un problema della rete domestica o aziendale da un problema del browser o del server. Se Jitsi funziona sulla rete alternativa ma si disconnette ripetutamente su quella originale, comunica all'amministratore di rete l'ora del test e chiedi se il traffico WebRTC in tempo reale viene filtrato.
Una VPN, un proxy, un captive portal o un firewall potrebbero interrompere la trasmissione di segnali o contenuti multimediali. Se la tua organizzazione richiede l'utilizzo di una VPN, non aggirare le sue policy; chiedi al reparto IT se l'host Jitsi è autorizzato. Se ti è consentito effettuare il confronto con la VPN disconnessa, fallo solo per un breve periodo e riattivala subito dopo.
Su un telefono, mantieni l'app Jitsi o il browser in primo piano durante un test e disattiva le restrizioni di risparmio energetico per quel test, se il dispositivo lo consente. I sistemi operativi mobili potrebbero sospendere l'attività di rete in background. Verifica inoltre che l'app e il sistema operativo siano aggiornati, quindi riavvia il dispositivo se la connessione continua a non funzionare. Un problema di autorizzazione per il microfono o la fotocamera di solito influisce sull'accesso al dispositivo piuttosto che indicare una disconnessione di rete, quindi tratta questi sintomi separatamente.
Disattiva temporaneamente la videocamera e verifica se l'audio si stabilizza. Questo può ridurre il consumo di banda, ma non risolve un problema di routing del server. Se audio e video non funzionano contemporaneamente su una rete ma altrove, verifica le restrizioni del firewall o del NAT. La guida di Jitsi per l'hosting autonomo indica la porta TCP 443 per l'accesso web generale, la porta UDP 10000 per le normali riunioni audio/video e la porta TCP 5349 come fallback coturn quando UDP è bloccato; l'utilizzo opzionale di STUN potrebbe anche coinvolgere la porta UDP 3478. Questi sono requisiti di implementazione lato server, non porte che un partecipante dovrebbe aprire sul proprio dispositivo personale. Consulta le linee guida aggiornate di Jitsi su firewall e NAT .
Se la riunione funziona con una connessione diversa, segnalate il confronto all'amministratore di rete. Chiedetegli di rivedere le regole dell'organizzazione relative al nome host Jitsi e al traffico WebRTC, anziché richiedere la disattivazione generalizzata del firewall.
Verifica che il nome DNS pubblico si risolva nel server previsto, che il certificato TLS sia valido e che il traffico richiesto raggiunga l'host corretto. Se il server si trova dietro un router o un firewall cloud, controlla sia il firewall dell'host che il gruppo di sicurezza a monte o le regole di inoltro delle porte. Una regola in UFW non è utile se il firewall cloud continua a bloccare lo stesso traffico.
sudo ufw status verbose
sudo ss -lntupQuesti comandi mostrano le regole del firewall locale e i socket in ascolto; non dimostrano che i partecipanti esterni possano raggiungere il servizio. Eseguite un test da una rete esterna e verificate che il router o il provider inoltri il traffico pertinente a Jitsi Videobridge. Jitsi precisa che, nelle implementazioni dietro NAT, potrebbe essere necessario un mapping corretto degli indirizzi pubblici e locali qualora le chiamate dall'esterno non funzionassero.
Per una distribuzione con reverse proxy, verificare che HTTPS funzioni e che il proxy inoltri correttamente la segnalazione WebSocket. La guida ufficiale di Docker documenta il /xmpp-websocketpercorso e le intestazioni necessarie per l'esempio con Nginx. Un proxy che serve la pagina ma blocca la segnalazione WebSocket può impedire agli utenti di mantenere la sessione di riunione.
Con Docker Compose, verifica che PUBLIC_URLcorrisponda al dominio pubblico effettivamente utilizzato dai visitatori e che le porte host pubblicate corrispondano alla configurazione del tuo firewall e proxy. La guida di Jitsi avverte che servire una riunione reale direttamente tramite HTTP anziché HTTPS può causare problemi con WebRTC. Evita di copiare frammenti di configurazione da una versione diversa di Jitsi senza verificare la versione e il metodo di distribuzione che stai utilizzando.
Confronta l'orario della disconnessione con i log di servizio. Nelle installazioni di pacchetti Debian o Ubuntu, Jitsi documenta i file di log, inclusi /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.loge /var/log/prosody/prosody.log. Le implementazioni Docker memorizzano i log tramite i loro container, quindi controlla l'output del container pertinente e la directory di configurazione per la versione installata.
sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.logCerca, intorno al timestamp dell'incidente, riavvii del servizio, modifiche alla registrazione del bridge, errori WebSocket, errori di certificato o timeout di connessione ripetuti. Oscura gli identificativi dei partecipanti, i nomi delle stanze, gli indirizzi IP e i token prima di condividere i log. La guida all'hosting self-service per Debian/Ubuntu consiglia inoltre di provare un altro browser, verificare il supporto WebRTC e rivedere le regole del firewall/NAT come passaggi di debug di base.
Partecipa a una riunione di prova dal dispositivo e dalla rete originali, rimani connesso per un tempo sufficiente a coprire il periodo in cui solitamente si verifica il problema e verifica che audio e video rimangano utilizzabili. Ripeti la procedura con un altro partecipante se il problema ha interessato tutti. Per un'installazione self-hosted, verifica sia la segnalazione del browser che la riproduzione di contenuti multimediali dall'esterno della rete del server. Il semplice caricamento della pagina non è sufficiente; la riunione deve rimanere connessa e i partecipanti devono essere in grado di scambiarsi audio e video.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
Risolvi l'avviso di Nextcloud relativo agli indici del database mancanti utilizzando il comando ufficiale occ. Prima di procedere, esegui un backup, visualizza in anteprima le modifiche, avvia la riparazione e verifica il risultato.
