Cómo configurar un nombre de dominio personalizado para Jitsi Meet Docker

La ruta más corta para un dominio personalizado para Jitsi Meet Docker es apuntar un nombre de host DNS al host de Docker, configurarlo PUBLIC_URLcon la URL HTTPS final, configurar TLS de confianza para ese mismo nombre de host y asegurarse de que los medios WebRTC aún puedan llegar a Jitsi Videobridge. Para una instalación directa a Internet, la configuración oficial de Docker admite la automatización de certificados integrada a través de ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, y LETSENCRYPT_EMAIL.

Esta guía utiliza meet.example.comcomo ejemplo concreto el proyecto estándar docker-jitsi-meet y lo asume . Reemplace el nombre de host, la dirección de correo electrónico y la dirección IP (solo para documentación) del ejemplo con sus propios valores. La configuración descrita aquí se verificó con el manual oficial de Jitsi Docker y el proyecto actual env.exampleel 7 de octubre de 2026.

Lo que necesitas antes de cambiar el dominio

Un dominio personalizado funciona mejor cuando el nombre de host se decide antes de solicitar el certificado. Por ejemplo, si los usuarios deben abrir https://meet.example.com, el DNS, PUBLIC_URLy el certificado TLS deben usar meet.example.com. Mezclar jitsi.example.comen un lugar y meet.example.comen otro es una causa común de advertencias de certificado o redirecciones al host incorrecto.

• Un dominio que usted controla.
• Un servidor con Docker Engine y Docker Compose.
• Una dirección IP pública o un proxy inverso que ya posea los puertos 80 y 443.
• Acceso al firewall para los puertos web y el tráfico multimedia de Jitsi.
• El docker-jitsi-meetdirectorio existente y su .envarchivo.

El manual oficial de Jitsi Docker indica que PUBLIC_URLdebe configurarse con el dominio real para una implementación en producción. También documenta los puertos 80/TCP, 443/TCP y 10000/UDP como los puertos externos principales para la configuración directa estándar. Consulte la guía de autoalojamiento de Jitsi Docker .

Paso 1: Apunte el nombre de host personalizado al servidor Jitsi.

Cree un registro A para el nombre de host que desea utilizar. En este ejemplo, meet.example.comapunta a la dirección IPv4 pública del servidor. Si su servidor tiene conectividad IPv6 estable, también puede agregar un registro AAAA que apunte a su dirección IPv6 pública.

Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300

No copie 203.0.113.10la ilustración en una implementación real; esa dirección está reservada para documentación. Si utiliza un proveedor de DNS con modo proxy/CDN, comience con la resolución DNS estándar, a menos que haya confirmado que el proxy admite el patrón de tráfico de Jitsi que pretende utilizar.

Paso 2: Establezca los valores de PUBLIC_URL y HTTPS en .env

Abra el .envarchivo en el directorio donde lo clonó o extrajo docker-jitsi-meet. Para una implementación directa donde el contenedor web de Jitsi escuchará públicamente en los puertos 80 y 443, las configuraciones importantes son:

PUBLIC_URL=https://meet.example.com
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_HTTP_REDIRECT=1
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com
LETSENCRYPT_ACME_SERVER=letsencrypt

PUBLIC_URLNo es solo cosmético. Jitsi lo usa al crear una configuración efectiva, por lo que dejarlo en localhost o en un nombre de host antiguo puede producir enlaces rotos y un comportamiento inconsistente. El ejemplo de proyecto actual también señala que si usa deliberadamente un puerto HTTPS no estándar, ese puerto pertenece a PUBLIC_URL.

Actualmente, la muestra oficial identifica a ZeroSSL como el servidor ACME predeterminado y permite usar LETSENCRYPT_ACME_SERVER="letsencrypt"Let's Encrypt cuando se desea específicamente. Si su instalación actual ya obtiene un certificado de confianza correctamente, mantenga la configuración de ACME que coincida con su entorno de trabajo en lugar de cambiar de proveedor sin motivo.

Paso 3: Abra los puertos del firewall necesarios.

