Pour configurer rapidement un domaine personnalisé pour Jitsi Meet Docker, il suffit de faire pointer un nom d'hôte DNS vers l'hôte Docker, de définir PUBLIC_URLl'URL HTTPS finale, de configurer un certificat TLS de confiance pour ce même nom d'hôte et de vérifier que les flux multimédias WebRTC restent accessibles à Jitsi Videobridge. Pour une installation directement accessible depuis Internet, la configuration Docker officielle prend en charge l'automatisation intégrée des certificats via les options `--cert` ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN`--cert` et `--cert` LETSENCRYPT_EMAIL.
Ce guide utilise meet.example.comcomme exemple concret le projet standard docker-jitsi-meet . Remplacez le nom d'hôte, l'adresse e-mail et l'adresse IP (utilisée uniquement dans la documentation) par vos propres valeurs. La configuration décrite ici a été vérifiée par rapport au manuel officiel Jitsi Docker et à la version actuelle du projet env.examplele 7 octobre 2026.
Un domaine personnalisé fonctionne de manière optimale lorsque le nom d'hôte est défini avant la demande de certificat. Par exemple, si les utilisateurs doivent accéder à ` http://localhost https://meet.example.com:8080`, le DNS, PUBLIC_URLle certificat TLS et le certificat lui-même doivent tous utiliser `http:// localhost:8080`. meet.example.comMélanger les noms d'hôte jitsi.example.comà un endroit et meet.example.comà un autre est une cause fréquente d'avertissements de certificat ou de redirections vers un hôte incorrect.
docker-jitsi-meetrépertoire existant et son .envfichier.Le manuel officiel de Jitsi Docker indique que PUBLIC_URLle nom de domaine réel doit être spécifié pour un déploiement en production. Il mentionne également les ports externes principaux 80/TCP, 443/TCP et 10000/UDP pour une configuration directe standard. Consultez le guide d'auto-hébergement de Jitsi Docker .
Créez un enregistrement A pour le nom d'hôte souhaité. Dans cet exemple, meet.example.comil pointe vers l'adresse IPv4 publique du serveur. Si votre serveur dispose d'une connectivité IPv6 stable, vous pouvez également ajouter un enregistrement AAAA pointant vers son adresse IPv6 publique.
Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300Ne copiez pas 203.0.113.10l'illustration pour un déploiement réel ; cette adresse est réservée à la documentation. Si vous utilisez un fournisseur DNS en mode proxy/CDN, commencez par une résolution DNS classique, sauf si vous avez vérifié que le proxy prend en charge le modèle de trafic Jitsi que vous comptez utiliser.
Ouvrez le .envfichier dans le répertoire où vous avez cloné ou extrait l'archive docker-jitsi-meet. Pour un déploiement direct où le conteneur web Jitsi écoutera publiquement sur les ports 80 et 443, les paramètres importants sont :
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=letsencryptPUBLIC_URLCe n'est pas qu'une question d'esthétique. Jitsi l'utilise pour créer une configuration efficace ; par conséquent, le laisser sur localhost ou avec un ancien nom d'hôte peut entraîner des liens brisés et un comportement incohérent. L'exemple de projet actuel indique également que si vous utilisez délibérément un port HTTPS non standard, ce port doit être spécifié PUBLIC_URL.
L'exemple officiel configure actuellement ZeroSSL comme serveur ACME par défaut et autorise l'utilisation LETSENCRYPT_ACME_SERVER="letsencrypt"de Let's Encrypt si vous le souhaitez. Si votre installation actuelle obtient déjà un certificat de confiance, conservez la configuration ACME correspondant à votre environnement de travail plutôt que de changer de fournisseur sans raison valable.
Pour le déploiement Docker exposé directement sur Internet décrit ci-dessus, autorisez les ports TCP 80 et 443, ainsi que le port UDP 10000. Laissez également ouvert votre port de gestion SSH. Sur un hôte Ubuntu utilisant UFW, voici un exemple minimal :
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verboseLes ports web gèrent le site et la vérification du certificat. Le port UDP 10000 est le port média par défaut de Jitsi Videobridge. Une page peut se charger correctement, mais les réunions peuvent échouer ou présenter des coupures audio/vidéo si le port média est bloqué ; par conséquent, la vérification du protocole HTTPS seul est insuffisante.
Si votre hôte se trouve derrière un NAT, consultez également cette information JVB_ADVERTISE_IPS. Le manuel officiel explique que cette variable contrôle l'adresse que Jitsi Videobridge diffuse pour les médias et est requise dans de nombreux déploiements LAN ou NAT. Voici un exemple typique sur Internet :
JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4
Enregistrez .env, puis recréez les conteneurs pour que les modifications d'environnement soient appliquées :
docker compose down
docker compose up -d
docker compose psUne simple reconfiguration restartn'est pas la meilleure solution après la modification des variables d'environnement, car la définition du conteneur existant peut encore contenir l'ancien environnement. Recréer la pile permet de PUBLIC_URLspécifier explicitement les nouvelles valeurs de port et les nouveaux paramètres de certificat.
Si vous partez d'une copie vierge du projet, suivez d'abord la procédure de démarrage rapide officielle, notamment la génération des mots de passe requis et la création des répertoires de configuration. Les versions récentes des conteneurs Jitsi exécutent les services en tant qu'utilisateur non privilégié et nécessitent un espace de stockage accessible en écriture ainsi que des répertoires temporaires. Par conséquent, pour une installation entièrement nouvelle, il est recommandé de suivre les commandes de répertoire décrites dans le manuel actuel plutôt que celles d'un ancien tutoriel tiers.
Une fois la propagation DNS effectuée, vérifiez que le nom d'hôte correspond bien à l'adresse publique attendue :
dig +short meet.example.comTestez ensuite le point de terminaison HTTPS :
curl -I https://meet.example.comUne réponse positive prouve que le DNS, le port TCP 443 et le service web fonctionnent correctement ensemble. Elle ne prouve cependant pas encore le bon fonctionnement des communications multipartites ; il s’agit donc d’une étape intermédiaire et non d’une finalité.
Si digla réponse renvoie une ancienne adresse, attendez la fin du délai de résolution DNS (TTL) ou corrigez l'enregistrement. Si le DNS est correct mais curlexpire, vérifiez les groupes de sécurité du cloud, le pare-feu de l'hôte, les règles du routeur/NAT et assurez-vous qu'aucun autre service n'utilise déjà le port 443.
Si le navigateur affiche toujours un avertissement de certificat, consultez les journaux du conteneur Web au lieu de supprimer la configuration et de demander un autre certificat à plusieurs reprises :
docker compose logs --tail=200 webRecherchez les erreurs de validation ACME, les échecs de liaison de port ou une incohérence de nom d'hôte. Le manuel Jitsi met en garde contre les limitations de débit des autorités de certification et recommande de conserver le stockage de configuration contenant les certificats émis. Lors de tests de configuration répétés, l'environnement de test peut s'avérer utile, mais après un passage en production, le manuel indique qu'il peut être nécessaire de supprimer les anciens certificats de test du stockage web avant de demander un certificat de production.
Si vous possédez déjà un certificat de confiance provenant d'une autre source, Jitsi prend également en charge l'intégration d'une chaîne complète et d'une clé privée existantes dans le service web, plutôt que d'activer le flux ACME intégré. Suivez l'exemple d'intégration de certificat dans la section officielle relative aux certificats existants .
Accédez https://meet.example.comà votre compte via un navigateur moderne. La page d'accueil de Jitsi devrait s'afficher sous le nom d'hôte choisi, avec un certificat TLS valide. Créez une salle de test avec un nom temporaire.
Utilisez HTTPS pour les réunions en présentiel. Le guide Docker officiel précise que l'accès HTTP direct peut entraîner le dysfonctionnement des API WebRTC du navigateur, telles que l'accès au microphone et à la caméra. HTTPS fait donc partie intégrante de la configuration fonctionnelle et n'est pas qu'une simple mesure de sécurité.
Si possible, rejoignez la même salle depuis deux appareils ou réseaux différents. Assurez-vous que chaque participant peut envoyer et recevoir de l'audio et de la vidéo. Un test avec deux navigateurs est important, car une installation peut afficher correctement le site web même si l'adresse Videobridge ou le chemin UDP est incorrect.
Pour les installations derrière un NAT, un symptôme fréquent est que la première connexion semble fonctionner, mais que la diffusion multimédia échoue lorsque d'autres participants se connectent. Dans ce cas, vérifiez la configuration JVB_ADVERTISE_IPS, le mappage NAT public et le port UDP 10000. Le manuel Jitsi précise que l'adresse multimédia Videobridge reste valide même lorsque le trafic HTTP est géré par un proxy inverse.
La configuration directe décrite ci-dessus convient lorsque le conteneur web Jitsi peut gérer les ports publics 80 et 443. Si le même serveur exécute déjà Nginx, Apache, Caddy, Traefik ou un autre proxy sur ces ports, n'essayez pas d'y lier Jitsi simultanément.
Pour un proxy inverse hébergé sur le même serveur, le guide Docker officiel de Jitsi recommande de désactiver HTTPS à l'intérieur du conteneur Jitsi, d'éviter l'exposition publique de ses ports web internes et de rediriger les requêtes vers l'entrée HTTP du conteneur. Le proxy doit également prendre en charge le transfert WebSocket /xmpp-websocket. Un environnement Jitsi typique est le suivant :
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.comEnsuite, désactivez le certificat de confiance au niveau de votre proxy inverse. Cette solution est plus appropriée lorsqu'un seul proxy gère les certificats de plusieurs applications. Il n'est pas nécessaire de modifier l'URL visible de l'extérieurPUBLIC_URL ; les utilisateurs doivent toujours voir le domaine HTTPS final.
Recréez les conteneurs avec docker compose downsuivi de docker compose up -d. Vérifiez également que vous avez modifié le .envfichier utilisé par le projet Compose que vous êtes en train de démarrer.
Vérifiez que les enregistrements DNS A/AAAA pointent bien vers le serveur recevant la requête et que le port public 80 est accessible via le flux de certificat direct intégré. docker compose logs webAvant d'effectuer une nouvelle requête, vérifiez l'erreur ACME exacte.
Vérifiez le port UDP 10000 et, pour les déploiements NAT, configurez-le correctement JVB_ADVERTISE_IPS. N'oubliez pas que le proxy inverse gère le trafic web ; il ne remplace pas le chemin média de Videobridge.
Vérifiez la chaîne de certificats. Le manuel Docker de Jitsi indique que les applications mobiles ne fonctionnent pas avec le certificat auto-signé par défaut. Utilisez un certificat publiquement reconnu ou une infrastructure où l'application reçoit une chaîne de certificats de confiance.
meet.example.comse résout à l'adresse publique prévue.PUBLIC_URL=https://meet.example.comL'URL du navigateur correspond exactement.meet.example.com.JVB_ADVERTISE_IPSest correct lorsque le serveur se trouve derrière un NAT ou nécessite des adresses explicitement annoncées.docker compose psaffiche les conteneurs requis en cours d'exécution.Une fois ces vérifications effectuées, le domaine personnalisé ne se contente pas de pointer vers Jitsi ; il est configuré pour les éléments qui comptent réellement lors d’une réunion : HTTPS, signalisation et transport multimédia.
Diagnostiquez les pics d'utilisation du processeur du navigateur Jitsi Meet et réduisez la charge client en vérifiant les vignettes vidéo, les effets de la caméra, les graphismes du navigateur et les paramètres de l'hôte.
Suivez l'état de santé, la charge des conférences et le trafic de Jitsi Videobridge grâce à son point de terminaison Prometheus intégré, puis explorez et représentez graphiquement les données dans Grafana.
Configurez un domaine personnalisé pour Jitsi Meet Docker avec DNS, PUBLIC_URL, HTTPS, Let's Encrypt, ports de pare-feu, paramètres NAT et vérification de bout en bout.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Découvrez comment diagnostiquer et corriger l'avertissement de configuration PHP OPcache de Nextcloud en vérifiant le SAPI PHP actif, les limites de dimensionnement, les commentaires et les paramètres de revalidation.
Résolvez les problèmes de migration de la base de données Kopano après une mise à niveau de MySQL ou MariaDB en vérifiant les sauvegardes, les versions du serveur, les modes SQL, le jeu de caractères, l'état du schéma et les journaux.
Connectez Nextcloud à LDAP ou Active Directory avec un transport sécurisé, des filtres d'utilisateurs et de groupes, des attributs de connexion et un déploiement testé.
Corriger les notifications Element Android sur les téléphones dé-Google en configurant UnifiedPush, les autorisations Android, les paramètres de la batterie et des tests de vérification fiables.
Pour supprimer l'avertissement relatif aux index de base de données manquants de Nextcloud, utilisez la commande officielle occ. Commencez par sauvegarder vos données, prévisualisez les modifications, puis lancez la réparation et vérifiez le résultat.
Configurez l'authentification unique Keycloak pour Element Web en connectant OIDC à Synapse, en définissant l'URL de rappel exacte, en mappant les revendications de l'utilisateur et en testant la déconnexion.
