Jitsi Meet Docker에서 사용자 지정 도메인 이름을 구성하는 방법

Jitsi Meet Docker용 사용자 지정 도메인을 설정하는 가장 빠른 방법은 DNS 호스트 이름을 Docker 호스트로 지정하고, 최종 HTTPS URL을 설정하고 , 동일한 호스트 이름에 대해 신뢰할 수 있는 TLS를 구성하고, WebRTC 미디어가 Jitsi Videobridge에 계속 연결할 수 있도록 하는 것입니다. 인터넷에 직접 연결하는 설치의 경우, 공식 Docker 설정은 , , 을 PUBLIC_URL통해 내장된 인증서 자동화 기능을 지원합니다 .ENABLE_LETSENCRYPTLETSENCRYPT_DOMAINLETSENCRYPT_EMAIL

이 가이드에서는 meet.example.com구체적인 예시로 표준 docker-jitsi-meet 프로젝트를 사용합니다 . 예시 호스트 이름, 이메일 주소 및 문서 전용 IP 주소는 실제 값으로 교체하십시오. 여기에 설명된 구성은 2026년 10월 7일 기준으로 공식 Jitsi Docker 핸드북 및 최신 프로젝트를 기준으로 검증되었습니다 env.example.

도메인 변경 전에 필요한 사항

사용자 지정 도메인은 인증서를 요청하기 전에 호스트 이름을 결정하는 것이 가장 좋습니다. 예를 들어 사용자가 에 접속해야 하는 경우 https://meet.example.comDNS, PUBLIC_URL, 그리고 TLS 인증서 모두 를 사용해야 합니다 meet.example.com. jitsi.example.com서로 meet.example.com다른 곳에서 호스트 이름과 호스트 이름을 혼용하면 인증서 경고가 발생하거나 잘못된 호스트로 리디렉션되는 경우가 많습니다.

  • 귀하가 소유한 도메인입니다.
  • Docker Engine과 Docker Compose가 설치된 서버.
  • 공용 IP 주소 또는 이미 80번 포트와 443번 포트를 소유하고 있는 리버스 프록시.
  • 웹 포트 및 Jitsi 미디어 트래픽에 대한 방화벽 액세스.
  • 기존 docker-jitsi-meet디렉터리와 그 안에 있는 .env파일.

Jitsi Docker 공식 핸드북에는 PUBLIC_URL프로덕션 배포를 위해 도메인을 실제 도메인으로 설정해야 한다고 명시되어 있습니다. 또한 표준 직접 설정에 필요한 핵심 외부 포트로 80/TCP, 443/TCP, 10000/UDP를 설명하고 있습니다. Jitsi Docker 자체 호스팅 가이드를 참조하세요 .

1단계: 사용자 지정 호스트 이름을 Jitsi 서버로 지정합니다.

사용할 호스트 이름에 대한 A 레코드를 생성합니다. 이 예에서는 meet.example.com서버의 공용 IPv4 주소를 가리킵니다. 서버가 안정적인 IPv6 연결을 지원하는 경우, 서버의 공용 IPv6 주소를 가리키는 AAAA 레코드를 추가할 수도 있습니다.

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

이 그림의 주소를 실제 배포 환경에 복사하지 마십시오 203.0.113.10. 해당 주소는 문서용으로 예약되어 있습니다. 프록시/CDN 모드를 지원하는 DNS 제공업체를 사용하는 경우, 사용하려는 Jitsi 트래픽 패턴을 프록시가 지원하는지 확인하기 전까지는 일반 DNS 확인만 시도하십시오.

meet.example.com에 대한 A 레코드가 서버 IP 주소를 가리키는 DNS 관리 화면입니다.
meet 서브도메인에 대한 DNS 구성 예시입니다. 예시에 나온 주소를 Jitsi 호스트의 실제 공용 IP 주소로 바꾸십시오.

2단계: .env 파일에 PUBLIC_URL 및 HTTPS 값을 설정합니다.

.env클론 또는 압축 해제한 디렉터리에서 파일을 엽니다 docker-jitsi-meet. Jitsi 웹 컨테이너가 80번 포트와 443번 포트에서 공개적으로 수신 대기하도록 직접 배포하는 경우 중요한 설정은 다음과 같습니다.

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_URL단순히 외관상의 문제가 아닙니다. Jitsi는 효과적인 구성을 구축하는 동안 이를 사용하므로, localhost 또는 이전 호스트 이름으로 두면 링크가 깨지거나 일관성 없는 동작이 발생할 수 있습니다. 현재 프로젝트 샘플에서는 비표준 HTTPS 포트를 의도적으로 사용하는 경우 해당 포트가 .에 속해야 한다고 명시하고 있습니다 PUBLIC_URL.

