Hoe configureer je een aangepaste domeinnaam voor Jitsi Meet Docker?

De kortste weg naar een aangepast domein voor Jitsi Meet Docker is door een DNS-hostnaam naar de Docker-host te laten verwijzen, deze in te stellen PUBLIC_URLop de uiteindelijke HTTPS-URL, vertrouwde TLS voor diezelfde hostnaam te configureren en ervoor te zorgen dat WebRTC-media Jitsi Videobridge nog steeds kunnen bereiken. Voor een directe installatie via internet ondersteunt de officiële Docker-installatie ingebouwde certificaatautomatisering via ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, en LETSENCRYPT_EMAIL.

Deze handleiding gebruikt meet.example.comals concreet voorbeeld het standaard docker-jitsi-meet-project en gaat ervan uit dat het werkt zoals beschreven. Vervang de voorbeeldhostnaam, het e-mailadres en het IP-adres (alleen voor documentatie) door uw eigen waarden. De hier beschreven configuratie is gecontroleerd aan de hand van de officiële Jitsi Docker-handleiding en het huidige project env.exampleop 7 oktober 2026.

Wat je nodig hebt voordat je het domein wijzigt

Een aangepast domein werkt het beste wanneer de hostnaam is vastgesteld voordat u een certificaat aanvraagt. Als gebruikers bijvoorbeeld toegang moeten hebben tot , moeten https://meet.example.comDNS, PUBLIC_URLen het TLS-certificaat allemaal gebruiken meet.example.com. Het combineren van is een veelvoorkomende oorzaak van certificaatwaarschuwingen of omleidingen naar de verkeerde host.jitsi.example.commeet.example.com

• Een domein dat u beheert.
• Een server met Docker Engine en Docker Compose.
• Een openbaar IP-adres, of een reverse proxy die al poorten 80 en 443 in gebruik heeft.
• Firewalltoegang voor de webpoorten en Jitsi-mediaverkeer.
• De bestaande docker-jitsi-meetmap en het bijbehorende .envbestand.

De officiële Jitsi Docker-handleiding vermeldt dat PUBLIC_URLvoor een productie-implementatie het daadwerkelijke domein moet worden ingesteld. Ook worden 80/TCP, 443/TCP en 10000/UDP beschreven als de belangrijkste externe poorten voor de standaard directe configuratie. Zie de Jitsi Docker self-hosting handleiding .

Stap 1: Stel de aangepaste hostnaam in op de Jitsi-server.

Maak een A-record aan voor de hostnaam die u wilt gebruiken. In dit voorbeeld meet.example.comverwijst deze naar het openbare IPv4-adres van de server. Als uw server een stabiele IPv6-verbinding heeft, kunt u ook een AAAA-record toevoegen dat verwijst naar het openbare IPv6-adres.

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

Kopieer de afbeelding niet 203.0.113.10rechtstreeks naar een daadwerkelijke implementatie; dat adres is gereserveerd voor documentatie. Als u een DNS-provider met een proxy-/CDN-modus gebruikt, begin dan met gewone DNS-resolutie, tenzij u hebt bevestigd dat de proxy het Jitsi-verkeerspatroon ondersteunt dat u wilt gebruiken.

Stap 2: Stel de waarden voor PUBLIC_URL en HTTPS in het .env-bestand in.

Open het .envbestand in de map waar u het bestand hebt gekloond of uitgepakt docker-jitsi-meet. Voor een directe implementatie waarbij de Jitsi-webcontainer publiekelijk luistert op poorten 80 en 443, zijn de belangrijkste instellingen:

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_URLHet is niet alleen cosmetisch. Jitsi gebruikt het bij het opbouwen van een effectieve configuratie, dus als je het op localhost of een oude hostnaam laat staan, kan dit leiden tot kapotte links en inconsistent gedrag. In het huidige projectvoorbeeld wordt ook vermeld dat als je bewust een niet-standaard HTTPS-poort gebruikt, die poort in het bestand thuishoort PUBLIC_URL.

De officiële voorbeeldcode identificeert ZeroSSL momenteel als de standaard ACME-server en staat toe LETSENCRYPT_ACME_SERVER="letsencrypt"dat u specifiek Let's Encrypt gebruikt. Als uw bestaande installatie al succesvol een vertrouwd certificaat verkrijgt, behoud dan de ACME-instelling die overeenkomt met uw werkomgeving in plaats van zonder reden van provider te wisselen.

Stap 3: Open de benodigde firewallpoorten

Voor de hierboven beschreven Docker-implementatie die rechtstreeks met internet verbonden is, moet u poorten 80/TCP, 443/TCP en 10000/UDP openhouden. Houd ook uw SSH-beheerpoort open. Op een Ubuntu-host met UFW ziet een minimaal voorbeeld er als volgt uit:

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

