Una llamada de Jitsi Meet puede mostrar el mensaje "Te has desconectado" cuando se pierde la conexión de señalización de la reunión, cuando el tráfico multimedia WebRTC no puede llegar al puente de vídeo o cuando una red local o un navegador interrumpe la sesión. Empieza por comprobar si el problema afecta a un participante o a todos. Esta distinción suele indicar si debes solucionar el problema en el dispositivo y la red o en el servidor Jitsi.
| Lo que observas | Primera comprobación | Área probable para investigar |
|---|---|---|
| Solo una persona se desconecta. | Volver a conectarse desde otra red o dispositivo. | Wi-Fi del participante, VPN, navegador, aplicación o cortafuegos local |
| Varias personas se desconectan al mismo tiempo. | Pregúntales si utilizan el mismo servidor Jitsi. | Servidor, proxy inverso, cortafuegos, conexión a Internet o incidente de servicio |
| La reunión permanece abierta, pero el audio/video se congela. | Apaga la cámara brevemente y comprueba si vuelve el audio. | Ruta de medios, ancho de banda, filtrado UDP o carga del dispositivo |
| La desconexión ocurre solo en una red de la empresa o escuela. | Repita el procedimiento una vez utilizando un punto de acceso autorizado. | Política de red, proxy, VPN o tráfico WebRTC bloqueado |
| El problema comienza después de un cambio de servidor o proxy. | Compruebe la configuración reciente y los registros de servicio. | Configuración de señalización, TLS, NAT o firewall de Jitsi autogestionada |
No cambies varias configuraciones a la vez. Prueba un cambio, vuelve a unirte a la misma reunión si es posible y observa si el síntoma cambia.
Jitsi Meet utiliza WebRTC para audio y video en tiempo real. Una reunión depende de algo más que la carga de la página: el navegador debe mantener la comunicación con el servidor y establecer una ruta multimedia hacia Jitsi Videobridge. En ocasiones, un participante puede permanecer visible en la sala mientras la imagen se congela; un mensaje completo de "Te has desconectado" puede indicar una interrupción general de la sesión o de la comunicación. La causa exacta no se puede determinar solo con ese mensaje.
Anota la hora de la desconexión, si el navegador mostró un mensaje para reconectarse, si otros participantes se vieron afectados y si la reunión se realizó en meet.jit.si o en un dominio privado de Jitsi. Evita publicar públicamente la URL de la reunión privada, el nombre de la sala, el token de acceso o los registros sin censurar.
Utilice la opción de reconexión en pantalla si aparece. Si la reunión no se restablece, abra de nuevo el enlace de invitación original en una pestaña nueva y vuelva a unirse. Confirme que el nombre de la sala y el dominio del anfitrión coincidan con la invitación; un error tipográfico o un enlace antiguo pueden llevar a una sala o anfitrión diferente. Si todos están desconectados, espere un momento y pregunte al organizador de la reunión si el servicio sigue disponible antes de actualizar la página repetidamente.
Actualiza el navegador, ciérralo por completo e intenta la reunión de nuevo. Si la desconexión persiste, prueba con otro navegador compatible con Jitsi. La lista de navegadores compatibles de Jitsi incluye información sobre compatibilidad y plataformas; consulta esa página, ya que los detalles de compatibilidad pueden cambiar. En iPhone y iPad, diferentes marcas de navegadores utilizan el mismo motor, por lo que probar con otra marca podría no solucionar el problema del motor del navegador.
Para una comparación precisa, prueba con una ventana privada o desactiva temporalmente las extensiones que filtran scripts, bloquean rastreadores o modifican las solicitudes de red. Si esto soluciona el problema, vuelve a activar las extensiones una por una para identificar el conflicto. No dejes las protecciones de seguridad desactivadas como solución permanente.
Acércate al punto de acceso Wi-Fi, pausa las descargas grandes o las copias de seguridad en la nube y realiza una prueba en una red diferente a la que tengas autorización. Usar la conexión Wi-Fi de tu teléfono puede ayudarte a distinguir un problema de red doméstica o laboral de un problema del navegador o del servidor. Si Jitsi funciona en la red alternativa pero se desconecta repetidamente en la original, informa al administrador de la red la hora de la prueba y pregúntale si se filtra el tráfico WebRTC en tiempo real.
Una VPN, un proxy, un portal cautivo o un cortafuegos pueden interrumpir la señalización o el flujo de datos. Si su organización requiere una VPN, no ignore su política; consulte con el departamento de TI si el host de Jitsi está permitido. Si se le permite realizar la comparación con la VPN desconectada, hágalo solo brevemente y vuelva a activarla después.
En un teléfono, mantén la aplicación o el navegador de Jitsi en primer plano durante la prueba y desactiva las restricciones de ahorro de batería para esa prueba si tu dispositivo lo permite. Los sistemas operativos móviles pueden suspender la actividad de red en segundo plano. Además, verifica que la aplicación y el sistema operativo estén actualizados y, si la conexión sigue fallando, reinicia el dispositivo. Un problema con los permisos del micrófono o la cámara generalmente afecta el acceso al dispositivo en lugar de provocar una desconexión de red, así que trata esos síntomas por separado.
Apague la cámara temporalmente y compruebe si el audio se estabiliza. Esto puede reducir el uso de ancho de banda, pero no soluciona un problema con la ruta del servidor. Si el audio y el vídeo fallan simultáneamente en una red y funcionan en otra, investigue las restricciones del firewall o NAT. La guía de autoalojamiento de Jitsi identifica el puerto TCP 443 para el acceso web general, el UDP 10000 para reuniones de audio/vídeo normales y el TCP 5349 para la conmutación por error cuando se bloquea UDP; el uso opcional de STUN también puede implicar el UDP 3478. Estos son requisitos de implementación del servidor, no puertos que un participante deba abrir en un dispositivo personal. Consulte la guía actual de Jitsi sobre firewall y NAT .
Si la reunión funciona con una conexión diferente, informe de esa diferencia al administrador de red. Pídale que revise las reglas de la organización para el nombre de host de Jitsi y el tráfico WebRTC, en lugar de solicitar el cierre general del cortafuegos.
Verifique que el nombre DNS público se resuelva al servidor esperado, que el certificado TLS sea válido y que el tráfico requerido llegue al host correcto. Si el servidor está detrás de un enrutador o firewall en la nube, inspeccione tanto el firewall del host como el grupo de seguridad o las reglas de reenvío de puertos. Una regla en UFW no sirve de nada si el firewall en la nube sigue bloqueando el mismo tráfico.
sudo ufw status verbose
sudo ss -lntupEstos comandos muestran las reglas del firewall local y los sockets de escucha; no demuestran que los participantes externos puedan acceder al servicio. Realice pruebas desde una red externa y confirme que el enrutador o proveedor reenvía el tráfico correspondiente a Jitsi Videobridge. Jitsi indica que las implementaciones detrás de NAT pueden requerir una asignación correcta de direcciones públicas y locales cuando las llamadas no funcionan desde el exterior.
Para una implementación de proxy inverso, verifique que HTTPS funcione y que el proxy reenvíe correctamente la señalización de WebSocket. La guía oficial de Docker documenta la /xmpp-websocketruta y los encabezados necesarios para su ejemplo de Nginx. Un proxy que sirve la página pero descarta el WebSocket puede impedir que los usuarios mantengan la sesión de la reunión.
Con Docker Compose, compruebe que PUBLIC_URLcoincida con el dominio público que utilizan los visitantes y que los puertos del host publicados coincidan con la configuración de su firewall y proxy. La guía de Jitsi advierte que servir una reunión real directamente a través de HTTP en lugar de HTTPS puede causar problemas con WebRTC. Evite copiar fragmentos de configuración de una versión diferente de Jitsi sin comprobar la versión y el método de implementación que utiliza.
Compara la hora de la desconexión con los registros del servicio. En las instalaciones de paquetes de Debian o Ubuntu, Jitsi documenta archivos de registro que incluyen /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, y /var/log/prosody/prosody.log. Las implementaciones de Docker almacenan los registros a través de sus contenedores, así que inspecciona la salida del contenedor correspondiente y el directorio de configuración de tu versión 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.logBusque en torno a la marca de tiempo del incidente reinicios del servicio, cambios en el registro del puente, fallos de WebSocket, errores de certificado o tiempos de espera de conexión repetidos. Oculte los identificadores de los participantes, los nombres de las salas, las direcciones IP y los tokens antes de compartir los registros. La guía de autoalojamiento de Debian/Ubuntu también recomienda probar con otro navegador, comprobar la compatibilidad con WebRTC y revisar las reglas del cortafuegos/NAT como pasos básicos de depuración.
Únase a una reunión de prueba desde el dispositivo y la red originales, permanezca conectado el tiempo suficiente para cubrir el período en el que suele ocurrir el fallo y confirme que el audio y el vídeo siguen funcionando. Repita el proceso con otro participante si el problema afectó a todos. En el caso de una implementación autoalojada, verifique tanto la señalización del navegador como el contenido multimedia desde fuera de la red del servidor. No basta con que la página se cargue correctamente; la reunión debe permanecer conectada y los participantes deben poder intercambiar audio y vídeo.
Configure Z-Push con Kopano para la sincronización segura de correo electrónico, contactos, calendario y tareas mediante ActiveSync. Compare las opciones de backend e implementación y, a continuación, verifique la configuración móvil.
Solucione los problemas de desconexión de Jitsi Meet con una lista de verificación práctica para navegadores, dispositivos móviles, redes inestables, cortafuegos y servidores autogestionados.
Solucione los problemas de calidad de las llamadas de Nextcloud Talk, configure coturn, abra los puertos correctos, pruebe los candidatos ICE y decida cuándo TURN o HPB es la solución adecuada.
Implementa Element Web en Nginx con un servidor principal personalizado, HTTPS, almacenamiento en caché y encabezados de seguridad, además de comprobaciones sencillas para detectar problemas de configuración comunes.
Solucione el error de presentación "Tipo de archivo no compatible" de BigBlueButton comprobando la extensión del archivo, exportando un PDF real, probando con otro archivo e identificando cuándo debe ponerse en contacto con un administrador.
Solucione los errores de Matrix Synapse "Demasiados archivos abiertos" comprobando el límite del servicio, aplicando una modificación de systemd y verificando el proceso en ejecución.
Configura la búsqueda de texto completo de Nextcloud con Elasticsearch 8, instala las aplicaciones necesarias, configura el índice, ejecuta el primer rastreo y verifica los resultados de la búsqueda.
Crea un bot de Matrix con Python y Simple-Matrix-Bot-Lib, compara las opciones de autenticación y despliegue, prueba los comandos y comprende cuándo usar matrix-nio en su lugar.
Instala Jitsi Meet en Ubuntu 24.04 con DNS, reglas de firewall, repositorios oficiales, SSL de Let's Encrypt, comprobaciones de servicio y solución de problemas de NAT.
Solucione los errores de certificado de sincronización de ownCloud Desktop comprobando la URL del servidor, el nombre y la cadena del certificado, la hora del sistema, la versión del cliente y el almacén de CA de confianza.