현재 공식 샘플에서는 ZeroSSL이 기본 ACME 서버로 지정되어 있으며, LETSENCRYPT_ACME_SERVER="letsencrypt"Let's Encrypt를 사용하도록 명시적으로 지정할 수도 있습니다. 기존 설치 환경에서 이미 신뢰할 수 있는 인증서를 성공적으로 발급받았다면, 특별한 이유 없이 제공업체를 변경하지 말고 현재 사용 중인 환경과 일치하는 ACME 설정을 유지하는 것이 좋습니다.

meet.example.com에 대한 PUBLIC_URL, HTTP_PORT, HTTPS_PORT 및 Let's Encrypt 변수를 보여주는 터미널 편집기
.env 파일의 주요 값은 사용자가 브라우저에 입력할 공개 호스트 이름과 동일해야 합니다.

3단계: 필요한 방화벽 포트를 엽니다.

위에서 설명한 인터넷에 직접 연결되는 Docker 배포의 경우 80/TCP, 443/TCP 및 10000/UDP 포트를 허용하십시오. SSH 관리 포트도 열어 두십시오. UFW를 사용하는 Ubuntu 호스트의 최소 예시는 다음과 같습니다.

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

웹 포트는 사이트 접속 및 인증서 인증을 담당합니다. UDP 10000은 Jitsi Videobridge의 기본 미디어 포트입니다. 미디어 포트가 차단되면 페이지는 완벽하게 로드되더라도 회의가 실패하거나 오디오/비디오 연결이 끊길 수 있으므로 HTTPS만 확인하는 것으로는 충분하지 않습니다.

호스트가 NAT 뒤에 있는 경우, 다음 사항도 검토하십시오 JVB_ADVERTISE_IPS. 공식 설명서에 따르면 이 변수는 Jitsi Videobridge가 미디어에 대해 광고하는 주소를 제어하며 많은 LAN 또는 NAT 환경에서 필수적입니다. 일반적인 공용 인터넷 환경의 예는 다음과 같습니다.

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4
TCP 포트 80 및 443, UDP 포트 10000을 허용하는 UFW 규칙을 보여주는 터미널 화면
방화벽 검증에는 웹사이트 포트뿐만 아니라 Jitsi Videobridge의 UDP 미디어 포트도 포함되어야 합니다.

4단계: 새 도메인으로 Docker 스택을 다시 시작합니다.

변경 사항을 저장한 .env다음 컨테이너를 다시 생성하여 환경 변경 사항이 적용되도록 하십시오.

docker compose down
docker compose up -d
docker compose ps

환경 변수를 변경한 후에는 기존 컨테이너 정의에 이전 환경 변수가 남아 있을 수 있으므로 간단한 방법은 restart최선의 선택이 아닙니다. 스택을 다시 생성하면 새로운 환경 변수 PUBLIC_URL, 포트 값 및 인증서 설정이 명시적으로 적용됩니다.

프로젝트를 새로 시작하는 경우, 필요한 암호 생성 및 구성 디렉터리 생성 등 공식 빠른 시작 단계를 먼저 따르십시오. 최근 Jitsi 컨테이너 릴리스는 권한이 없는 사용자로 서비스를 실행하며 쓰기 가능한 저장소와 임시 디렉터리가 필요하므로, 완전히 새로 설치하는 경우에는 이전 타사 튜토리얼이 아닌 최신 설명서의 디렉터리 명령을 따라야 합니다.

Jitsi 웹, Prosody, Jicofo 및 JVB 컨테이너가 시작된 것을 보여주는 Docker Compose 터미널
.env 파일을 변경한 후 스택을 다시 생성하고 핵심 Jitsi 컨테이너가 실행 중인지 확인하십시오.

5단계: 서버 외부에서 DNS 및 HTTPS를 확인합니다.

DNS 전파가 완료되면 호스트 이름이 예상되는 공용 주소로 확인되는지 확인하십시오.

dig +short meet.example.com

다음으로 HTTPS 엔드포인트를 테스트합니다.

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

성공적인 응답은 DNS, TCP 443 포트 및 웹 서비스가 서로 연동하여 작동하고 있음을 증명합니다. 하지만 이는 다자간 미디어가 제대로 작동한다는 것을 증명하는 것은 아니므로, 최종 단계라기보다는 중간 점검 단계입니다.

