So konfigurieren Sie einen benutzerdefinierten Domänennamen für Jitsi Meet Docker

Der kürzeste Weg zu einer benutzerdefinierten Domain für Jitsi Meet Docker besteht darin, einen DNS-Hostnamen auf den Docker-Host zu verweisen, PUBLIC_URLdie endgültige HTTPS-URL festzulegen, vertrauenswürdiges TLS für denselben Hostnamen zu konfigurieren und sicherzustellen, dass WebRTC-Medien weiterhin Jitsi Videobridge erreichen können. Für eine direkte Internetinstallation unterstützt das offizielle Docker-Setup die integrierte Zertifikatsautomatisierung über [hier fehlende Information ENABLE_LETSENCRYPTeinfügen LETSENCRYPT_DOMAIN] LETSENCRYPT_EMAIL.

Diese Anleitung verwendet das Standardprojekt docker-jitsi-meetmeet.example.com als konkretes Beispiel . Ersetzen Sie den Beispiel-Hostnamen, die Beispiel-E-Mail-Adresse und die IP-Adresse für die Dokumentation durch Ihre eigenen Werte. Die hier beschriebene Konfiguration wurde am 7. Oktober 2026 anhand des offiziellen Jitsi-Docker-Handbuchs und des aktuellen Projektstandes überprüft .env.example

Was Sie vor dem Ändern der Domäne benötigen

Eine benutzerdefinierte Domain funktioniert am besten, wenn der Hostname vor der Zertifikatsanforderung festgelegt wird. Wenn Benutzer beispielsweise öffnen sollen https://meet.example.com, sollten DNS, PUBLIC_URLund das TLS-Zertifikat alle verwenden meet.example.com. Eine Vermischung jitsi.example.comvon und meet.example.comist eine häufige Ursache für Zertifikatswarnungen oder Weiterleitungen zum falschen Host.

• Eine Domäne, die Sie kontrollieren.
• Ein Server mit Docker Engine und Docker Compose.
• Eine öffentliche IP-Adresse oder ein Reverse-Proxy, der bereits die Ports 80 und 443 belegt.
• Firewall-Zugriff für die Web-Ports und den Jitsi-Medienverkehr.
• Das bestehende docker-jitsi-meetVerzeichnis und seine .envDatei.

Das offizielle Jitsi-Docker-Handbuch gibt an, dass PUBLIC_URLfür eine Produktionsumgebung die tatsächliche Domain angegeben werden muss. Es nennt außerdem 80/TCP, 443/TCP und 10000/UDP als die wichtigsten externen Ports für die Standard-Direktkonfiguration. Siehe den Jitsi-Docker-Leitfaden zum Selbsthosting .

Schritt 1: Den benutzerdefinierten Hostnamen auf den Jitsi-Server verweisen.

Erstellen Sie einen A-Eintrag für den gewünschten Hostnamen. In diesem Beispiel meet.example.comverweist er auf die öffentliche IPv4-Adresse des Servers. Verfügt Ihr Server über eine stabile IPv6-Verbindung, können Sie zusätzlich einen AAAA-Eintrag hinzufügen, der auf seine öffentliche IPv6-Adresse verweist.

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

Kopieren Sie 203.0.113.10die Abbildung nicht in eine reale Umgebung; diese Adresse ist für die Dokumentation reserviert. Wenn Sie einen DNS-Anbieter mit Proxy-/CDN-Modus verwenden, beginnen Sie mit der reinen DNS-Auflösung, es sei denn, Sie haben bestätigt, dass der Proxy das von Ihnen beabsichtigte Jitsi-Datenverkehrsmuster unterstützt.

Schritt 2: Legen Sie die Werte für PUBLIC_URL und HTTPS in der .env-Datei fest.

