How to Configure a Custom Domain Name for Jitsi Meet Docker

The shortest path to a custom domain for Jitsi Meet Docker is to point a DNS hostname at the Docker host, set PUBLIC_URL to the final HTTPS URL, configure trusted TLS for that same hostname, and make sure WebRTC media can still reach Jitsi Videobridge. For a direct Internet-facing installation, the official Docker setup supports built-in certificate automation through ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, and LETSENCRYPT_EMAIL.

This guide uses meet.example.com as a concrete example and assumes the standard docker-jitsi-meet project. Replace the example hostname, email address, and documentation-only IP address with your own values. The configuration described here was checked against the official Jitsi Docker handbook and current project env.example on October 7, 2026.

What you need before changing the domain

A custom domain works best when the hostname is decided before you request a certificate. For example, if users should open https://meet.example.com, DNS, PUBLIC_URL, and the TLS certificate should all use meet.example.com. Mixing jitsi.example.com in one place and meet.example.com in another is a common reason for certificate warnings or redirects to the wrong host.

• A domain you control.
• A server with Docker Engine and Docker Compose.
• A public IP address, or a reverse proxy that already owns ports 80 and 443.
• Firewall access for the web ports and Jitsi media traffic.
• The existing docker-jitsi-meet directory and its .env file.

The official Jitsi Docker handbook states that PUBLIC_URL must be set to the real domain for a production deployment. It also documents 80/TCP, 443/TCP, and 10000/UDP as the core external ports for the standard direct setup. See the Jitsi Docker self-hosting guide.

Step 1: Point the custom hostname to the Jitsi server

Create an A record for the hostname you want to use. In this example, meet.example.com points to the server's public IPv4 address. If your server has stable IPv6 connectivity, you may also add an AAAA record that points to its public IPv6 address.

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

Do not copy 203.0.113.10 from the illustration into a real deployment; that address is reserved for documentation. If you use a DNS provider with a proxy/CDN mode, start with ordinary DNS-only resolution unless you have confirmed that the proxy supports the Jitsi traffic pattern you intend to use.

Step 2: Set PUBLIC_URL and HTTPS values in .env

Open the .env file in the directory where you cloned or extracted docker-jitsi-meet. For a direct deployment where the Jitsi web container will listen publicly on ports 80 and 443, the important settings are:

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_URLTo nie tylko kwestia estetyki. Jitsi używa go podczas budowania efektywnej konfiguracji, więc pozostawienie go na localhost lub pod starą nazwą hosta może powodować zerwanie linków i niespójne działanie. W bieżącym przykładzie projektu zaznaczono również, że jeśli celowo użyjesz niestandardowego portu HTTPS, port ten powinien znajdować się w PUBLIC_URL.

Oficjalna próbka obecnie identyfikuje ZeroSSL jako domyślny serwer ACME i zezwala na LETSENCRYPT_ACME_SERVER="letsencrypt"korzystanie z Let's Encrypt, gdy jest to wymagane. Jeśli Twoja obecna instalacja pomyślnie uzyskała już zaufany certyfikat, zachowaj ustawienie ACME odpowiadające Twojemu środowisku pracy, zamiast zmieniać dostawcę bez powodu.

Krok 3: Otwórz wymagane porty zapory

W przypadku wdrożenia Dockera bezpośrednio z dostępem do Internetu, opisanego powyżej, należy zezwolić na porty 80/TCP, 443/TCP i 10000/UDP. Należy również pozostawić otwarty port zarządzania SSH. Na hoście Ubuntu z UFW, minimalny przykład wygląda następująco:

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

Porty internetowe obsługują witrynę i wyzwanie certyfikacyjne. UDP 10000 to domyślny port multimedialny Jitsi Videobridge. Strona może załadować się idealnie, a spotkania i tak się nie powiodą lub dźwięk/obraz zniknie, jeśli port multimedialny jest zablokowany. Dlatego sprawdzanie samego protokołu HTTPS nie wystarczy.

Jeśli Twój host korzysta z NAT, zapoznaj się również z sekcją JVB_ADVERTISE_IPS. Oficjalny podręcznik wyjaśnia, że ​​ta zmienna kontroluje adres, który Jitsi Videobridge reklamuje dla multimediów i jest wymagana w wielu wdrożeniach sieci LAN lub NAT. Typowy przykład publicznego Internetu to:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Krok 4: Uruchom ponownie stos Docker z nową domeną

Zapisz .env, a następnie utwórz ponownie kontenery, aby zastosować zmiany w środowisku:

docker compose down
docker compose up -d
docker compose ps