Para la implementación de Docker con acceso directo a Internet descrita anteriormente, permita los puertos 80/TCP, 443/TCP y 10000/UDP. Mantenga también abierto el puerto de administración SSH. En un host Ubuntu que utilice UFW, un ejemplo mínimo es:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verbose

Los puertos web sirven para el sitio y el desafío de certificados. El puerto multimedia predeterminado de Jitsi Videobridge es UDP 10000. Una página puede cargarse perfectamente, pero las reuniones pueden fallar o perder audio/video si el puerto multimedia está bloqueado, por lo que verificar solo HTTPS no es suficiente.

Si su host está detrás de NAT, revise también JVB_ADVERTISE_IPS. El manual oficial explica que esta variable controla la dirección que Jitsi Videobridge anuncia para los medios y es necesaria en muchas implementaciones de LAN o NAT. Un ejemplo típico de Internet pública es:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Paso 4: Reinicie la pila de Docker con el nuevo dominio.

Guarda .envlos archivos y vuelve a crear los contenedores para que se apliquen los cambios del entorno:

docker compose down
docker compose up -d
docker compose ps

Una solución simple restartno es la mejor opción después de cambiar las variables de entorno, ya que la definición del contenedor existente aún puede contener el entorno anterior. Recrear la pila hace que los nuevos PUBLIC_URLvalores de puerto y la configuración del certificado sean explícitos.

Si parte de una copia nueva del proyecto, siga primero los pasos de inicio rápido oficiales, incluida la generación de las contraseñas necesarias y la creación de los directorios de configuración. Las versiones recientes de contenedores Jitsi ejecutan los servicios como un usuario sin privilegios y requieren almacenamiento con permisos de escritura y directorios temporales, por lo que una instalación completamente nueva debe seguir los comandos de directorio del manual actual en lugar de un tutorial antiguo de terceros.

Paso 5: Confirme el DNS y HTTPS desde fuera del servidor.

Una vez que el DNS se haya propagado, compruebe que el nombre de host se resuelva a la dirección pública esperada:

dig +short meet.example.com

A continuación, pruebe el punto final HTTPS:

curl -I https://meet.example.com

Una respuesta exitosa demuestra que DNS, TCP 443 y el servicio web funcionan correctamente. Sin embargo, esto no demuestra que la comunicación multipartita funcione, por lo que se trata de una verificación intermedia y no de la meta final.

Si digdevuelve una dirección antigua, espere a que finalice el TTL de DNS o corrija el registro. Si DNS es correcto pero curlse agota el tiempo de espera, revise los grupos de seguridad en la nube, el firewall del host, las reglas del enrutador/NAT y compruebe si otro servicio ya está utilizando el puerto 443.

Paso 6: Comprobar la emisión del certificado y los registros web.

Si el navegador sigue mostrando una advertencia de certificado, inspeccione los registros del contenedor web en lugar de eliminar repetidamente la configuración y solicitar otro certificado:

docker compose logs --tail=200 web

Busque errores de validación ACME, fallos de enlace de puerto o discrepancias en el nombre de host. El manual de Jitsi advierte sobre los límites de velocidad de la autoridad de certificación y recomienda conservar el almacenamiento de configuración que contiene los certificados emitidos. Durante las pruebas de configuración repetidas, el entorno de pruebas puede ser útil, pero después de dejar de usarlo, el manual indica que es posible que sea necesario eliminar el material de certificados antiguo del almacenamiento web antes de solicitar un certificado de producción.

Si ya dispone de un certificado de confianza de otra fuente, Jitsi también permite montar una cadena completa y una clave privada existentes en el servicio web, en lugar de habilitar el flujo ACME integrado. Siga el ejemplo de montaje de certificados en la sección oficial de certificados existentes .

Paso 7: Abra el dominio personalizado en un navegador.

Acceda https://meet.example.coma la página desde un navegador moderno. Debería ver la página de inicio de Jitsi bajo el nombre de host que haya seleccionado, con un indicador TLS válido. Cree una sala de prueba con un nombre provisional.

Utilice HTTPS para reuniones reales. La guía oficial de Docker advierte específicamente que el acceso HTTP directo puede provocar fallos en las API WebRTC del navegador, como el acceso al micrófono y la cámara. Por lo tanto, HTTPS forma parte de la configuración funcional, no es simplemente una medida de seguridad.

