How to Fix Jitsi Meet “Failed to Connect to Bridge” Error

You open a Jitsi Meet room, the page loads normally, and signaling may even appear to work—but the conference never establishes media. Instead, Jitsi reports “Failed to connect to bridge” or repeatedly disconnects while joining. On a self-hosted deployment, that message usually points to a problem between the browser and Jitsi Videobridge (JVB), or between Jicofo and the bridge itself.

The fastest way to troubleshoot it is to work from the server outward: confirm that JVB is running and registered, confirm that its media port is reachable, verify NAT/public-address handling, and only then investigate client-side network restrictions. The official Jitsi self-hosting guide lists UDP port 10000 as the default media path, while Jicofo is responsible for selecting a Videobridge for each conference.

What the error usually means

Jitsi Meet has several components. The web interface and Prosody handle signaling, Jicofo coordinates conferences, and Jitsi Videobridge forwards the audio and video streams. If the browser can reach the web page but cannot establish media with JVB, or if Jicofo has no healthy bridge available, the meeting can fail at the bridge stage.

For current Debian/Ubuntu installations, Jitsi documents these network requirements: TCP 80 for certificate validation and renewal, TCP 443 for web access, UDP 10000 for general audio/video, UDP 3478 for optional STUN queries, and TCP 5349 for coturn-based fallback media when UDP is blocked. See the official Jitsi Debian/Ubuntu self-hosting guide. JVB’s current reference configuration also shows UDP port 10000 as the default ICE/UDP port in the Jitsi Videobridge reference configuration.

1. Confirm that Jitsi Videobridge is running

Start with the component named in the error. On a standard package-based installation, run:

sudo systemctl status jitsi-videobridge2

You want to see active (running). If the unit is failed, restarting it may restore service temporarily, but do not stop there—check the logs to learn why it stopped:

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

Look for bind failures, authentication errors, XMPP connection failures, repeated ICE problems, or messages indicating that no valid address is available. Do not assume that an active systemd status proves JVB is usable: a Java process can be running while media networking or XMPP registration is broken.

2. Verify that UDP 10000 is listening and allowed through the host firewall

El puerto multimedia JVB predeterminado de Jitsi es UDP 10000. Primero, confirme que el servidor está escuchando:

sudo ss -lunp | grep ':10000'

Si no hay ningún servicio escuchando, inspeccione /etc/jitsi/videobridge/jvb.conflos registros de JVB antes de cambiar las reglas del firewall. Si el puerto está escuchando, verifique el firewall del host:

sudo ufw status verbose

En un servidor Ubuntu que utiliza UFW, la propia guía de Jitsi utiliza:

sudo ufw allow 10000/udp
sudo ufw status verbose

Si utiliza firewalld, nftables, iptables o un firewall en la nube en lugar de UFW, agregue allí la regla UDP de entrada equivalente. Un error común es abrir el puerto UDP 10000 en Ubuntu, pero dejarlo bloqueado por un grupo de seguridad de AWS, un grupo de seguridad de red de Azure, un firewall de VPC de Google Cloud, un firewall del proveedor de VPS o un firewall de hardware de la red.

3. Compruebe el reenvío de puertos del router cuando el servidor esté detrás de NAT.

Si Jitsi se ejecuta en una dirección privada, como 192.168.x.x, abrir UFW no es suficiente. Su enrutador perimetral debe reenviar el puerto multimedia UDP externo a la máquina que ejecuta JVB. En una instalación simple de un solo servidor, esto generalmente significa reenviar UDP 10000 a UDP 10000 en el servidor Jitsi.

Si modificaste el puerto de JVB, usa el valor configurado en lugar de abrir el puerto 10000 sin más. Verifica también que ninguna otra máquina o contenedor esté utilizando ese puerto. Las pantallas de reenvío de puertos varían según el router, así que considera esta ilustración como un ejemplo de configuración y no como una representación exacta de la interfaz de usuario de tu dispositivo.

4. Corrija la asignación de direcciones públicas/privadas.

NAT puede causar un fallo más sutil: JVB puede anunciar un candidato privado a los clientes de Internet aunque el enrutador reenvíe el puerto correcto. La documentación de inicio rápido actual de Jitsi muestra una asignación estática /etc/jitsi/videobridge/jvb.confpara sistemas que necesitan una traducción explícita de direcciones locales a públicas:

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

Sustituya los marcadores de posición con la dirección privada real del host JVB y la dirección pública a la que pueden acceder los clientes remotos. A continuación, reinicie JVB:

sudo systemctl restart jitsi-videobridge2

Utilice esta opción únicamente si coincide con su topología. Los servidores con direccionamiento público directo, implementaciones de Docker, múltiples tarjetas de red, IPv6 o NAT más complejo pueden requerir configuraciones diferentes. El ejemplo de referencia se encuentra en la sección NAT de la guía de inicio rápido de Jitsi .

5. Para Docker, verifique que el puerto UDP de JVB esté publicado.