Öffnen Sie die .envDatei in dem Verzeichnis, in dem Sie sie geklont oder extrahiert haben docker-jitsi-meet. Für eine direkte Bereitstellung, bei der der Jitsi-Webcontainer öffentlich auf den Ports 80 und 443 lauscht, sind folgende Einstellungen wichtig:

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_URList nicht nur kosmetischer Natur. Jitsi verwendet es zur Erstellung einer effektiven Konfiguration. Daher kann die Belassung auf localhost oder einem alten Hostnamen zu defekten Links und inkonsistentem Verhalten führen. Das aktuelle Projektbeispiel weist außerdem darauf hin, dass ein bewusst verwendeter, nicht standardmäßiger HTTPS-Port in die Konfigurationsdatei gehört PUBLIC_URL.

Das offizielle Beispiel verwendet derzeit ZeroSSL als Standard-ACME-Server und ermöglicht die Nutzung LETSENCRYPT_ACME_SERVER="letsencrypt"von Let's Encrypt, wenn Sie dies explizit wünschen. Falls Ihre bestehende Installation bereits erfolgreich ein vertrauenswürdiges Zertifikat bezieht, behalten Sie die für Ihre Arbeitsumgebung passende ACME-Einstellung bei, anstatt den Anbieter ohne triftigen Grund zu wechseln.

Schritt 3: Öffnen Sie die erforderlichen Firewall-Ports

Für die oben beschriebene, direkt mit dem Internet verbundene Docker-Bereitstellung müssen die Ports 80/TCP, 443/TCP und 10000/UDP freigegeben werden. Der SSH-Management-Port muss ebenfalls geöffnet bleiben. Ein Minimalbeispiel für einen Ubuntu-Host mit UFW:

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

Die Web-Ports dienen der Website- und Zertifikatsanforderung. UDP 10000 ist der Standard-Medienport von Jitsi Videobridge. Eine Seite kann einwandfrei geladen werden, während Meetings dennoch fehlschlagen oder Audio-/Videoverluste auftreten, wenn der Medienport blockiert ist. Daher reicht die alleinige Prüfung von HTTPS nicht aus.

Wenn sich Ihr Host hinter einem NAT-Router befindet, überprüfen Sie bitte auch die entsprechende Einstellung JVB_ADVERTISE_IPS. Das offizielle Handbuch erklärt, dass diese Variable die Adresse steuert, die Jitsi Videobridge für Mediendateien angibt, und in vielen LAN- oder NAT-Umgebungen erforderlich ist. Ein typisches Beispiel aus dem öffentlichen Internet ist:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Schritt 4: Starten Sie den Docker-Stack mit der neuen Domäne neu.

Speichern Sie .envdie Container und erstellen Sie sie anschließend neu, damit die Umgebungsänderungen angewendet werden:

docker compose down
docker compose up -d
docker compose ps

Eine einfache restartLösung ist nach dem Ändern von Umgebungsvariablen nicht optimal, da die bestehende Containerdefinition möglicherweise noch die vorherige Umgebung enthält. Durch das Neuerstellen des Stacks werden die neuen PUBLIC_URLPortwerte und Zertifikatseinstellungen explizit angegeben.

Wenn Sie mit einer neuen Kopie des Projekts beginnen, befolgen Sie zunächst die offiziellen Schnellstart-Schritte, einschließlich der Generierung der erforderlichen Passwörter und der Erstellung der Konfigurationsverzeichnisse. Neuere Jitsi-Containerversionen führen Dienste als Benutzer ohne Administratorrechte aus und benötigen beschreibbaren Speicher sowie temporäre Verzeichnisse. Daher sollte eine Neuinstallation den Verzeichnisbefehlen im aktuellen Handbuch folgen und nicht einer älteren Anleitung eines Drittanbieters.

Schritt 5: DNS und HTTPS von außerhalb des Servers überprüfen.

Sobald die DNS-Änderungen übernommen wurden, überprüfen Sie, ob der Hostname zur erwarteten öffentlichen Adresse aufgelöst wird:

dig +short meet.example.com

Testen Sie anschließend den HTTPS-Endpunkt:

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

Eine erfolgreiche Antwort beweist, dass DNS, TCP 443 und der Webdienst zusammenarbeiten. Sie beweist jedoch noch nicht, dass die Mehrparteienkommunikation funktioniert; es handelt sich also um eine Zwischenprüfung und nicht um den endgültigen Abschluss.

