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.

Ilustração de uma janela do navegador Jitsi Meet exibindo a mensagem "Falha ao conectar à ponte".
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:

sudo systemctl restart jitsi-videobridge2
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager
Terminal do Ubuntu mostrando o status do systemctl para o serviço jitsi-videobridge2 em estado ativo de execução.
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.

Terminal do Ubuntu exibindo um exemplo de saída do journal do Jitsi Videobridge com avisos sobre a porta UDP e a conexão da ponte.
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
Terminal do Ubuntu mostrando regras do UFW onde as portas TCP 22, 80 e 443 são permitidas, mas a porta UDP 10000 está ausente.
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
Terminal do Ubuntu exibindo o comando sudo ufw allow 10000/udp e uma listagem de status do UFW que permite UDP 10000.
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.

Ilustração de administração de roteador mostrando uma regra de encaminhamento de porta UDP da porta externa 10000 para a porta interna 10000 em um endereço de servidor Jitsi privado.
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.

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

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:

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

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.

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 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.

Ilustração das configurações de proxy de rede e internet do Windows com a opção de proxy manual desativada.
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.

Navegador: caixa de diálogo Limpar dados de navegação com cookies e imagens em cache selecionados
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

SintomaA próxima verificação mais útil
Todo mundo recebe o erro de ponteServiç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.

Deixar um comentário

10 Melhores Ferramentas de Varredura de Ping para Encontrar Dispositivos na Sua Rede

10 Melhores Ferramentas de Varredura de Ping para Encontrar Dispositivos na Sua Rede

Compare 10 ferramentas de varredura de ping para descoberta rápida de LAN, varredura multiplataforma e gerenciamento de endereços IP. Saiba o que uma varredura pode — e não pode — revelar.

6 Melhores Ferramentas de Gerenciamento de Rede para Monitorar o Desempenho

6 Melhores Ferramentas de Gerenciamento de Rede para Monitorar o Desempenho

Compare seis ferramentas de gerenciamento de rede para monitoramento de desempenho, incluindo cobertura SNMP, mapeamento, alertas, modelos de implantação e custo-benefício.

Melhores analisadores de Wi-Fi para Windows, iOS e Android

Melhores analisadores de Wi-Fi para Windows, iOS e Android

Compare as melhores opções de analisadores de Wi-Fi para Windows, iPhone e Android, incluindo ferramentas para congestionamento de canais, cobertura de sinal, mapas de calor e solução de problemas de rede.

Monitor de Ping: 7 ferramentas gratuitas e de código aberto para disponibilidade de rede

Monitor de Ping: 7 ferramentas gratuitas e de código aberto para disponibilidade de rede

Compare sete monitores de ping gratuitos e de código aberto, desde suítes completas de rede até sondas de latência específicas, e escolha a opção mais adequada para disponibilidade, perda de pacotes e histórico.

Taxa de transferência de rede versus largura de banda: o que significam e como afetam o desempenho

Taxa de transferência de rede versus largura de banda: o que significam e como afetam o desempenho

Veja como a taxa de transferência de rede difere da largura de banda, o que causa desempenho lento ou instável e quais ferramentas podem testar um caminho ou monitorar o tráfego.

Melhor software de servidor SFTP para transferências seguras de arquivos

Melhor software de servidor SFTP para transferências seguras de arquivos

Compare softwares de servidor SFTP confiáveis ​​para Windows e Linux, incluindo OpenSSH, Bitvise, SolarWinds e SFTPGo. Encontre a solução ideal para suas necessidades de segurança e transferência de arquivos.

Melhores práticas de monitoramento de rede: o que monitorar e quais ferramentas usar

Melhores práticas de monitoramento de rede: o que monitorar e quais ferramentas usar

Crie um monitoramento de rede prático com cobertura clara de dispositivos, métricas de desempenho úteis, alertas acionáveis ​​e uma comparação entre SolarWinds NPM, PRTG e OpManager.

As 7 melhores ferramentas de gerenciamento de endereços IP para equipes de rede

As 7 melhores ferramentas de gerenciamento de endereços IP para equipes de rede

Compare sete ferramentas de gerenciamento de endereços IP para descoberta de sub-redes, coordenação de DNS e DHCP, inventário de rede e IPAM de código aberto.

10 Melhores Ferramentas de Varredura de Rede para Descobrir Dispositivos e IPs

10 Melhores Ferramentas de Varredura de Rede para Descobrir Dispositivos e IPs

Compare ferramentas de varredura de rede para descoberta rápida de dispositivos, varreduras de IP multiplataforma e IPAM corporativo, com orientações sobre como escolher a opção mais adequada para sua rede.

6 ferramentas de monitoramento de rede Linux para dispositivos, hosts e tráfego.

6 ferramentas de monitoramento de rede Linux para dispositivos, hosts e tráfego.

Compare seis ferramentas de monitoramento de rede Linux para descoberta de dispositivos SNMP, gráficos de interface, métricas de host, verificação de serviços e fluxos de tráfego.