이전 주소가 반환 되면 digDNS TTL이 만료될 때까지 기다리거나 레코드를 수정하십시오. DNS 주소는 올바르지만 curl시간 초과가 발생하면 클라우드 보안 그룹, 호스트 방화벽, 라우터/NAT 규칙을 확인하고 다른 서비스가 443번 포트를 이미 사용 중인지 확인하십시오.

터미널에서 dig 명령어를 실행하여 meet.example.com에 대한 정보를 얻고, curl -I 명령어를 사용하여 해당 HTTPS URL에 대해 200 응답을 받는 경우를 보여줍니다.
DNS 확인 및 HTTPS 헤더 요청이 성공적으로 완료되면 사용자 지정 호스트 이름을 신속하게 초기 검증할 수 있습니다.

6단계: 인증서 발급 및 웹 로그를 확인합니다.

브라우저에 여전히 인증서 경고가 표시되는 경우, 구성을 반복적으로 삭제하고 새 인증서를 요청하는 대신 웹 컨테이너 로그를 검사하십시오.

docker compose logs --tail=200 web

ACME 유효성 검사 오류, 포트 바인딩 실패 또는 호스트 이름 불일치를 확인하십시오. Jitsi 설명서에서는 인증 기관의 속도 제한에 대해 경고하고 발급된 인증서가 포함된 구성 저장소를 보존할 것을 권장합니다. 반복적인 설정 실험 중에는 스테이징 환경이 유용할 수 있지만, 스테이징 환경에서 벗어난 후에는 프로덕션 인증서를 요청하기 전에 웹 저장소에서 이전 스테이징 인증서 자료를 삭제해야 할 수도 있다고 설명서에 나와 있습니다.

이미 다른 곳에서 발급받은 신뢰할 수 있는 인증서가 있는 경우, Jitsi는 내장된 ACME 흐름을 활성화하는 대신 기존의 전체 인증서 체인과 개인 키를 웹 서비스에 마운트하는 것도 지원합니다. 공식 기존 인증서 섹션 의 인증서 마운트 예제를 참조하세요 .

Docker Compose 웹 로그에 meet.example.com에 대한 인증서 요청 및 Nginx 시작 메시지가 표시됩니다.
인증서 또는 Nginx 시작 문제를 진단하려면 새 인증서를 반복적으로 요청하는 대신 웹 컨테이너 로그를 사용하십시오.

7단계: 브라우저에서 사용자 지정 도메인을 엽니다.

최신 브라우저에서 접속하세요 https://meet.example.com. 선택한 호스트 이름으로 Jitsi 랜딩 페이지가 표시되고 유효한 TLS 표시기가 나타날 것입니다. 임시 이름으로 테스트룸을 생성하세요.

실제 회의에는 HTTPS를 사용하십시오. Docker 공식 가이드에서는 HTTP를 직접 사용하면 마이크 및 카메라 접근과 같은 브라우저 WebRTC API에 접근할 수 없게 될 수 있다고 명시적으로 경고합니다. 따라서 HTTPS는 단순한 보안 조치가 아니라 필수적인 기능 구성 요소입니다.

브라우저에 https://meet.example.com 주소의 Jitsi Meet 랜딩 페이지가 표시되고 있으며, 회의 이름 필드가 있습니다.
미디어 테스트를 시작하기 전에 랜딩 페이지가 최종 HTTPS 호스트 이름에서 로드되어야 합니다.

8단계: 홈페이지뿐만 아니라 실제 통화도 테스트해 보세요.

가능하다면 서로 다른 두 기기 또는 네트워크에서 동일한 회의실에 접속하세요. 각 참가자가 오디오와 비디오를 송수신할 수 있는지 확인하십시오. 웹사이트는 정상적으로 표시되지만 Videobridge 주소 또는 UDP 경로가 잘못되었을 수 있으므로 두 가지 브라우저를 사용한 테스트가 중요합니다.

NAT 뒤에 설치된 환경에서 흔히 나타나는 증상은 첫 연결은 정상적으로 보이지만, 참여자가 늘어날수록 미디어 전송이 실패하는 것입니다. 이 경우 JVB_ADVERTISE_IPS공용 NAT 매핑과 UDP 10000 포트를 다시 확인하십시오. Jitsi 설명서에는 HTTP 트래픽이 리버스 프록시를 통해 처리되는 경우에도 Videobridge 미디어 주소가 여전히 중요하다고 명시되어 있습니다.