Prosta konfiguracja restartnie jest najlepszym wyborem po zmianie zmiennych środowiskowych, ponieważ istniejąca definicja kontenera może nadal zawierać poprzednie środowisko. Ponowne utworzenie stosu sprawia, że ​​nowe PUBLIC_URLwartości, porty i ustawienia certyfikatu stają się jawne.

Jeśli zaczynasz od nowej kopii projektu, najpierw wykonaj oficjalne kroki szybkiego startu, w tym wygenerowanie wymaganych haseł i utworzenie katalogów konfiguracyjnych. Najnowsze wersje kontenerów Jitsi uruchamiają usługi jako użytkownik bez uprawnień i wymagają pamięci masowej z możliwością zapisu oraz katalogów tymczasowych, dlatego całkowicie nowa instalacja powinna przebiegać zgodnie z poleceniami katalogowymi zawartymi w aktualnym podręczniku, a nie według starego, zewnętrznego samouczka.

Krok 5: Potwierdź DNS i HTTPS spoza serwera

Po propagacji DNS sprawdź, czy nazwa hosta odpowiada oczekiwanemu adresowi publicznemu:

dig +short meet.example.com

Następnie przetestuj punkt końcowy HTTPS:

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

Pomyślna odpowiedź dowodzi, że DNS, TCP 443 i usługa sieciowa współpracują ze sobą. Nie dowodzi to jednak jeszcze działania multimediów wielostronnych, więc jest to raczej weryfikacja pośrednia niż punkt końcowy.

Jeśli digzwróci stary adres, poczekaj na wartość TTL DNS lub popraw rekord. Jeśli DNS jest poprawny, ale curlprzekracza limit czasu, sprawdź grupy zabezpieczeń chmury, zaporę hosta, reguły routera/NAT i sprawdź, czy inna usługa zajmuje już port 443.

Krok 6: Sprawdź wydanie certyfikatu i dzienniki sieciowe

Jeśli przeglądarka nadal wyświetla ostrzeżenie o certyfikacie, sprawdź logi kontenera internetowego zamiast wielokrotnie usuwać konfigurację i żądać kolejnego certyfikatu:

docker compose logs --tail=200 web

Sprawdź błędy walidacji ACME, błędy powiązania portów lub niezgodność nazwy hosta. Podręcznik Jitsi ostrzega o limitach szybkości urzędów certyfikacji i zaleca zachowanie pamięci masowej konfiguracji zawierającej wydane certyfikaty. Podczas powtarzających się eksperymentów konfiguracyjnych, przechowywanie w trybie przejściowym może być przydatne, ale po przejściu na tryb przejściowy, podręcznik zauważa, że ​​przed żądaniem certyfikatu produkcyjnego może być konieczne usunięcie starych danych certyfikatu w trybie przejściowym z pamięci masowej.

Jeśli posiadasz już zaufany certyfikat z innego źródła, Jitsi obsługuje również montowanie istniejącego pełnego łańcucha i klucza prywatnego w usłudze sieciowej, zamiast włączania wbudowanego przepływu ACME. Skorzystaj z przykładu montowania certyfikatu w oficjalnej sekcji dotyczącej istniejącego certyfikatu .

Krok 7: Otwórz domenę niestandardową w przeglądarce

Otwórz witrynę https://meet.example.comw nowoczesnej przeglądarce. Powinna wyświetlić się strona docelowa Jitsi pod wybraną nazwą hosta z prawidłowym wskaźnikiem TLS. Utwórz pokój testowy z nazwą tymczasową.

Używaj protokołu HTTPS podczas prawdziwych spotkań. Oficjalny przewodnik po Dockerze wyraźnie ostrzega, że ​​bezpośredni dostęp HTTP może spowodować awarię interfejsów API WebRTC przeglądarki, takich jak dostęp do mikrofonu i kamery. HTTPS jest zatem częścią konfiguracji funkcjonalnej, a nie tylko symbolem bezpieczeństwa.

Krok 8: Przetestuj prawdziwe połączenie, a nie tylko stronę główną

Jeśli to możliwe, dołącz do tego samego pokoju z dwóch różnych urządzeń lub sieci. Upewnij się, że każdy uczestnik może wysyłać i odbierać dźwięk i obraz. Test w dwóch przeglądarkach jest ważny, ponieważ instalacja może poprawnie obsługiwać stronę internetową, nawet jeśli adres Videobridge lub ścieżka UDP nadal są nieprawidłowe.