Wird digeine alte Adresse zurückgegeben, warten Sie die DNS-TTL ab oder korrigieren Sie den Eintrag. Falls die DNS-Anfrage korrekt ist, aber curlein Timeout auftritt, überprüfen Sie die Cloud-Sicherheitsgruppen, die Host-Firewall, die Router-/NAT-Regeln und ob Port 443 bereits von einem anderen Dienst belegt ist.

Schritt 6: Zertifikatsausstellung und Webprotokolle prüfen

Falls der Browser weiterhin eine Zertifikatswarnung anzeigt, überprüfen Sie die Webcontainer-Protokolle, anstatt die Konfiguration wiederholt zu löschen und ein neues Zertifikat anzufordern:

docker compose logs --tail=200 web

Achten Sie auf ACME-Validierungsfehler, Portbindungsfehler oder Hostnamenabweichungen. Das Jitsi-Handbuch weist auf die Ratenbegrenzungen der Zertifizierungsstellen hin und empfiehlt, den Konfigurationsspeicher mit den ausgestellten Zertifikaten zu sichern. Bei wiederholten Einrichtungsversuchen kann eine Staging-Umgebung hilfreich sein. Nach dem Wechsel von der Staging-Umgebung muss laut Handbuch jedoch das alte Staging-Zertifikatmaterial aus dem Webspeicher gelöscht werden, bevor ein Produktionszertifikat angefordert wird.

Wenn Sie bereits über ein vertrauenswürdiges Zertifikat einer anderen Quelle verfügen, unterstützt Jitsi auch das Einbinden einer bestehenden vollständigen Zertifikatskette und des zugehörigen privaten Schlüssels in den Webdienst, anstatt den integrierten ACME-Ablauf zu aktivieren. Folgen Sie dem Beispiel zum Einbinden von Zertifikaten im offiziellen Abschnitt zu bestehenden Zertifikaten .

Schritt 7: Öffnen Sie die benutzerdefinierte Domäne in einem Browser

Öffnen Sie die Seite https://meet.example.comin einem modernen Browser. Sie sollten die Jitsi-Startseite unter Ihrem gewählten Hostnamen mit einem gültigen TLS-Indikator sehen. Erstellen Sie einen Testraum mit einem temporären Namen.

Verwenden Sie HTTPS für echte Meetings. Die offizielle Docker-Anleitung warnt ausdrücklich davor, dass direkter HTTP-Zugriff dazu führen kann, dass Browser-WebRTC-APIs wie der Zugriff auf Mikrofon und Kamera nicht mehr funktionieren. HTTPS ist daher Teil der funktionalen Konfiguration und nicht nur ein Sicherheitsmerkmal.

Schritt 8: Testen Sie einen echten Anruf, nicht nur die Startseite.

Verbinden Sie sich nach Möglichkeit von zwei verschiedenen Geräten oder Netzwerken aus mit demselben virtuellen Raum. Stellen Sie sicher, dass alle Teilnehmer Audio und Video senden und empfangen können. Ein Test mit zwei Browsern ist wichtig, da die Website auch dann korrekt angezeigt werden kann, wenn die Videobridge-Adresse oder der UDP-Pfad noch nicht korrekt ist.

Bei Installationen hinter einem NAT-Router tritt häufig auf, dass die erste Verbindung normal erscheint, die Medienübertragung jedoch abbricht, sobald weitere Teilnehmer beitreten. Überprüfen Sie in diesem Fall JVB_ADVERTISE_IPSdie öffentliche NAT-Zuordnung und UDP 10000. Das Jitsi-Handbuch weist ausdrücklich darauf hin, dass die Videobridge-Medienadresse auch dann relevant bleibt, wenn der HTTP-Verkehr über einen Reverse-Proxy abgewickelt wird.

Wann Sie stattdessen einen Reverse-Proxy verwenden sollten

Die oben beschriebene direkte Konfiguration ist geeignet, wenn der Jitsi-Webcontainer die öffentlichen Ports 80 und 443 belegen kann. Falls auf demselben Server bereits Nginx, Apache, Caddy, Traefik oder ein anderer Proxy auf diesen Ports läuft, versuchen Sie nicht, Jitsi gleichzeitig daran zu binden.

