Como corrigir o erro "Falha ao conectar à ponte" no Jitsi Meet
Você abre uma sala do Jitsi Meet, a página carrega normalmente e a sinalização pode até parecer funcionar — mas a conferência nunca estabelece a conexão de mídia. Em vez disso, o Jitsi exibe a mensagem “Falha ao conectar à ponte” ou desconecta repetidamente durante a tentativa de entrada. Em uma instalação auto-hospedada, essa mensagem geralmente indica um problema entre o navegador e o Jitsi Videobridge (JVB) ou entre o Jicofo e a própria ponte.
A maneira mais rápida de solucionar o problema é trabalhar de dentro para fora do servidor: confirme se o JVB está em execução e registrado, confirme se a porta de mídia está acessível, verifique o tratamento de NAT/endereço público e somente então investigue as restrições de rede do lado do cliente. O guia oficial de auto-hospedagem do Jitsi lista a porta UDP 10000 como o caminho de mídia padrão, enquanto o Jicofo é responsável por selecionar um Videobridge para cada conferência.
Um erro de conexão de ponte pode ocorrer mesmo que a interface web do Jitsi tenha carregado com sucesso.
O que o erro geralmente significa
O Jitsi Meet possui vários componentes. A interface web e o Prosody gerenciam a sinalização, o Jicofo coordena as conferências e o Jitsi Videobridge encaminha os fluxos de áudio e vídeo. Se o navegador conseguir acessar a página web, mas não conseguir estabelecer a conexão de mídia com o JVB, ou se o Jicofo não tiver uma ponte estável disponível, a reunião poderá falhar na etapa de ponte.
Para instalações Debian/Ubuntu atuais, o Jitsi documenta os seguintes requisitos de rede: TCP 80 para validação e renovação de certificados, TCP 443 para acesso à web, UDP 10000 para áudio/vídeo em geral, UDP 3478 para consultas STUN opcionais e TCP 5349 para mídia de fallback baseada em coturn quando o UDP estiver bloqueado. Consulte o guia oficial de auto-hospedagem do Jitsi para Debian/Ubuntu . A configuração de referência atual do JVB também mostra a porta UDP 10000 como a porta ICE/UDP padrão na configuração de referência do Jitsi Videobridge .
1. Confirme se o Jitsi Videobridge está em execução.
Comece pelo componente mencionado no erro. Em uma instalação padrão baseada em pacotes, execute:
sudo systemctl status jitsi-videobridge2
Você deseja verificar active (running). Se a unidade falhar, reiniciá-la pode restaurar o serviço temporariamente, mas não pare por aí — verifique os registros para saber por que ela parou:
Uma instalação de pacote bem-sucedida deve mostrar a unidade systemd jitsi-videobridge2 como ativa e em execução.
Procure por falhas de vinculação, erros de autenticação, falhas de conexão XMPP, problemas ICE repetidos ou mensagens indicando que nenhum endereço válido está disponível. Não presuma que um status systemd ativo comprove que o JVB está utilizável: um processo Java pode estar em execução enquanto a rede de mídia ou o registro XMPP estiverem com problemas.
Os logs do JVB são o próximo local a ser verificado quando o serviço está em execução, mas as conferências ainda não conseguem obter uma ponte funcional.
2. Verifique se a porta UDP 10000 está em escuta e liberada no firewall do host.
A porta de mídia JVB padrão do Jitsi é UDP 10000. Primeiro, confirme se o servidor está escutando:
sudo ss -lunp | grep ':10000'
Se nada estiver escutando, inspecione /etc/jitsi/videobridge/jvb.confos logs do JVB antes de alterar as regras do firewall. Se a porta estiver escutando, verifique o firewall do host:
sudo ufw status verbose
Se a porta UDP 10000 estiver ausente das regras do firewall do host, a página da web ainda poderá carregar, mesmo que a mídia da conferência falhe.
Em um servidor Ubuntu usando UFW, o próprio guia do Jitsi utiliza:
sudo ufw allow 10000/udp
sudo ufw status verbose
Após adicionar a regra, verifique se a porta UDP 10000 está permitida; não confie apenas na mensagem de sucesso do comando do firewall.
Se você usa firewalld, nftables, iptables ou um firewall na nuvem em vez do UFW, adicione a regra UDP de entrada equivalente lá. Um erro comum é abrir a porta UDP 10000 no Ubuntu, mas deixá-la bloqueada por um grupo de segurança da AWS, grupo de segurança de rede do Azure, firewall do Google Cloud VPC, firewall do provedor de VPS ou firewall de hardware upstream.
3. Verifique o encaminhamento de portas do roteador quando o servidor estiver atrás de um NAT.
Se o Jitsi estiver sendo executado em um endereço privado, como 192.168.x.x, abrir o UFW não é suficiente. Seu roteador de borda deve encaminhar a porta de mídia UDP externa para a máquina que executa o JVB. Em uma instalação simples com um único servidor, isso geralmente significa encaminhar a porta UDP 10000 para a porta UDP 10000 no servidor Jitsi.
Um servidor Jitsi auto-hospedado atrás de um roteador precisa que a porta de mídia JVB seja encaminhada para o host interno correto.
Se você alterou a porta do JVB, use o valor configurado em vez de abrir a porta 10000 indiscriminadamente. Verifique também se outra máquina ou contêiner não está utilizando a porta. As telas de encaminhamento de portas variam de acordo com o roteador, portanto, considere a ilustração como um exemplo de configuração e não como um mapa exato da interface do usuário para o seu dispositivo.
4. Corrigir o mapeamento de endereços públicos/privados.
O NAT pode causar uma falha mais sutil: o JVB pode anunciar um endereço IP privado para clientes da internet, mesmo que o roteador encaminhe a porta correta. A documentação de início rápido atual do Jitsi mostra um mapeamento estático para /etc/jitsi/videobridge/jvb.confsistemas que precisam de tradução explícita de endereços locais para públicos.
Substitua os espaços reservados pelo endereço privado real do host JVB e pelo endereço público que os clientes remotos podem acessar. Em seguida, reinicie o JVB:
sudo systemctl restart jitsi-videobridge2
Use esta opção somente quando ela corresponder à sua topologia. Servidores com endereçamento público direto, implantações do Docker, múltiplas NICs, IPv6 ou NAT mais complexo podem exigir configurações diferentes. O exemplo oficial encontra-se na seção de NAT do guia de início rápido do Jitsi .
5. Para o Docker, verifique se a porta UDP do JVB está realmente publicada.
No Docker, uma regra de firewall correta no host não resolve o problema se o contêiner JVB não estiver publicando sua porta de mídia. A documentação do Jitsi para Docker lista JVB_PORTa porta 10000 como padrão e instrui os administradores a abrirem a porta UDP 10000 no host. Verifique sua implantação em execução:
Em seguida, inspecione seus arquivos Compose e de ambiente e confirme se o serviço JVB expõe a porta UDP desejada. Se você alterou alguma configuração JVB_PORT, o mapeamento de host, a regra de firewall e qualquer encaminhamento NAT devem estar corretos. Consulte o guia oficial de auto-hospedagem do Jitsi com Docker em vez de copiar um trecho de código Compose antigo de um tutorial de terceiros.
6. Confirme se o Jicofo consegue ver uma Videobridge.
Uma porta UDP perfeitamente acessível não é suficiente se o JVB nunca se registrar no plano de controle XMPP. O Jicofo seleciona um Videobridge para uma conferência, e o guia de implantação escalável do Jitsi recomenda verificar os logs do Prosody e do Jicofo após a reinicialização dos serviços para confirmar se as pontes se conectam e são detectadas.
Se você personalizou domínios XMPP ou executa vários nós, verifique se o Jicofo e o JVB usam o mesmo MUC ("brewery") da ponte. A documentação oficial do MUC do Jitsi Videobridge afirma que o MUC do Jicofo jicofo.bridge.brewery-jiddeve apontar para o mesmo MUC usado pelas instâncias do Videobridge.
Isso é especialmente importante após alterações de nome de host, migrações, implantações em ambientes com hosts separados ou edições manuais de configuração. Para instalações de pacotes padrão criadas com o instalador oficial, evite reescrever a configuração XMPP, a menos que seus logs indiquem um problema de registro ou autenticação.
7. Descarte redes de clientes restritivas, VPNs ou proxies.
Se o servidor funcionar para alguns usuários, mas não para outros, teste a partir de uma rede diferente antes de alterar a configuração do servidor. Redes corporativas, Wi-Fi para visitantes, VPNs e proxies restritivos podem bloquear o UDP. Desconectar temporariamente uma VPN ou proxy é um teste diagnóstico útil; reconecte-o posteriormente, caso sua organização exija.
Realizar testes temporários sem VPN ou proxy manual pode ajudar a distinguir uma restrição na rede do cliente de uma falha JVB em todo o servidor.
O guia do Jitsi para Debian/Ubuntu documenta a porta TCP 5349 como um caminho alternativo para áudio/vídeo (coturn) quando o UDP está bloqueado. Se você precisa que usuários em redes restritivas se conectem de forma confiável, verifique sua configuração TURN/coturn em vez de presumir que abrir a porta TCP 443 para o site automaticamente fornece uma alternativa para mídia.
8. Tente novamente com uma sessão de navegador limpa somente após as verificações do servidor serem aprovadas.
Uma sessão de navegador desatualizada é menos provável do que uma rota JVB quebrada quando todos os participantes veem o mesmo erro de ponte, mas é fácil de resolver. Recarregue a sala, tente uma janela de navegação anônima ou limpe os dados do site para o seu domínio Jitsi e faça login novamente, caso a autenticação esteja ativada.
Uma sessão limpa do navegador é uma verificação de baixo risco no lado do cliente, mas não deve substituir a solução de problemas de JVB, firewall e NAT no servidor.
Se o erro persistir em diferentes navegadores e redes, retorne às verificações do lado do servidor em vez de limpar repetidamente os dados do navegador.
Como verificar se a correção realmente funcionou
Não considere o problema resolvido só porque a janela de erro desapareceu. Teste todo o caminho da mídia.
Crie uma nova sala e participe a partir de dois dispositivos.
Se possível, conecte os dispositivos a redes diferentes, como por exemplo, um na banda larga doméstica e outro em dados móveis.
Confirme se o áudio e o vídeo fluem em ambas as direções durante vários minutos.
Ao participar da conferência, monitore os logs do JVB e do Jicofo e verifique se a conferência foi atribuída a uma ponte sem falhas repetidas de ICE ou de integridade da ponte.
Execute novamente sudo ss -lunp | grep ':10000'a verificação do status do firewall após qualquer reinicialização ou alteração no firewall.
Para instalações com múltiplas pontes, teste mais de uma conferência. O guia de configuração escalável do Jitsi explica que o Jicofo seleciona uma Videobridge para novas conferências, portanto, uma ponte com problemas pode causar falhas intermitentes mesmo quando outra ponte estiver funcionando.
Tabela de diagnóstico rápido
Sintoma
A próxima verificação mais útil
Todo mundo recebe o erro de ponte
Serviço JVB, registro Jicofo, UDP 10000, mapeamento NAT/público
Apenas os usuários em um escritório ou rede Wi-Fi específica apresentam falhas.
Firewall do cliente, VPN/proxy, bloqueio de UDP, fallback TURN
O serviço JVB não permanecerá em execução.
journalctl -u jitsi-videobridge2para erros de bind, configuração, JVM ou XMPP
Funciona em rede local (LAN), mas não pela internet.
Firewall na nuvem, encaminhamento de roteador, mapeamento de endereços públicos/privados
A interface web do Docker funciona, mas não há suporte para mídia.
Porta JVB UDP publicada e correspondênciaJVB_PORT
As falhas começaram após alterações no nome do host/XMPP.
Autenticação JVB e configuração MUC da cervejaria
Resumindo
Para um servidor Jitsi Meet auto-hospedado, o erro "Falha ao conectar à ponte" deve ser tratado inicialmente como um problema de caminho de mídia ou de registro da ponte. Verifique se o Jitsi Videobridge está funcionando corretamente, se a porta UDP 10000 está aberta e acessível através de todas as camadas de firewall/NAT, se o JVB anuncia um endereço IP público válido quando houver NAT envolvido e se o Jicofo reconhece a ponte. Somente após essas verificações você deve se preocupar com o cache do navegador ou com as configurações individuais do cliente.
A solução exata depende da sua topologia, portanto, evite aplicar chaves de configuração antigas do Jitsi apenas porque elas aparecem em postagens antigas do fórum. Os comandos e configurações acima estão alinhados com o Manual Oficial do Jitsi atual e com as fontes de configuração do Jitsi Videobridge verificadas em outubro de 2026.