Jitsi Meet 브라우저 통화 화면(meet.example.com)에 두 명의 참가자와 회의 제어 기능이 표시됩니다.
두 참가자 간의 통화가 성공적으로 이루어지면 Jitsi 홈페이지가 로드되는지 확인하는 것보다 더 나은 엔드 투 엔드 테스트가 됩니다.

리버스 프록시를 사용해야 하는 경우는 언제일까요?

위의 직접 구성은 Jitsi 웹 컨테이너가 공용 포트 80과 443을 사용할 수 있는 경우에 적합합니다. 동일한 서버에서 이미 Nginx, Apache, Caddy, Traefik 또는 다른 프록시가 해당 포트를 사용하고 있는 경우, Jitsi를 이러한 서비스에 동시에 바인딩하지 마십시오.

동일 호스트 리버스 프록시의 경우, Jitsi 공식 Docker 가이드에서는 Jitsi 컨테이너 내부에서 HTTPS를 비활성화하고, 내부 웹 포트가 외부에 노출되지 않도록 하며, 컨테이너의 HTTP 인그레스로 요청을 전달할 것을 권장합니다. 또한 프록시는 WebSocket 포워딩을 지원해야 합니다 /xmpp-websocket. 일반적인 Jitsi 환경은 다음과 같습니다.

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

그런 다음 리버스 프록시에서 신뢰할 수 있는 인증서를 종료하십시오. 이는 하나의 프록시가 여러 애플리케이션의 인증서를 관리하는 경우에 더 적합합니다. 외부에서 보이는 주소를 변경할 필요는 없으며 PUBLIC_URL, 사용자는 여전히 최종 HTTPS 도메인을 보게 됩니다.

사용자 지정 도메인 오류 해결

.env 파일을 수정해도 이전 도메인이 여전히 표시됩니다.

컨테이너를 다시 생성하려면 docker compose down다음 명령어를 실행하세요. 또한 실제로 시작하려는 Compose 프로젝트에서 사용하는 파일을 docker compose up -d편집했는지 확인하세요 ..env

HTTPS 인증서 유효성 검사에 실패했습니다.

DNS A/AAAA 레코드가 챌린지를 수신하는 서버를 가리키는지, 그리고 내장된 직접 인증서 흐름을 사용할 때 공용 포트 80에 접근할 수 있는지 확인하십시오. docker compose logs web추가 요청을 하기 전에 정확한 ACME 오류를 확인하십시오.

페이지는 로드되지만 참가자들은 오디오나 비디오를 사용할 수 없습니다.

UDP 10000 포트를 확인하고, NAT 환경의 경우 올바른 값을 설정하십시오 JVB_ADVERTISE_IPS. 리버스 프록시는 웹 트래픽을 처리하는 것이지 Videobridge 미디어 경로를 대체하는 것이 아님을 기억하십시오.

브라우저는 작동하지만 모바일 앱이 서버 연결을 거부합니다.

인증서 체인을 확인하세요. Jitsi Docker 핸드북에 따르면 모바일 앱은 기본 자체 서명 인증서로는 작동하지 않습니다. 공개적으로 신뢰할 수 있는 인증서를 사용하거나 앱이 신뢰할 수 있는 인증서 체인을 받을 수 있도록 인프라를 설계하세요.

최종 확인 체크리스트

  • meet.example.com의도한 공개 주소로 연결됩니다.
  • PUBLIC_URL=https://meet.example.com브라우저 URL과 정확히 일치합니다.
  • TLS 인증서는 신뢰할 수 있으며 다음을 포함합니다 meet.example.com.
  • 포트 80/TCP 및 443/TCP를 통해 직접 설정이 가능합니다.
  • UDP 10000 포트가 Jitsi Videobridge 호스트에 도달합니다.
  • JVB_ADVERTISE_IPS서버가 NAT 뒤에 있거나 명시적으로 광고된 주소가 필요한 경우에 올바른 표현입니다.
  • docker compose ps필요한 컨테이너가 실행 중임을 보여줍니다.
  • 두 명의 참가자가 참여한 테스트에서 오디오와 비디오가 성공적으로 전송되었습니다.

이러한 검사를 통과하면 사용자 지정 도메인은 Jitsi를 가리킬 뿐만 아니라 실제 회의에서 중요한 부분인 HTTPS, 신호 처리 및 미디어 전송에 맞게 구성됩니다.

공식 참고 자료