De webpoorten worden gebruikt voor de website en de certificaatverificatie. UDP 10000 is de standaard mediapoort van Jitsi Videobridge. Een pagina kan perfect laden, terwijl vergaderingen nog steeds mislukken of audio/video verliezen als de mediapoort geblokkeerd is. Het is dus niet voldoende om alleen HTTPS te controleren.

Als uw host zich achter NAT bevindt, controleer dan ook de betreffende instelling JVB_ADVERTISE_IPS. De officiële handleiding legt uit dat deze variabele het adres bepaalt dat Jitsi Videobridge adverteert voor media en dat deze vereist is in veel LAN- of NAT-implementaties. Een typisch voorbeeld van openbaar internet is:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Stap 4: Herstart de Docker-stack met het nieuwe domein.

Sla de wijzigingen op .enven maak de containers vervolgens opnieuw aan, zodat de omgevingswijzigingen worden toegepast:

docker compose down
docker compose up -d
docker compose ps

Een eenvoudige herinstallatie restartis niet de beste keuze na het wijzigen van omgevingsvariabelen, omdat de bestaande containerdefinitie mogelijk nog steeds de vorige omgevingsinstellingen bevat. Door de stack opnieuw aan te maken, worden de nieuwe PUBLIC_URLpoortwaarden en certificaatinstellingen expliciet vastgelegd.

Als u begint met een nieuwe kopie van het project, volg dan eerst de officiële snelstartstappen, inclusief het genereren van de benodigde wachtwoorden en het aanmaken van de configuratiemappen. Recente Jitsi-containerreleases voeren services uit als een gebruiker zonder beheerdersrechten en vereisen beschrijfbare opslag en tijdelijke mappen. Daarom moet u bij een volledig nieuwe installatie de mapopdrachten in de huidige handleiding volgen in plaats van een oude handleiding van een derde partij.

Stap 5: Controleer DNS en HTTPS vanaf buiten de server.

Zodra de DNS-wijzigingen zijn doorgevoerd, controleer dan of de hostnaam wordt omgezet naar het verwachte openbare adres:

dig +short meet.example.com

Test vervolgens het HTTPS-eindpunt:

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

Een succesvolle reactie bewijst dat DNS, TCP 443 en de webservice samenwerken. Het bewijst echter nog niet dat multiparty media werkt, dus dit is een tussencontrole en niet het eindpunt.

Als diger een oud adres wordt geretourneerd, wacht dan op de DNS TTL of corrigeer het record. Als de DNS correct is maar curleen time-out optreedt, controleer dan de cloudbeveiligingsgroepen, de hostfirewall, router-/NAT-regels en of een andere service poort 443 al bezet houdt.

Stap 6: Controleer de certificaatuitgifte en de weblogs.

Als de browser nog steeds een certificaatwaarschuwing weergeeft, controleer dan de logboeken van de webcontainer in plaats van herhaaldelijk de configuratie te verwijderen en een nieuw certificaat aan te vragen:

docker compose logs --tail=200 web

Zoek naar ACME-validatiefouten, fouten bij het koppelen van poorten of een mismatch in de hostnaam. De Jitsi-handleiding waarschuwt voor limieten voor het aantal aanvragen van certificeringsinstanties en adviseert om de configuratiegegevens met uitgegeven certificaten te bewaren. Tijdens herhaalde installatie-experimenten kan een stagingomgeving nuttig zijn, maar na het overschakelen van de stagingomgeving moet volgens de handleiding mogelijk oud certificaatmateriaal uit de stagingomgeving worden verwijderd voordat een productiecertificaat wordt aangevraagd.

Als u al een vertrouwd certificaat van een andere bron hebt, ondersteunt Jitsi ook het koppelen van een bestaande volledige certificaatketen en privésleutel aan de webservice in plaats van de ingebouwde ACME-flow in te schakelen. Volg het voorbeeld voor het koppelen van certificaten in het officiële gedeelte over bestaande certificaten .

Stap 7: Open het aangepaste domein in een browser.

Ga naar de website https://meet.example.comin een moderne browser. Je zou de Jitsi-landingspagina moeten zien onder de door jou gekozen hostnaam, met een geldige TLS-indicator. Maak een testruimte aan met een tijdelijke naam.

Gebruik HTTPS voor echte vergaderingen. De officiële Docker-handleiding waarschuwt specifiek dat directe HTTP-toegang ertoe kan leiden dat WebRTC API's van browsers, zoals toegang tot de microfoon en camera, niet meer werken. HTTPS is daarom onderdeel van de functionele configuratie, en niet slechts een beveiligingsmaatregel.

