Cea mai scurtă cale către un domeniu personalizat pentru Jitsi Meet Docker este să îndreptați un nume de gazdă DNS către gazda Docker, să setați PUBLIC_URLadresa URL HTTPS finală, să configurați TLS de încredere pentru același nume de gazdă și să vă asigurați că suportul media WebRTC poate ajunge în continuare la Jitsi Videobridge. Pentru o instalare directă la internet, configurația oficială Docker acceptă automatizarea încorporată a certificatelor prin ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, și LETSENCRYPT_EMAIL.
Acest ghid folosește meet.example.comca exemplu concret și presupune proiectul standard docker-jitsi-meet . Înlocuiți numele de gazdă, adresa de e-mail și adresa IP din documentație din exemplu cu propriile valori. Configurația descrisă aici a fost verificată în raport cu manualul oficial Jitsi Docker și cu proiectul curent env.examplepe 7 octombrie 2026.
Un domeniu personalizat funcționează cel mai bine atunci când numele de gazdă este decis înainte de a solicita un certificat. De exemplu, dacă utilizatorii ar trebui să deschidă https://meet.example.com, DNS, PUBLIC_URLși certificatul TLS ar trebui să utilizeze toate meet.example.com. Amestecarea numelui de jitsi.example.comdomeniu într-un loc și meet.example.comîn altul este un motiv frecvent pentru avertismentele privind certificatele sau redirecționările către gazda greșită.
docker-jitsi-meetși .envfișierul său.Manualul oficial Jitsi Docker precizează că PUBLIC_URLtrebuie setat la domeniul real pentru o implementare de producție. De asemenea, documentează 80/TCP, 443/TCP și 10000/UDP ca porturi externe principale pentru configurarea directă standard. Consultați ghidul de auto-găzduire Jitsi Docker .
Creați o înregistrare A pentru numele de gazdă pe care doriți să îl utilizați. În acest exemplu, meet.example.comindică adresa IPv4 publică a serverului. Dacă serverul dvs. are o conectivitate IPv6 stabilă, puteți adăuga și o înregistrare AAAA care indică adresa sa IPv6 publică.
Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300Nu copiați 203.0.113.10din ilustrație într-o implementare reală; adresa respectivă este rezervată pentru documentație. Dacă utilizați un furnizor DNS cu mod proxy/CDN, începeți cu o rezoluție DNS-only obișnuită, cu excepția cazului în care ați confirmat că proxy-ul acceptă modelul de trafic Jitsi pe care intenționați să îl utilizați.
Deschideți .envfișierul din directorul în care ați clonat sau extras fișierul docker-jitsi-meet. Pentru o implementare directă în care containerul web Jitsi va asculta public pe porturile 80 și 443, setările importante sunt:
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_URLnu este doar cosmetic. Jitsi îl folosește în timp ce construiește o configurație eficientă, așa că lăsarea lui la localhost sau la un nume de gazdă vechi poate produce linkuri rupte și un comportament inconsistent. Exemplul de proiect actual menționează, de asemenea, că, dacă utilizați în mod deliberat un port HTTPS non-standard, acel port aparține în PUBLIC_URL.
Exemplul oficial identifică în prezent ZeroSSL ca server ACME implicit și permite utilizarea LETSENCRYPT_ACME_SERVER="letsencrypt"Let's Encrypt atunci când doriți în mod specific. Dacă instalarea existentă obține deja cu succes un certificat de încredere, păstrați setarea ACME care corespunde mediului dvs. de lucru, în loc să schimbați furnizorii fără un motiv.
Pentru implementarea Docker direct la internet descrisă mai sus, permiteți 80/TCP, 443/TCP și 10000/UDP. De asemenea, păstrați portul de administrare SSH deschis. Pe o gazdă Ubuntu care utilizează UFW, un exemplu minimal este:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verbosePorturile web deservesc provocarea pentru site și certificat. UDP 10000 este portul media implicit Jitsi Videobridge. O pagină se poate încărca perfect în timp ce întâlnirile eșuează sau pierd sunet/video dacă portul media este blocat, așa că verificarea doar a HTTPS nu este suficientă.
Dacă gazda dvs. se află în spatele NAT, consultați și [pagina] JVB_ADVERTISE_IPS. Manualul oficial explică faptul că această variabilă controlează adresa pe care Jitsi Videobridge o promovează pentru media și este necesară în multe implementări LAN sau NAT. Un exemplu tipic de internet public este:
JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4
Salvați .env, apoi recreați containerele astfel încât modificările de mediu să fie aplicate:
docker compose down
docker compose up -d
docker compose psO configurație simplă restartnu este cea mai bună alegere după modificarea variabilelor de mediu, deoarece definiția existentă a containerului poate conține în continuare mediul anterior. Recrearea stivei face ca noile setări PUBLIC_URL, valorile portului și setările certificatului să fie explicite.
Dacă porniți de la o copie nouă a proiectului, urmați mai întâi pașii oficiali de pornire rapidă, inclusiv generarea parolelor necesare și crearea directoarelor de configurare. Versiunile recente de containere Jitsi rulează serviciile ca utilizator neprivilegiat și necesită spațiu de stocare cu drepturi de scriere și directoare temporare, așadar o instalare complet nouă ar trebui să urmeze comenzile de director din manualul curent, mai degrabă decât un tutorial vechi de la o terță parte.
După ce DNS-ul s-a propagat, verificați dacă numele de gazdă se rezolvă la adresa publică așteptată:
dig +short meet.example.comApoi testați endpoint-ul HTTPS:
curl -I https://meet.example.comUn răspuns pozitiv dovedește că DNS, TCP 443 și serviciul web funcționează împreună. Nu dovedește încă că media multipartită funcționează, deci aceasta este o verificare intermediară, nu doar o verificare finală.
Dacă digreturnează o adresă veche, așteptați TTL-ul DNS sau corectați înregistrarea. Dacă DNS-ul este corect, dar curlexpiră, verificați grupurile de securitate din cloud, firewall-ul gazdă, regulile routerului/NAT și dacă un alt serviciu ocupă deja portul 443.
Dacă browserul afișează în continuare un avertisment privind certificatul, verificați jurnalele containerului web în loc să ștergeți în mod repetat configurația și să solicitați un alt certificat:
docker compose logs --tail=200 webCăutați erori de validare ACME, erori de legare a porturilor sau o nepotrivire a numelui de gazdă. Manualul Jitsi avertizează cu privire la limitele ratei autorității de certificare și recomandă păstrarea spațiului de stocare a configurației care conține certificatele emise. În timpul experimentelor repetate de configurare, staging-ul poate fi util, dar după renunțarea la staging, manualul menționează că este posibil să fie nevoie să se elimine materialul vechi al certificatului de staging din spațiul de stocare web înainte de a solicita un certificat de producție.
Dacă aveți deja un certificat de încredere de la o altă sursă, Jitsi acceptă și montarea unui lanț complet existent și a unei chei private în serviciul web, în loc să activeze fluxul ACME încorporat. Urmați exemplul de montare a certificatului din secțiunea oficială existing-certificate .
Accesați https://meet.example.comîntr-un browser modern. Ar trebui să vedeți pagina de destinație Jitsi sub numele de gazdă ales, cu un indicator TLS valid. Creați o cameră de testare cu un nume temporar.
Folosește HTTPS pentru întâlniri reale. Ghidul oficial Docker avertizează în mod specific că accesul direct HTTP poate cauza eșecul API-urilor WebRTC ale browserului, cum ar fi accesul la microfon și cameră. Prin urmare, HTTPS face parte din configurația funcțională, nu doar o simplă insignă de securitate.
Dacă este posibil, alăturați-vă aceleiași camere de pe două dispozitive sau rețele separate. Confirmați că fiecare participant poate trimite și primi audio și video. Un test cu două browsere este important, deoarece o instalare poate servi corect site-ul web chiar dacă adresa Videobridge sau calea UDP sunt încă greșite.
Pentru instalările în spatele NAT, un simptom comun este că prima conexiune pare normală, dar mediul de conectare eșuează pe măsură ce se alătură mai mulți participanți. În acest caz, verificați din nou JVB_ADVERTISE_IPS, maparea NAT publică și UDP 10000. Manualul Jitsi menționează în mod explicit că adresa media Videobridge rămâne relevantă chiar și atunci când traficul HTTP este gestionat de un proxy invers.
Configurația directă de mai sus este potrivită atunci când containerul web Jitsi poate deține porturile publice 80 și 443. Dacă același server rulează deja Nginx, Apache, Caddy, Traefik sau un alt proxy pe aceste porturi, nu încercați să legați Jitsi la ele în același timp.
Pentru un proxy invers pe aceeași gazdă, ghidul oficial Jitsi Docker recomandă dezactivarea HTTPS în interiorul containerului Jitsi, evitarea expunerii publice a porturilor web interne și redirecționarea cererilor către intrarea HTTP a containerului. Proxy-ul trebuie să suporte și redirecționarea WebSocket pentru /xmpp-websocket. Un mediu tipic Jitsi-side este:
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.comApoi, terminați certificatul de încredere la proxy-ul invers. Aceasta este o opțiune mai bună atunci când un proxy gestionează certificate pentru mai multe aplicații. Nu este un motiv pentru a schimba vizibilitatea externă PUBLIC_URL; utilizatorii ar trebui să vadă în continuare domeniul HTTPS final.
Recreați containerele cu [ docker compose downurmător] urmat de [următor] docker compose up -d. De asemenea, verificați dacă ați editat .envfișierul utilizat de proiectul Compose pe care îl începeți.
Confirmați că înregistrările DNS A/AAAA indică serverul care primește provocarea și că portul public 80 este accesibil atunci când utilizați fluxul direct de certificate încorporat. Verificați docker compose logs weberoarea ACME exactă înainte de a face o altă solicitare.
Verificați UDP 10000 și, pentru implementările NAT, setați valoarea corectă JVB_ADVERTISE_IPS. Rețineți că proxy-ul invers gestionează traficul web; acesta nu înlocuiește calea media Videobridge.
Verificați lanțul de certificate. Manualul Jitsi Docker menționează că aplicațiile mobile nu funcționează cu certificatul autosemnat implicit. Folosiți un certificat de încredere publică sau un design de infrastructură în care aplicația primește un lanț de încredere.
meet.example.comse rezolvă la adresa publică prevăzută.PUBLIC_URL=https://meet.example.comse potrivește exact cu adresa URL a browserului.meet.example.com.JVB_ADVERTISE_IPSeste corect atunci când serverul se află în spatele NAT sau are nevoie de adrese anunțate explicit.docker compose psarată containerele necesare care rulează.Odată ce aceste verificări trec, domeniul personalizat nu se limitează doar la Jitsi, ci este configurat pentru părțile care contează cu adevărat într-o întâlnire reală: HTTPS, semnalizare și transport media.
Remediați o eroare a bazei de date Nextcloud WebGUI după o actualizare prin verificarea jurnalelor, finalizarea actualizării occ, repararea problemelor schemei și verificarea stării bazei de date.
Remediați avertismentul ownCloud Apache AllowOverride All prin configurarea directorului corect, testarea Apache, reîncărcarea în siguranță și verificarea protecției .htaccess.
Aflați cum să identificați, să arhivați, să comprimați și să eliminați jurnalele de audit Zimbra vechi, când să evitați trunchierea audit.log și cum să verificați dacă spațiul pe disc și jurnalele se recuperează corect.
Remediați o pagină goală din ownCloud separând erorile de browser, PHP, aplicație, permisiuni, upgrade și proxy, apoi alegeți calea de recuperare cu cea mai puțină perturbare.
Diagnosticați vârfurile de solicitare a procesorului browserului Jitsi Meet și reduceți încărcarea clientului verificând dalele video, efectele camerei, grafica browserului și setările gazdei.
Urmărește starea de funcționare a Jitsi Videobridge, încărcarea conferințelor și traficul cu ajutorul endpoint-ului Prometheus încorporat, apoi explorează și prezintă datele în grafic în Grafana.
Configurați un domeniu personalizat pentru Jitsi Meet Docker cu DNS, PUBLIC_URL, HTTPS, Let's Encrypt, porturi firewall, setări NAT și verificare end-to-end.
Remediați erorile 404 din consola de administrare Zimbra după reînnoirea SSL verificând adresa URL și portul corecte, rutarea proxy, starea serviciului, certificatele implementate și jurnalele.
Învață cum să diagnostichezi și să remediezi avertismentul de configurare PHP OPcache din Nextcloud verificând setările SAPI PHP active, limitele de dimensionare, comentariile și revalidarea.
Depanați erorile de migrare a bazei de date Kopano după o actualizare MySQL sau MariaDB verificând copiile de rezervă, versiunile serverului, modurile SQL, setul de caractere, starea schemei și jurnalele.