En Docker, una regla de firewall correcta en el host no sirve de nada si el contenedor JVB no publica su puerto multimedia. La documentación de Docker de Jitsi indica JVB_PORTun valor predeterminado de 10000 e indica a los administradores que abran el puerto UDP 10000 en el host. Compruebe su implementación en ejecución:

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

Luego, revise sus archivos Compose y de entorno y confirme que el servicio JVB expone el puerto UDP previsto. Si realizó algún cambio JVB_PORT, la asignación de host, la regla del firewall y cualquier reenvío NAT deben coincidir. Consulte la guía oficial de Jitsi Docker para autoalojamiento en lugar de copiar un fragmento antiguo de Compose de un tutorial de terceros.

6. Confirma que Jicofo puede ver un Videobridge.

Un puerto UDP perfectamente accesible no es suficiente si JVB nunca se registra en el plano de control XMPP. Jicofo selecciona un Videobridge para una conferencia, y la guía de implementación escalable de Jitsi recomienda revisar los registros de Prosody y Jicofo después de reiniciar los servicios para confirmar que los puentes se conectan y se detectan.

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

Si personalizaste dominios XMPP o ejecutas varios nodos, verifica que Jicofo y JVB utilicen el mismo MUC de puente ("brewery"). La documentación oficial de Jitsi Videobridge MUC indica que Jicofo jicofo.bridge.brewery-jiddebe apuntar al mismo MUC que utilizan las instancias de Videobridge.

Esto es especialmente importante después de cambios de nombre de host, migraciones, implementaciones en hosts separados o ediciones manuales de la configuración. Para instalaciones de paquetes estándar creadas con el instalador oficial, evite modificar la configuración XMPP a menos que los registros indiquen un problema de registro o autenticación.

7. Descartar una red cliente restrictiva, una VPN o un proxy

Si el servidor funciona para algunos usuarios pero no para otros, pruebe desde una red diferente antes de modificar la configuración del servidor. Las redes corporativas, las redes Wi-Fi para invitados, las VPN y los proxies estrictos pueden bloquear el protocolo UDP. Desconectar temporalmente una VPN o un proxy es una prueba de diagnóstico útil; vuelva a conectarlo posteriormente si su organización lo requiere.

La guía de Jitsi para Debian/Ubuntu documenta el puerto TCP 5349 como ruta alternativa de coturn para audio/video cuando UDP está bloqueado. Si necesita que los usuarios en redes con restricciones se conecten de forma fiable, verifique su configuración de TURN/coturn en lugar de asumir que abrir el puerto TCP 443 para el sitio web proporciona automáticamente una ruta alternativa para los medios.

8. Vuelva a intentarlo con una sesión de navegador limpia solo después de que las comprobaciones del servidor sean correctas.

Es menos probable que se trate de una sesión de navegador obsoleta que de una ruta JVB defectuosa cuando todos los participantes ven el mismo error de puente, pero es fácil de solucionar. Recargue la sala, intente usar una ventana de navegación privada o borre los datos del sitio para su dominio Jitsi e inicie sesión nuevamente si la autenticación está habilitada.

Si el error se reproduce en diferentes navegadores y redes, vuelva a realizar las comprobaciones del lado del servidor en lugar de borrar repetidamente los datos del navegador.

Cómo verificar que la solución realmente funcionó.

No considere que el problema está resuelto solo porque haya desaparecido la ventana emergente de error. Pruebe la ruta completa del archivo multimedia.

• Crea una nueva sala y únete desde dos dispositivos.
• Si es posible, conecta los dispositivos a redes diferentes, por ejemplo, uno a la red de banda ancha doméstica y el otro a los datos móviles.
• Confirma que tanto el audio como el vídeo fluyen en ambas direcciones durante varios minutos.
• Durante la conexión, supervise los registros de JVB y Jicofo y verifique que la conferencia esté asignada a un puente sin que se produzcan fallos repetidos de ICE o de estado del puente.
• Vuelva sudo ss -lunp | grep ':10000'a ejecutar la comprobación del estado del firewall después de cualquier reinicio o cambio en el firewall.

Para instalaciones con múltiples puentes, pruebe más de una conferencia. La guía de configuración escalable de Jitsi explica que Jicofo selecciona un Videobridge para las nuevas conferencias, por lo que un puente defectuoso puede producir fallos intermitentes incluso cuando otro puente funciona correctamente.

Tabla de diagnóstico rápido

En resumen

Para un servidor Jitsi Meet autohospedado, el error "Error al conectar con el puente" se suele tratar primero como un problema de ruta de medios o de registro del puente. Verifique que Jitsi Videobridge funcione correctamente, que el puerto UDP 10000 esté activo y accesible a través de todos los firewalls/NAT, que JVB anuncie una dirección IP pública válida cuando se utilice NAT y que Jicofo detecte el puente. Solo después de estas comprobaciones debería revisar la caché del navegador o la configuración de cada cliente.

La solución exacta depende de tu topología, así que evita usar claves de configuración antiguas de Jitsi solo porque aparezcan en publicaciones antiguas del foro. Los comandos y la configuración anteriores se ajustan al Manual oficial de Jitsi y a las fuentes de configuración de Jitsi Videobridge actuales, verificadas en octubre de 2026.