Como configurar um nome de domínio personalizado para o Jitsi Meet no Docker

O caminho mais curto para um domínio personalizado para o Jitsi Meet Docker é apontar um nome de host DNS para o host Docker, definir PUBLIC_URLo URL HTTPS final, configurar o TLS confiável para esse mesmo nome de host e garantir que a mídia WebRTC ainda possa alcançar o Jitsi Videobridge. Para uma instalação diretamente voltada para a Internet, a configuração oficial do Docker oferece suporte à automação de certificados integrada por meio de `--configure` ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN`--configure` e `--configure` LETSENCRYPT_EMAIL.

Este guia usa meet.example.comcomo exemplo concreto e pressupõe o projeto padrão docker-jitsi-meet . Substitua o nome do host, o endereço de e-mail e o endereço IP (somente para documentação) de exemplo pelos seus próprios valores. A configuração descrita aqui foi verificada em relação ao manual oficial do Jitsi Docker e à versão atual do projeto env.exampleem 7 de outubro de 2026.

O que você precisa antes de alterar o domínio.

Um domínio personalizado funciona melhor quando o nome do host é definido antes de solicitar um certificado. Por exemplo, se os usuários devem acessar `example.com` https://meet.example.com, o DNS, PUBLIC_URLo certificado TLS e o próprio domínio devem usar ` example.com` meet.example.com. Misturar `example.com` jitsi.example.comem um lugar e ` meet.example.comexample.com` em outro é uma causa comum de avisos de certificado ou redirecionamentos para o host errado.

• Um domínio que você controla.
• Um servidor com Docker Engine e Docker Compose.
• Um endereço IP público ou um proxy reverso que já possua as portas 80 e 443.
• Acesso via firewall para as portas web e tráfego de mídia do Jitsi.
• O docker-jitsi-meetdiretório existente e seu .envarquivo.

O manual oficial do Jitsi Docker afirma que PUBLIC_URLo domínio deve ser configurado para um ambiente de produção. Ele também documenta as portas 80/TCP, 443/TCP e 10000/UDP como as principais portas externas para a configuração direta padrão. Consulte o guia de auto-hospedagem do Jitsi Docker .

Passo 1: Aponte o nome de host personalizado para o servidor Jitsi.

Crie um registro A para o nome de host que você deseja usar. Neste exemplo, meet.example.comele aponta para o endereço IPv4 público do servidor. Se o seu servidor tiver conectividade IPv6 estável, você também pode adicionar um registro AAAA que aponte para o endereço IPv6 público dele.

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

Não copie 203.0.113.10a ilustração para uma implementação real; esse endereço é reservado para documentação. Se você usa um provedor de DNS com modo proxy/CDN, comece com a resolução DNS comum, a menos que tenha confirmado que o proxy suporta o padrão de tráfego do Jitsi que você pretende usar.

Etapa 2: Defina os valores de PUBLIC_URL e HTTPS no arquivo .env.

Abra o .envarquivo no diretório onde você clonou ou extraiu o Jitsi docker-jitsi-meet. Para uma implantação direta em que o contêiner web do Jitsi ficará escutando publicamente nas portas 80 e 443, as configurações importantes são:

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_URLNão é apenas uma questão estética. O Jitsi usa isso ao construir uma configuração eficaz, portanto, deixá-lo em localhost ou em um nome de host antigo pode gerar links quebrados e comportamento inconsistente. O exemplo de projeto atual também observa que, se você usar deliberadamente uma porta HTTPS não padrão, essa porta deve estar em PUBLIC_URL.

O exemplo oficial identifica atualmente o ZeroSSL como o servidor ACME padrão e permite o uso LETSENCRYPT_ACME_SERVER="letsencrypt"do Let's Encrypt quando você o deseja especificamente. Se a sua instalação atual já obtém um certificado confiável com sucesso, mantenha a configuração ACME que corresponde ao seu ambiente de trabalho, em vez de trocar de provedor sem um motivo.

Passo 3: Abra as portas de firewall necessárias.

Para a implantação do Docker com acesso direto à Internet descrita acima, permita as portas 80/TCP, 443/TCP e 10000/UDP. Mantenha também a porta de gerenciamento SSH aberta. Em um host Ubuntu usando UFW, um exemplo mínimo é:

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