W przypadku instalacji z NAT, częstym objawem jest to, że pierwsze połączenie wydaje się normalne, ale media zawodzą wraz z dołączaniem kolejnych uczestników. W takim przypadku należy ponownie sprawdzić JVB_ADVERTISE_IPS, publiczne mapowanie NAT oraz UDP 10000. W podręczniku Jitsi wyraźnie zaznaczono, że adres multimediów Videobridge pozostaje istotny nawet wtedy, gdy ruch HTTP jest obsługiwany przez odwrotny serwer proxy.

Kiedy należy użyć odwrotnego serwera proxy

Powyższa bezpośrednia konfiguracja jest odpowiednia, gdy kontener internetowy Jitsi może posiadać publiczne porty 80 i 443. Jeśli na tym samym serwerze działa już Nginx, Apache, Caddy, Traefik lub inny serwer proxy na tych portach, nie należy próbować wiązać z nimi jednocześnie Jitsi.

W przypadku odwrotnego serwera proxy na tym samym hoście, oficjalny przewodnik Jitsi Docker zaleca wyłączenie protokołu HTTPS w kontenerze Jitsi, unikanie publicznego udostępniania jego wewnętrznych portów internetowych oraz przekierowywanie żądań do wejścia HTTP kontenera. Serwer proxy musi również obsługiwać przekierowywanie protokołu WebSocket /xmpp-websocket. Typowe środowisko po stronie Jitsi to:

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

Następnie zakończ działanie zaufanego certyfikatu na odwrotnym serwerze proxy. Jest to lepsze rozwiązanie, gdy jeden serwer proxy zarządza certyfikatami dla kilku aplikacji. Nie ma powodu, aby zmieniać domenę widoczną zewnętrznie PUBLIC_URL; użytkownicy nadal powinni widzieć ostateczną domenę HTTPS.

Rozwiązywanie problemów z domenami niestandardowymi

Stara domena nadal pojawia się po edycji .env

Utwórz ponownie kontenery, używając , a docker compose downnastępnie docker compose up -d. Sprawdź również, czy edytowałeś .envplik używany przez projekt Compose, który faktycznie uruchamiasz.

Niepowodzenie walidacji certyfikatu HTTPS

Sprawdź, czy rekordy DNS A/AAAA wskazują na serwer odbierający wyzwanie i czy publiczny port 80 jest dostępny podczas korzystania z wbudowanego bezpośredniego przepływu certyfikatów. docker compose logs webPrzed wysłaniem kolejnego żądania sprawdź, czy wystąpił błąd ACME.

Strona się ładuje, ale uczestnicy nie mają dostępu do dźwięku ani obrazu

Sprawdź UDP 10000 i, w przypadku wdrożeń NAT, ustaw poprawną wartość JVB_ADVERTISE_IPS. Pamiętaj, że odwrotny serwer proxy obsługuje ruch sieciowy i nie zastępuje ścieżki multimedialnej Videobridge.

Przeglądarka działa, ale aplikacja mobilna odrzuca serwer

Sprawdź łańcuch certyfikatów. W podręczniku Jitsi Docker zaznaczono, że aplikacje mobilne nie działają z domyślnym certyfikatem podpisanym samodzielnie. Użyj publicznie zaufanego certyfikatu lub projektu infrastruktury, w którym aplikacja otrzymuje zaufany łańcuch.

Ostateczna lista kontrolna weryfikacji

• meet.example.comrozwiązuje się na zamierzony adres publiczny.
• PUBLIC_URL=https://meet.example.comdokładnie odpowiada adresowi URL przeglądarki.
• Certyfikat TLS jest zaufany i obejmuje meet.example.com.
• Do konfiguracji bezpośredniej dostępne są porty 80/TCP i 443/TCP.
• Protokół UDP 10000 dociera do hosta Jitsi Videobridge.
• JVB_ADVERTISE_IPSjest poprawny, gdy serwer znajduje się za NAT-em lub wymaga jawnie reklamowanych adresów.
• docker compose pspokazuje wymagane uruchomione kontenery.
• Test dwuosobowy kończy się pomyślnym wysłaniem dźwięku i obrazu.

Gdy te kontrole zakończą się sukcesem, domena niestandardowa nie będzie już wskazywała wyłącznie na Jitsi — będzie też skonfigurowana pod kątem elementów, które rzeczywiście mają znaczenie podczas prawdziwego spotkania: protokołu HTTPS, sygnalizacji i przesyłu multimediów.

Oficjalne referencje

• Przewodnik po samodzielnym hostingu Jitsi Meet — Docker
• docker-jitsi-meet env.example
• Oficjalne repozytorium docker-jitsi-meet