Für einen Reverse-Proxy auf demselben Host empfiehlt die offizielle Jitsi-Docker-Anleitung, HTTPS innerhalb des Jitsi-Containers zu deaktivieren, die internen Webports nicht öffentlich zugänglich zu machen und Anfragen an den HTTP-Ingress des Containers weiterzuleiten. Der Proxy muss außerdem WebSocket-Weiterleitung unterstützen /xmpp-websocket. Eine typische Jitsi-Umgebung sieht folgendermaßen aus:

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

Anschließend wird das vertrauenswürdige Zertifikat auf Ihrem Reverse-Proxy deaktiviert. Dies ist die bessere Lösung, wenn ein Proxy Zertifikate für mehrere Anwendungen verwaltet. Die extern sichtbare Domain muss dadurch nicht geändert werden PUBLIC_URL; Benutzer sollten weiterhin die endgültige HTTPS-Domain sehen.

Fehlerbehebung bei benutzerdefinierten Domänen

Die alte Domain wird auch nach der Bearbeitung der .env-Datei weiterhin angezeigt.

Erstellen Sie die Container mit docker compose downdem Befehl `<containers>` neu docker compose up -d. Überprüfen Sie außerdem, ob Sie die .envDatei bearbeitet haben, die vom Compose-Projekt verwendet wird, das Sie gerade starten.

HTTPS-Zertifikatvalidierung schlägt fehl

Prüfen Sie, ob die DNS-A/AAAA-Einträge auf den Server verweisen, der die Herausforderung empfängt, und ob der öffentliche Port 80 über den integrierten direkten Zertifikatsfluss erreichbar ist. Prüfen Sie docker compose logs webdie genaue ACME-Fehlermeldung, bevor Sie eine weitere Anfrage senden.

Die Seite wird geladen, aber die Teilnehmer haben weder Ton noch Video.

Prüfen Sie UDP 10000 und konfigurieren Sie bei NAT-Bereitstellungen den korrekten Wert JVB_ADVERTISE_IPS. Beachten Sie, dass der Reverse-Proxy den Webverkehr verarbeitet; er ersetzt nicht den Videobridge-Medienpfad.

Der Browser funktioniert, aber die mobile App verweigert die Verbindung zum Server.

Überprüfen Sie die Zertifikatskette. Im Jitsi Docker-Handbuch wird darauf hingewiesen, dass die mobilen Apps nicht mit dem standardmäßigen selbstsignierten Zertifikat funktionieren. Verwenden Sie ein öffentlich vertrauenswürdiges Zertifikat oder eine Infrastruktur, in der die App eine vertrauenswürdige Zertifikatskette empfängt.

Checkliste zur abschließenden Überprüfung

• meet.example.comwird an die beabsichtigte öffentliche Adresse weitergeleitet.
• PUBLIC_URL=https://meet.example.comentspricht exakt der Browser-URL.
• Das TLS-Zertifikat ist vertrauenswürdig und bietet umfassenden Schutz meet.example.com.
• Für die direkte Einrichtung sind die Ports 80/TCP und 443/TCP erreichbar.
• UDP 10000 erreicht den Jitsi Videobridge-Host.
• JVB_ADVERTISE_IPSist korrekt, wenn sich der Server hinter einem NAT befindet oder explizit angekündigte Adressen benötigt.
• docker compose pszeigt die benötigten, laufenden Container an.
• Bei einem Test mit zwei Teilnehmern wurden Audio und Video erfolgreich übertragen.

Sobald diese Prüfungen erfolgreich abgeschlossen sind, verweist die benutzerdefinierte Domäne nicht nur auf Jitsi – sie ist auch für die Teile konfiguriert, die in einem realen Meeting tatsächlich wichtig sind: HTTPS, Signalisierung und Medientransport.

Offizielle Referenzen

• Jitsi Meet Self-Hosting-Leitfaden — Docker
• docker-jitsi-meet env.example
• Offizielles Docker-Jitsi-Meet-Repository