As portas web servem o site e o desafio de certificado. UDP 10000 é a porta de mídia padrão do Jitsi Videobridge. Uma página pode carregar perfeitamente, mas as reuniões podem falhar ou perder áudio/vídeo se a porta de mídia estiver bloqueada; portanto, verificar apenas o HTTPS não é suficiente.

Se o seu host estiver atrás de um NAT, consulte também JVB_ADVERTISE_IPSa variável `<nome_da_variável>`. O manual oficial explica que essa variável controla o endereço que o Jitsi Videobridge anuncia para a mídia e é necessária em muitas implantações de LAN ou NAT. Um exemplo típico na Internet pública é:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Etapa 4: Reinicie o Docker com o novo domínio.

Salve .enve, em seguida, recrie os contêineres para que as alterações de ambiente sejam aplicadas:

docker compose down
docker compose up -d
docker compose ps

Uma abordagem simples restartnão é a melhor escolha após alterar variáveis ​​de ambiente, pois a definição do contêiner existente ainda pode conter o ambiente anterior. Recriar a pilha torna PUBLIC_URLexplícitos os novos valores de porta e configurações de certificado.

Se você estiver começando com uma nova cópia do projeto, siga primeiro os passos oficiais de início rápido, incluindo a geração das senhas necessárias e a criação dos diretórios de configuração. As versões recentes do contêiner Jitsi executam os serviços como um usuário sem privilégios e exigem armazenamento gravável e diretórios temporários; portanto, uma instalação completamente nova deve seguir os comandos de diretório do manual atual, em vez de um tutorial antigo de terceiros.

Etapa 5: Confirme o DNS e o HTTPS de fora do servidor.

Após a propagação do DNS, verifique se o nome do host é resolvido para o endereço público esperado:

dig +short meet.example.com

Em seguida, teste o endpoint HTTPS:

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

Uma resposta bem-sucedida comprova que o DNS, a porta TCP 443 e o serviço web estão funcionando em conjunto. Isso ainda não comprova o funcionamento da mídia multipartidária, portanto, trata-se de uma verificação intermediária, e não da conclusão definitiva.

Se digretornar um endereço antigo, aguarde o TTL do DNS ou corrija o registro. Se o DNS estiver correto, mas curlexpirar o tempo limite, verifique os grupos de segurança na nuvem, o firewall do host, as regras do roteador/NAT e se outro serviço já está utilizando a porta 443.

Etapa 6: Verificar a emissão do certificado e os registros da web

Se o navegador ainda exibir um aviso de certificado, verifique os logs do contêiner web em vez de excluir repetidamente a configuração e solicitar outro certificado:

docker compose logs --tail=200 web

Procure por erros de validação ACME, falhas na vinculação de portas ou incompatibilidade de nomes de host. O manual do Jitsi alerta sobre os limites de taxa da autoridade de certificação e recomenda preservar o armazenamento de configuração que contém os certificados emitidos. Durante experimentos de configuração repetidos, o ambiente de teste pode ser útil, mas após a mudança para um ambiente de produção, o manual observa que os certificados de teste antigos podem precisar ser removidos do armazenamento da web antes de solicitar um certificado de produção.

Se você já possui um certificado confiável de outra fonte, o Jitsi também oferece suporte à montagem de uma cadeia completa de certificados e chave privada existentes no serviço web, em vez de habilitar o fluxo ACME integrado. Consulte o exemplo de montagem de certificado na seção oficial sobre certificados existentes .

Passo 7: Abra o domínio personalizado em um navegador.

Acesse https://meet.example.comem um navegador moderno. Você deverá ver a página inicial do Jitsi com o nome de host escolhido e um indicador TLS válido. Crie uma sala de teste com um nome temporário.

Use HTTPS para reuniões reais. O guia oficial do Docker alerta especificamente que o acesso HTTP direto pode causar falhas nas APIs WebRTC do navegador, como o acesso ao microfone e à câmera. Portanto, o HTTPS faz parte da configuração funcional, e não é apenas um selo de segurança.

