Uma chamada do Jitsi Meet pode exibir a mensagem "Você foi desconectado" quando a conexão de sinalização da reunião cai, quando o tráfego de mídia WebRTC não consegue alcançar a ponte de vídeo ou quando uma rede local ou o navegador interrompe a sessão. Comece verificando se o problema afeta apenas um participante ou todos. Essa distinção geralmente indica se o problema está no dispositivo e na rede ou no servidor Jitsi.
| O que você observa | Primeiro verifique | Área provável a ser investigada |
|---|---|---|
| Apenas uma pessoa se desconecta. | Reconectar a partir de outra rede ou dispositivo | Wi-Fi do participante, VPN, navegador, aplicativo ou firewall local. |
| Várias pessoas se desconectam ao mesmo tempo | Pergunte se eles usam o mesmo host Jitsi. | Incidente de servidor, proxy reverso, firewall, conexão de internet ou serviço |
| A reunião permanece aberta, mas o áudio/vídeo congela. | Desligue a câmera brevemente e verifique se o áudio retorna. | Caminho da mídia, largura de banda, filtragem UDP ou carga do dispositivo |
| A desconexão ocorre apenas em uma rede específica da empresa ou escola. | Repita uma vez usando um ponto de acesso autorizado. | Política de rede, proxy, VPN ou tráfego WebRTC bloqueado |
| O problema começa após uma alteração de servidor ou proxy. | Verifique os registros de configuração e serviço recentes. | Configurações de sinalização, TLS, NAT ou firewall do Jitsi autohospedado |
Não altere várias configurações de uma só vez. Teste uma alteração por vez, participe novamente da mesma reunião, se possível, e observe se o problema persiste.
O Jitsi Meet utiliza WebRTC para áudio e vídeo em tempo real. Uma reunião depende de mais do que apenas o carregamento da página: o navegador precisa manter a comunicação com o servidor e estabelecer um caminho de mídia para o Jitsi Videobridge. Um participante pode, por vezes, permanecer visível na sala enquanto a mídia congela; uma mensagem completa de "Você foi desconectado" pode indicar uma interrupção mais ampla da sessão ou da comunicação. A causa exata não pode ser determinada apenas por essa mensagem.
Anote o horário da queda, se o navegador exibiu uma mensagem de reconexão, se outros participantes foram afetados e se a reunião estava hospedada em meet.jit.si ou em um domínio Jitsi privado. Evite publicar o URL da reunião privada, o nome da sala, o token de acesso ou os registros não editados publicamente.
Use a opção de reconexão na tela, se disponível. Se a reunião não for restabelecida, abra o link do convite original novamente em uma nova aba e tente entrar novamente. Confirme se o nome da sala e o domínio do host correspondem ao convite; um erro de digitação ou um link antigo podem levar a uma sala ou host diferente. Se todos estiverem desconectados, aguarde alguns instantes e pergunte ao organizador da reunião se o serviço ainda está disponível antes de atualizar a página repetidamente.
Atualize o navegador, feche-o completamente e tente a reunião novamente. Se a desconexão persistir, teste outro navegador compatível com o Jitsi. A lista de navegadores compatíveis do Jitsi inclui informações sobre suporte e plataformas; consulte essa página, pois os detalhes de suporte podem mudar. No iPhone e iPad, diferentes marcas de navegadores usam o mesmo mecanismo subjacente, portanto, testar outra marca pode não ser a causa exata do problema.
Para uma comparação mais precisa, tente usar uma janela anônima ou desative temporariamente as extensões que filtram scripts, bloqueiam rastreadores ou modificam solicitações de rede. Se isso resolver o problema, reative as extensões uma de cada vez para identificar o conflito. Não deixe as proteções de segurança desativadas como uma solução permanente.
Aproxime-se do ponto de acesso Wi-Fi, pause downloads grandes ou backups na nuvem e faça um teste em uma rede diferente que você tenha autorização para usar. Um ponto de acesso Wi-Fi do seu celular pode ajudar a distinguir um problema na rede doméstica ou do trabalho de um problema no navegador ou no servidor. Se o Jitsi funcionar na rede alternativa, mas desconectar repetidamente na rede original, informe ao administrador da rede o horário do teste e pergunte se o tráfego WebRTC em tempo real está sendo filtrado.
Uma VPN, proxy, portal cativo ou firewall pode interromper a sinalização ou a transmissão de dados. Se sua organização exige uma VPN, não ignore a política de privacidade; pergunte ao departamento de TI se o host Jitsi está autorizado. Se for permitido comparar a conexão com a VPN desconectada, faça-o apenas brevemente e reative-a em seguida.
Em um celular, mantenha o aplicativo Jitsi ou o navegador em primeiro plano durante o teste e desative as restrições de economia de bateria para esse teste, se o seu dispositivo permitir. Os sistemas operacionais móveis podem suspender a atividade de rede em segundo plano. Verifique também se o aplicativo e o sistema operacional estão atualizados e reinicie o dispositivo se a conexão continuar falhando. Um problema de permissão de microfone ou câmera geralmente afeta o acesso ao dispositivo, em vez de causar uma desconexão de rede, portanto, trate esses sintomas separadamente.
Desligue a câmera temporariamente e verifique se o áudio se estabiliza. Isso pode reduzir o uso de largura de banda, mas não corrige uma rota de servidor interrompida. Se o áudio e o vídeo falharem simultaneamente em uma rede e funcionarem em outra, investigue as restrições de firewall ou NAT. O guia de auto-hospedagem do Jitsi identifica a porta TCP 443 para acesso geral à web, a porta UDP 10000 para reuniões normais de áudio/vídeo e a porta TCP 5349 como fallback para o Coturn quando o UDP estiver bloqueado; o uso opcional do STUN também pode envolver a porta UDP 3478. Esses são requisitos de implantação do lado do servidor, não portas que um participante deva abrir em seu dispositivo pessoal. Consulte as diretrizes atuais do Jitsi sobre firewall e NAT .
Se a reunião funcionar em uma conexão diferente, informe essa comparação ao administrador de rede. Peça a ele que revise as regras da organização para o nome de host do Jitsi e o tráfego WebRTC, em vez de solicitar o desligamento total do firewall.
Verifique se o nome DNS público resolve para o servidor esperado, se o certificado TLS é válido e se o tráfego necessário chega ao host correto. Se o servidor estiver atrás de um roteador ou firewall na nuvem, inspecione tanto o firewall do host quanto o grupo de segurança upstream ou as regras de encaminhamento de porta. Uma regra no UFW não ajuda se o firewall na nuvem continuar bloqueando o mesmo tráfego.
sudo ufw status verbose
sudo ss -lntupEsses comandos mostram as regras do firewall local e os sockets em escuta; eles não comprovam que participantes externos podem acessar o serviço. Teste a partir de uma rede externa e confirme se o roteador ou provedor encaminha o tráfego relevante para o Jitsi Videobridge. A Jitsi observa que implantações atrás de NAT podem precisar de mapeamento correto de endereços públicos e locais quando as chamadas não funcionarem de fora da rede.
Para uma implementação de proxy reverso, verifique se o HTTPS está funcionando e se o proxy está encaminhando corretamente a sinalização WebSocket. O guia oficial do Docker documenta a /xmpp-websocketrota e os cabeçalhos necessários para o exemplo com Nginx. Um proxy que serve a página, mas descarta o WebSocket, pode impedir que os usuários mantenham a sessão da reunião.
Com o Docker Compose, verifique se PUBLIC_URLo domínio público utilizado pelos visitantes corresponde ao domínio público usado e se as portas do host publicadas correspondem à configuração do seu firewall e proxy. O guia do Jitsi alerta que servir uma reunião real diretamente via HTTP em vez de HTTPS pode causar problemas com o WebRTC. Evite copiar trechos de configuração de uma versão diferente do Jitsi sem verificar a versão e o método de implantação que você está usando.
Compare o horário da desconexão com os logs de serviço. Em instalações de pacotes Debian ou Ubuntu, o Jitsi documenta arquivos de log, incluindo `logs.jitsi.log`, ` /var/log/jitsi/jvb.loglogs.jitsi.log` /var/log/jitsi/jicofo.loge /var/log/prosody/prosody.log`logs.jitsi.log`. Implantações Docker armazenam logs por meio de seus contêineres; portanto, inspecione a saída relevante do contêiner e o diretório de configuração da sua versão instalada.
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.logProcure por reinicializações de serviço, alterações no registro de ponte, falhas de WebSocket, erros de certificado ou timeouts de conexão repetidos em torno do horário do incidente. Oculte os identificadores dos participantes, nomes de salas, endereços IP e tokens antes de compartilhar os logs. O guia de auto-hospedagem do Debian/Ubuntu também recomenda tentar outro navegador, verificar o suporte a WebRTC e revisar as regras de firewall/NAT como etapas básicas de depuração.
Participe de uma reunião de teste a partir do dispositivo e da rede originais, mantenha-se conectado tempo suficiente para cobrir o período em que a falha normalmente ocorre e confirme se o áudio e o vídeo permanecem utilizáveis. Repita o procedimento com outro participante se o problema afetar todos. Para uma implantação auto-hospedada, verifique a sinalização do navegador e a mídia fora da rede do servidor. O carregamento bem-sucedido da página não é suficiente; a reunião deve permanecer conectada e os participantes devem conseguir trocar áudio e vídeo.
Diagnostique picos de uso da CPU no navegador do Jitsi Meet e reduza a carga do cliente verificando os mosaicos de vídeo, os efeitos da câmera, os gráficos do navegador e as configurações do host.
Monitore a integridade, a carga da conferência e o tráfego do Jitsi Videobridge com seu endpoint Prometheus integrado e, em seguida, explore e visualize os dados em gráficos no Grafana.
Configure um domínio personalizado para o Jitsi Meet Docker com DNS, URL pública, HTTPS, Let's Encrypt, portas de firewall, configurações de NAT e verificação de ponta a ponta.
Corrija os erros 404 do Console de Administração do Zimbra após a renovação do SSL, verificando o URL e a porta corretos, o roteamento do proxy, o status do serviço, os certificados implantados e os logs.
Aprenda a diagnosticar e corrigir o aviso de configuração do PHP OPcache do Nextcloud, verificando o PHP SAPI ativo, os limites de tamanho, os comentários e as configurações de revalidação.
Solucione problemas de falhas na migração do banco de dados Kopano após uma atualização do MySQL ou MariaDB, verificando backups, versões do servidor, modos SQL, conjunto de caracteres, estado do esquema e logs.
Conecte o Nextcloud ao LDAP ou Active Directory com transporte seguro, filtros de usuários e grupos, atributos de login e uma implementação testada.
Corrija as notificações do Element no Android em telefones sem serviços do Google configurando o UnifiedPush, as permissões do Android, as configurações de bateria e realizando testes de verificação confiáveis.
Remova o aviso de índices de banco de dados ausentes do Nextcloud com o comando oficial occ. Primeiro, faça um backup, visualize as alterações, execute o reparo e verifique o resultado.
Configure o SSO do Keycloak para o Element Web conectando o OIDC ao Synapse, definindo a URL de retorno de chamada exata, mapeando as declarações do usuário e testando o logout.