댓글 남기기

Jitsi Meet 클라이언트 브라우저에서 높은 CPU 사용량 문제 해결

Jitsi Meet 클라이언트 브라우저에서 높은 CPU 사용량 문제 해결

Jitsi Meet 브라우저의 CPU 사용량 급증 원인을 진단하고 비디오 타일, 카메라 효과, 브라우저 그래픽 및 호스트 설정을 확인하여 클라이언트 부하를 줄이세요.

Prometheus와 Grafana를 사용하여 Jitsi Videobridge 메트릭을 모니터링하는 방법

Prometheus와 Grafana를 사용하여 Jitsi Videobridge 메트릭을 모니터링하는 방법

Jitsi Videobridge의 내장 Prometheus 엔드포인트를 사용하여 상태, 회의 부하 및 트래픽을 추적한 다음 Grafana에서 데이터를 탐색하고 차트로 표시할 수 있습니다.

Jitsi Meet Docker에서 사용자 지정 도메인 이름을 구성하는 방법

Jitsi Meet Docker에서 사용자 지정 도메인 이름을 구성하는 방법

Jitsi Meet Docker에 대한 사용자 지정 도메인을 DNS, PUBLIC_URL, HTTPS, Let's Encrypt, 방화벽 포트, NAT 설정 및 엔드 투 엔드 검증을 통해 구성합니다.

SSL 갱신 후 Zimbra 관리 콘솔에서 발생하는 404 오류(찾을 수 없음) 해결 방법

SSL 갱신 후 Zimbra 관리 콘솔에서 발생하는 404 오류(찾을 수 없음) 해결 방법

SSL 갱신 후 Zimbra 관리 콘솔에서 발생하는 404 오류를 해결하려면 올바른 URL 및 포트, 프록시 라우팅, 서비스 상태, 배포된 인증서 및 로그를 확인하십시오.

Nextcloud에서 발생하는 "PHP OPcache가 제대로 구성되지 않았습니다" 경고를 해결하는 방법

Nextcloud에서 발생하는 "PHP OPcache가 제대로 구성되지 않았습니다" 경고를 해결하는 방법

Nextcloud의 PHP OPcache 구성 경고를 진단하고 해결하는 방법을 알아보세요. 활성화된 PHP SAPI, 크기 제한, 주석 및 재검증 설정을 확인하면 됩니다.

MySQL 버전 업그레이드 후 Kopano 데이터베이스 마이그레이션 오류 해결 방법

MySQL 버전 업그레이드 후 Kopano 데이터베이스 마이그레이션 오류 해결 방법

MySQL 또는 MariaDB 업그레이드 후 Kopano 데이터베이스 마이그레이션 실패 문제를 해결하려면 백업, 서버 버전, SQL 모드, 문자 집합, 스키마 상태 및 로그를 확인하십시오.

Nextcloud에서 LDAP 및 Active Directory 인증을 구성하는 방법

Nextcloud에서 LDAP 및 Active Directory 인증을 구성하는 방법

안전한 전송, 사용자 및 그룹 필터, 로그인 속성, 그리고 검증된 배포 기능을 통해 Nextcloud를 LDAP 또는 Active Directory에 연결하세요.

Google 서비스 없이 Element Android 알림 설정하기: UnifiedPush 가이드

Google 서비스 없이 Element Android 알림 설정하기: UnifiedPush 가이드

UnifiedPush, Android 권한, 배터리 설정 및 안정성 검증 테스트를 구성하여 Google 서비스가 제거된 휴대폰에서 Element Android 알림 문제를 해결하세요.

Nextcloud의 "데이터베이스에 일부 인덱스가 누락되었습니다" 경고를 해결하는 방법

Nextcloud의 "데이터베이스에 일부 인덱스가 누락되었습니다" 경고를 해결하는 방법

Nextcloud의 데이터베이스 인덱스 누락 경고를 공식 occ 명령어를 사용하여 해결하세요. 먼저 백업을 수행하고, 변경 사항을 미리 보고, 복구를 실행한 후 결과를 확인하십시오.

Element Web에서 Keycloak을 사용하여 싱글 사인온(SSO)을 구성하는 방법

Element Web에서 Keycloak을 사용하여 싱글 사인온(SSO)을 구성하는 방법

OIDC를 Synapse에 연결하고, 정확한 콜백 URL을 설정하고, 사용자 클레임을 매핑하고, 로그아웃을 테스트하여 Element Web용 Keycloak SSO를 구성하십시오.