Passo 8: Teste uma chamada real, não apenas a página inicial.

Se possível, tente entrar na mesma sala a partir de dois dispositivos ou redes diferentes. Confirme se cada participante consegue enviar e receber áudio e vídeo. É importante testar com dois navegadores, pois a instalação pode exibir o site corretamente mesmo que o endereço do Videobridge ou o caminho UDP ainda estejam incorretos.

Para instalações atrás de um NAT, um sintoma comum é que a primeira conexão parece normal, mas a mídia falha à medida que mais participantes se conectam. Nesse caso, verifique novamente JVB_ADVERTISE_IPSo mapeamento NAT público e a porta UDP 10000. O manual do Jitsi observa explicitamente que o endereço de mídia do Videobridge permanece relevante mesmo quando o tráfego HTTP é tratado por um proxy reverso.

Quando você deve usar um proxy reverso em vez de um proxy reverso.

A configuração direta acima é apropriada quando o contêiner web Jitsi pode utilizar as portas públicas 80 e 443. Se o mesmo servidor já estiver executando Nginx, Apache, Caddy, Traefik ou outro proxy nessas portas, não tente vincular o Jitsi a eles simultaneamente.

Para um proxy reverso no mesmo host, o guia oficial do Jitsi para Docker recomenda desabilitar o HTTPS dentro do contêiner do Jitsi, evitar a exposição pública de suas portas web internas e encaminhar as requisições para o ingress HTTP do contêiner. O proxy também deve suportar o encaminhamento de WebSocket /xmpp-websocket. Um ambiente típico do lado do Jitsi é:

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

Em seguida, encerre o certificado confiável no seu proxy reverso. Essa é a melhor opção quando um único proxy gerencia certificados para vários aplicativos. Não há motivo para alterar o domínio visível externamente PUBLIC_URL; os usuários ainda devem ver o domínio HTTPS final.

Solução de problemas de falhas em domínios personalizados

O domínio antigo ainda aparece após editar o arquivo .env.

Recrie os contêineres com ` docker compose downcomposer update` seguido de `composer update` docker compose up -d. Verifique também se você editou o .envarquivo usado pelo projeto Compose que você está iniciando.

A validação do certificado HTTPS falhou.

Confirme se os registros DNS A/AAAA apontam para o servidor que recebe o desafio e se a porta pública 80 está acessível ao usar o fluxo de certificado direto integrado. Verifique docker compose logs webo erro ACME exato antes de fazer outra solicitação.

A página carrega, mas os participantes não têm áudio nem vídeo.

Verifique a porta UDP 10000 e, para implantações NAT, defina o valor correto JVB_ADVERTISE_IPS. Lembre-se de que o proxy reverso lida com o tráfego da web; ele não substitui o caminho de mídia do Videobridge.

O navegador funciona, mas o aplicativo móvel rejeita o servidor.

Verifique a cadeia de certificados. O manual do Jitsi Docker observa que os aplicativos móveis não funcionam com o certificado autoassinado padrão. Use um certificado publicamente confiável ou uma arquitetura de infraestrutura em que o aplicativo receba uma cadeia de certificados confiável.

Lista de verificação final

• meet.example.comresolve-se com o endereço público pretendido.
• PUBLIC_URL=https://meet.example.comcorresponde exatamente ao URL do navegador.
• O certificado TLS é confiável e abrange meet.example.com.
• As portas 80/TCP e 443/TCP estão acessíveis para configuração direta.
• A conexão UDP 10000 chega ao host do Jitsi Videobridge.
• JVB_ADVERTISE_IPSEstá correto quando o servidor está atrás de um NAT ou precisa de endereços anunciados explicitamente.
• docker compose psMostra os contêineres necessários em execução.
• Um teste com dois participantes enviou áudio e vídeo com sucesso.

Após a aprovação nessas verificações, o domínio personalizado não apenas aponta para o Jitsi, mas também é configurado para as partes que realmente importam em uma reunião real: HTTPS, sinalização e transporte de mídia.

Referências oficiais

• Guia de auto-hospedagem do Jitsi Meet — Docker
• docker-jitsi-meet env.example
• Repositório oficial docker-jitsi-meet