Как настроить пользовательское доменное имя для Jitsi Meet Docker

Кратчайший путь к созданию собственного домена для Jitsi Meet Docker — это указать DNS-имя хоста на хост Docker, установить PUBLIC_URLконечный HTTPS-адрес, настроить доверенный TLS для этого же имени хоста и убедиться, что медиаконтент WebRTC по-прежнему доступен для Jitsi Videobridge. Для установки с прямым доступом из Интернета официальная настройка Docker поддерживает встроенную автоматизацию сертификатов через ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, и LETSENCRYPT_EMAIL.

В этом руководстве meet.example.comв качестве конкретного примера используется стандартный проект docker-jitsi-meet . Замените приведенные в примере имя хоста, адрес электронной почты и IP-адрес, указанные только в документации, своими собственными значениями. Описанная здесь конфигурация была проверена на соответствие официальному руководству по Docker для Jitsi и текущему проекту env.example7 октября 2026 года.

Что вам понадобится перед сменой домена

Использование собственного домена наиболее эффективно, если имя хоста определяется до запроса сертификата. Например, если пользователи должны открывать DNS https://meet.example.com, DNS PUBLIC_URLи TLS-сертификат должны использовать DNS meet.example.com. Смешивание DNS jitsi.example.comв одном месте и meet.example.comDNS в другом является распространенной причиной предупреждений о сертификате или перенаправлений на неправильный хост.

• Домен, который вы контролируете.
• Сервер с 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-соединение, вы также можете добавить запись AAAA, указывающую на его публичный IPv6-адрес.

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

Не копируйте 203.0.113.10изображение в реальную среду развертывания; этот адрес зарезервирован для документации. Если вы используете DNS-провайдера в режиме прокси/CDN, начните с обычного разрешения DNS-запросов, если вы не убедились, что прокси-сервер поддерживает схему трафика Jitsi, которую вы планируете использовать.

Шаг 2: Установите значения PUBLIC_URL и HTTPS в файле .env.

Откройте .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.

В официальном примере в качестве сервера ACME по умолчанию указан ZeroSSL, что позволяет LETSENCRYPT_ACME_SERVER="letsencrypt"использовать Let's Encrypt, если это необходимо. Если ваша существующая установка уже успешно получает доверенный сертификат, сохраните настройки ACME, соответствующие вашей рабочей среде, вместо того, чтобы менять поставщика без причины.

Шаг 3: Откройте необходимые порты брандмауэра.

Для описанного выше развертывания Docker с прямым доступом из интернета разрешите использование портов 80/TCP, 443/TCP и 10000/UDP. Также оставьте открытым порт управления SSH. На хосте Ubuntu с использованием UFW минимальный пример выглядит следующим образом:

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 объявляет для медиафайлов, и необходима во многих локальных сетях или развертываниях с NAT. Типичный пример из общедоступного интернета:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

Шаг 4: Перезапустите стек Docker с новым доменом.

Сохраните изменения .env, а затем создайте контейнеры заново, чтобы применить изменения среды:

docker compose down
docker compose up -d
docker compose ps

Простой вариант restartне является лучшим решением после изменения переменных окружения, поскольку существующее определение контейнера может по-прежнему содержать предыдущую среду. Пересоздание стека делает новые PUBLIC_URLзначения параметров, портов и настроек сертификата явными.

Если вы начинаете с чистого листа проекта, сначала выполните официальные шаги быстрого запуска, включая генерацию необходимых паролей и создание каталогов конфигурации. В последних версиях контейнеров Jitsi службы запускаются от имени непривилегированного пользователя и требуют доступа к записываемому хранилищу и временным каталогам, поэтому для полной переустановки следует использовать команды для работы с каталогами из текущего руководства, а не старые сторонние инструкции.

Шаг 5: Подтвердите DNS и HTTPS извне сервера.

После распространения DNS-запроса убедитесь, что имя хоста разрешается в ожидаемый публичный адрес:

dig +short meet.example.com

Затем проверьте конечную точку HTTPS:

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

Успешный ответ доказывает, что DNS, TCP 443 и веб-сервис работают совместно. Он еще не доказывает работоспособность многосторонних медиасерверов, поэтому это промежуточная проверка, а не окончательный результат.

Если digвозвращается старый адрес, дождитесь истечения срока действия DNS TTL или исправьте запись. Если DNS корректен, но curlпроисходит таймаут, проверьте группы безопасности облака, брандмауэр хоста, правила маршрутизатора/NAT и проверьте, не занимает ли порт 443 уже другая служба.