Stap 8: Test een echt gesprek, niet alleen de homepage.

Neem indien mogelijk vanaf twee verschillende apparaten of netwerken deel aan dezelfde ruimte. Controleer of elke deelnemer audio en video kan verzenden en ontvangen. Een test met twee browsers is belangrijk, omdat een installatie de website correct kan weergeven, terwijl het Videobridge-adres of het UDP-pad nog steeds onjuist is.

Bij installaties achter NAT is een veelvoorkomend symptoom dat de eerste verbinding normaal lijkt, maar dat de mediaverbinding wegvalt naarmate er meer deelnemers zich aansluiten. Controleer in dat geval JVB_ADVERTISE_IPSde openbare NAT-mapping en UDP-poort 10000 opnieuw. De Jitsi-handleiding vermeldt expliciet dat het media-adres van Videobridge relevant blijft, zelfs wanneer HTTP-verkeer via een reverse proxy wordt afgehandeld.

Wanneer je in plaats daarvan een reverse proxy zou moeten gebruiken

De bovenstaande directe configuratie is geschikt wanneer de Jitsi-webcontainer de openbare poorten 80 en 443 kan gebruiken. Als dezelfde server al Nginx, Apache, Caddy, Traefik of een andere proxy op die poorten draait, probeer Jitsi dan niet tegelijkertijd aan deze servers te binden.

Voor een reverse proxy op dezelfde host raadt de officiële Jitsi Docker-handleiding aan om HTTPS in de Jitsi-container uit te schakelen, te voorkomen dat de interne webpoorten openbaar toegankelijk zijn en verzoeken door te sturen naar de HTTP-ingang van de container. De proxy moet ook WebSocket-doorsturing ondersteunen /xmpp-websocket. Een typische Jitsi-omgeving ziet er als volgt uit:

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

Beëindig vervolgens het vertrouwde certificaat bij uw reverse proxy. Dit is de beste oplossing wanneer één proxy certificaten beheert voor meerdere applicaties. Dit is geen reden om het extern zichtbare domein te wijzigen PUBLIC_URL; gebruikers moeten nog steeds het uiteindelijke HTTPS-domein zien.

Problemen met aangepaste domeinen oplossen

Het oude domein blijft zichtbaar na het bewerken van het .env-bestand.

Maak de containers opnieuw aan met docker compose downde volgende opdracht docker compose up -d: . Controleer ook of je het .envbestand hebt bewerkt dat wordt gebruikt door het Compose-project dat je daadwerkelijk start.

De validatie van het HTTPS-certificaat mislukt.

Controleer of de DNS A/AAAA-records verwijzen naar de server die de uitdaging ontvangt en of openbare poort 80 bereikbaar is bij gebruik van de ingebouwde directe certificaatstroom. Controleer docker compose logs webde exacte ACME-fout voordat u een nieuwe aanvraag indient.

De pagina laadt wel, maar deelnemers hebben geen geluid of video.

Controleer UDP 10000 en stel voor NAT-implementaties de juiste instelling in JVB_ADVERTISE_IPS. Houd er rekening mee dat de reverse proxy het webverkeer afhandelt; deze vervangt niet het mediapad van Videobridge.

De browser werkt wel, maar de mobiele app weigert de serververbinding.

Controleer de certificaatketen. In de Jitsi Docker-handleiding staat dat de mobiele apps niet werken met het standaard zelfondertekende certificaat. Gebruik een publiekelijk vertrouwd certificaat of een infrastructuurontwerp waarbij de app een vertrouwde certificaatketen ontvangt.

Definitieve verificatiechecklist

• meet.example.comwordt omgezet naar het beoogde openbare adres.
• PUBLIC_URL=https://meet.example.comkomt exact overeen met de URL van de browser.
• Het TLS-certificaat is betrouwbaar en dekt meet.example.com.
• Poorten 80/TCP en 443/TCP zijn bereikbaar voor de directe configuratie.
• UDP-poort 10000 bereikt de Jitsi Videobridge-host.
• JVB_ADVERTISE_IPSDit is correct wanneer de server zich achter NAT bevindt of expliciet geadverteerde IP-adressen nodig heeft.
• docker compose psToont de vereiste containers die actief zijn.
• Een test met twee deelnemers verzendt succesvol audio en video.

Zodra die controles geslaagd zijn, verwijst het aangepaste domein niet alleen naar Jitsi, maar is het ook geconfigureerd voor de onderdelen die er echt toe doen in een echte vergadering: HTTPS, signalering en mediatransport.

Officiële referenties

• Jitsi Meet handleiding voor zelfhosting — Docker
• docker-jitsi-meet env.example
• Officiële docker-jitsi-meet repository