Paso 8: Pruebe una llamada real, no solo la página de inicio.

Conéctese a la misma sala desde dos dispositivos o redes diferentes, si es posible. Confirme que cada participante pueda enviar y recibir audio y video. Es importante realizar una prueba con dos navegadores, ya que una instalación puede mostrar el sitio web correctamente aunque la dirección de Videobridge o la ruta UDP sean incorrectas.

En instalaciones con NAT, un síntoma común es que la primera conexión parece normal, pero la transmisión multimedia falla a medida que se unen más participantes. En ese caso, revise JVB_ADVERTISE_IPSla configuración de NAT pública y el puerto UDP 10000. El manual de Jitsi indica explícitamente que la dirección multimedia de Videobridge sigue siendo relevante incluso cuando el tráfico HTTP es gestionado por un proxy inverso.

Cuándo deberías usar un proxy inverso en su lugar

La configuración directa descrita anteriormente es apropiada cuando el contenedor web de Jitsi puede gestionar los puertos públicos 80 y 443. Si el mismo servidor ya ejecuta Nginx, Apache, Caddy, Traefik u otro proxy en esos puertos, no intente vincular Jitsi a ellos simultáneamente.

Para un proxy inverso en el mismo host, la guía oficial de Jitsi Docker recomienda deshabilitar HTTPS dentro del contenedor de Jitsi, evitar la exposición pública de sus puertos web internos y reenviar las solicitudes al ingress HTTP del contenedor. El proxy también debe admitir el reenvío de WebSocket para /xmpp-websocket. Un entorno típico del lado de Jitsi es:

DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.com

Luego, finalice el certificado de confianza en su proxy inverso. Esto es más adecuado cuando un proxy administra certificados para varias aplicaciones. No es motivo para cambiar la URL visible externamente PUBLIC_URL; los usuarios deberían seguir viendo el dominio HTTPS final.

Solución de problemas de dominios personalizados

El dominio antiguo sigue apareciendo después de editar .env.

Recrea los contenedores con docker compose downseguido de docker compose up -d. Además, verifica que hayas editado el .envarchivo utilizado por el proyecto Compose que estás iniciando.

La validación del certificado HTTPS falla.

Confirme que los registros DNS A/AAAA apuntan al servidor que recibe el desafío y que el puerto público 80 es accesible al usar el flujo de certificado directo integrado. Verifique docker compose logs webel error ACME exacto antes de realizar otra solicitud.

La página se carga, pero los participantes no tienen audio ni vídeo.

Verifique UDP 10000 y, para implementaciones NAT, configure correctamente JVB_ADVERTISE_IPS. Recuerde que el proxy inverso gestiona el tráfico web; no reemplaza la ruta de medios de Videobridge.

El navegador funciona, pero la aplicación móvil rechaza el servidor.

Verifique la cadena de certificados. El manual de Jitsi Docker indica que las aplicaciones móviles no funcionan con el certificado autofirmado predeterminado. Utilice un certificado de confianza pública o un diseño de infraestructura donde la aplicación reciba una cadena de certificados de confianza.

Lista de verificación final

• meet.example.comSe resuelve en el discurso público previsto.
• PUBLIC_URL=https://meet.example.comcoincide exactamente con la URL del navegador.
• El certificado TLS es de confianza y cubre meet.example.com.
• Los puertos 80/TCP y 443/TCP son accesibles para la configuración directa.
• El protocolo UDP 10000 llega al host de Jitsi Videobridge.
• JVB_ADVERTISE_IPSEs correcto cuando el servidor está detrás de NAT o necesita direcciones anunciadas explícitamente.
• docker compose psmuestra los contenedores necesarios en ejecución.
• Una prueba con dos participantes envía audio y vídeo correctamente.

Una vez superadas esas comprobaciones, el dominio personalizado no solo apunta a Jitsi, sino que también está configurado para los aspectos que realmente importan en una reunión real: HTTPS, señalización y transporte de medios.

Referencias oficiales

• Guía de autoalojamiento de Jitsi Meet — Docker
• docker-jitsi-meet env.example
• Repositorio oficial de docker-jitsi-meet