Шаг 6: Проверьте выдачу сертификатов и веб-журналы.

Если браузер по-прежнему отображает предупреждение о сертификате, вместо того чтобы многократно удалять конфигурацию и запрашивать новый сертификат, проверьте журналы веб-контейнера:

docker compose logs --tail=200 web

Проверьте наличие ошибок проверки ACME, сбоев привязки портов или несоответствия имени хоста. В руководстве Jitsi предупреждается об ограничениях скорости запросов к центрам сертификации и рекомендуется сохранять хранилище конфигурации, содержащее выданные сертификаты. Во время повторных экспериментов по настройке может быть полезно использовать промежуточное хранилище, но после отказа от него в руководстве отмечается, что старые данные сертификатов из промежуточного хранилища, возможно, потребуется удалить из веб-хранилища перед запросом производственного сертификата.

Если у вас уже есть доверенный сертификат из другого источника, Jitsi также поддерживает подключение существующей полной цепочки и закрытого ключа к веб-сервису, вместо включения встроенного потока ACME. Следуйте примеру подключения сертификата в официальном разделе, посвященном существующим сертификатам .

Шаг 7: Откройте пользовательский домен в браузере.

Откройте сайт https://meet.example.comв современном браузере. Вы должны увидеть главную страницу Jitsi под выбранным вами именем хоста с действительным индикатором TLS. Создайте тестовую комнату с временным именем.

Используйте HTTPS для проведения реальных совещаний. В официальном руководстве Docker специально предупреждается, что прямой доступ по HTTP может привести к сбоям в работе API WebRTC браузера, таких как доступ к микрофону и камере. Поэтому HTTPS является частью функциональной конфигурации, а не просто мерой безопасности.

Шаг 8: Проверьте реальный звонок, а не просто главную страницу.

По возможности подключитесь к одной и той же комнате с двух разных устройств или сетей. Убедитесь, что каждый участник может отправлять и получать аудио и видео. Тестирование в двух браузерах важно, поскольку установленная система может корректно отображать веб-сайт, в то время как адрес Videobridge или UDP-путь остаются некорректными.

Для установок, находящихся за NAT, распространенным симптомом является то, что первое соединение кажется нормальным, но передача медиаданных прерывается по мере подключения большего числа участников. В этом случае следует повторно проверить JVB_ADVERTISE_IPSобщедоступное сопоставление NAT и UDP 10000. В руководстве Jitsi прямо указано, что медиа-адрес Videobridge остается актуальным даже при обработке HTTP-трафика обратным прокси-сервером.

Когда следует использовать обратный прокси-сервер вместо этого

Приведенная выше конфигурация подходит, если веб-контейнер Jitsi может использовать публичные порты 80 и 443. Если на этом же сервере уже запущены Nginx, Apache, Caddy, Traefik или другой прокси-сервер на этих портах, не пытайтесь одновременно привязать Jitsi к ним.

Для обратного прокси-сервера на том же хосте официальное руководство по Docker для Jitsi рекомендует отключить HTTPS внутри контейнера Jitsi, избегать публичного доступа к его внутренним веб-портам и перенаправлять запросы на 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`, а затем `compose` docker compose up -d. Также убедитесь, что вы отредактировали .envфайл, используемый проектом Compose, который вы фактически запускаете.

Проверка HTTPS-сертификата завершается неудачей.

Убедитесь, что записи DNS A/AAAA указывают на сервер, получающий запрос, и что публичный порт 80 доступен при использовании встроенного прямого потока сертификатов. docker compose logs webПеред выполнением следующего запроса проверьте наличие точной ошибки ACME.

Страница загружается, но у участников нет ни аудио, ни видео.

Проверьте протокол UDP 10000 и, для развертываний NAT, установите правильное значение JVB_ADVERTISE_IPS. Помните, что обратный прокси обрабатывает веб-трафик; он не заменяет путь к медиафайлам Videobridge.

Браузер работает, но мобильное приложение отклоняет запрос от сервера.

Проверьте цепочку сертификатов. В руководстве по Docker для Jitsi отмечается, что мобильные приложения не работают с самоподписанным сертификатом по умолчанию. Используйте общедоступный доверенный сертификат или инфраструктуру, в которой приложение получает доверенную цепочку сертификатов.

Контрольный список для окончательной проверки

• 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: руководство по самостоятельному размещению — Docker
• docker-jitsi-meet env.example
• Официальный репозиторий docker-jitsi-meet