Jitsi Meet на сервере: частые ошибки и решения

MAATRIX

Jitsi Meet — самый популярный self-hosted аналог Zoom: участники заходят по ссылке в браузере, ничего не устанавливают, а видео и звук идут через ваш собственный сервер. Разворачивается он обычно за 15 минут через docker-jitsi-meet, но именно после этого начинаются вопросы — камера не включается, собеседники видят чёрный экран друг у друга, конференция зависает на «Setup failed». Ниже — конкретные причины и то, как их закрыть, без переустановки всего с нуля.

Камера и микрофон не запрашиваются или браузер их блокирует

Самая частая жалоба новичков: страница конференции открывается, а окна запроса доступа к камере/микрофону просто нет, или в консоли браузера ошибка getUserMedia is not defined. Причина почти всегда одна — браузеры разрешают доступ к медиаустройствам только по HTTPS (кроме localhost). Если вы зашли на Jitsi по http:// или используете самоподписанный сертификат, часть браузеров (особенно Chrome и Firefox в последних версиях) просто не показывает диалог разрешения.

Проверьте, что сервер действительно отдаёт валидный сертификат:

curl -vI https://meet.your-domain.ru 2>&1 | grep -i "SSL certificate"

Если сертификата нет или он самоподписанный, в docker-jitsi-meet включите штатный Let's Encrypt — в файле .env:

ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.your-domain.ru
LETSENCRYPT_EMAIL=you@your-domain.ru

и перезапустите стек:

docker compose down
docker compose up -d
docker logs jitsi-web --tail 50

Второй частый вариант — доступ реально запрашивается, но пользователь один раз нажал «Заблокировать» и браузер это запомнил. Проверьте иконку замка в адресной строке → «Настройки сайта» → «Камера/Микрофон» → «Разрешить». Это не баг сервера, но именно с этого стоит начинать диагностику, прежде чем копать глубже.

Участники подключаются, но не видят и не слышат друг друга

Это самая неприятная категория ошибок: конференция открывается, список участников заполняется, а видео/звук не идёт — обычно виноват Jitsi Videobridge (JVB), который не может пробросить медиапоток через NAT вашего VPS.

JVB по умолчанию слушает UDP-порт 10000 и должен «знать» свой публичный адрес, чтобы сказать браузерам клиентов, куда слать RTP-пакеты. Если сервер стоит за NAT (типично для облачных VPS, где внутренний IP отличается от внешнего), а .env этого не учитывает — участники из разных сетей просто не достучатся друг до друга, хотя сигнальный канал (XMPP) работает нормально.

Проверьте и пропишите в .env:

DOCKER_HOST_ADDRESS=203.0.113.10
JVB_ADVERTISE_IPS=203.0.113.10

где 203.0.113.10 — реальный публичный IP сервера (узнать: curl -4 ifconfig.me). После правки — обязательно пересоздать контейнер JVB, а не просто рестарт:

docker compose up -d --force-recreate jvb

Убедитесь также, что UDP-порт 10000 открыт в фаерволе — это частая причина, когда всё настроено правильно, но пакеты просто режутся на входе:

ufw allow 10000/udp
ufw status

Если сервер за NAT провайдера (не публичный IP напрямую, а проброс портов через роутер/облако) — TCP-fallback на порту 4443 спасает не всегда, лучше сразу проверить, что провайдер даёт «чистый» публичный IPv4 без двойного NAT. Подробнее про настройку самого фаервола под такие сценарии — в статье про UFW на сервере.

Конференция зависает на «Setup failed» или бесконечной загрузке

Если пользователь видит логотип Jitsi и надпись «Setup failed, retry in 3…2…1», сигнальный канал не может подняться — это почти всегда проблема связки Prosody (XMPP-сервер) ↔ Jicofo (управление конференциями) ↔ web-контейнер, а не проблема с видео.

Смотрите логи в таком порядке:

docker logs jitsi-prosody --tail 100
docker logs jitsi-jicofo --tail 100
docker logs jitsi-web --tail 100

Частые находки:

• В логах prosody ошибка Failed to open socket — контейнеры на разных Docker-сетях, docker-compose.yml был отредактирован вручную и потерял общую сеть meet.jitsi.
• В jicofo Failed to allocate channels — no bridges available — JVB не подключился к прosody вообще (проверьте docker logs jvb, там обычно видна причина: неверный пароль в .env между JICOFO_AUTH_PASSWORD и JVB_AUTH_PASSWORD, они должны совпадать с тем, что сгенерировано при первой установке).
• Контейнеры вообще не стартуют после git pull обновления docker-jitsi-meet — почти всегда несовместимость версии .env со свежим docker-compose.yml; сравните свой .env со свежим env.example из репозитория и добавьте недостающие переменные, не удаляя старые с уже сгенерированными паролями.

Если меняли .env, помните: часть переменных (пароли XMPP, JWT-секреты) читаются контейнерами один раз при старте и требуют --force-recreate, простого restart недостаточно.

Nginx перед Jitsi отдаёт 502 или рвёт WebSocket

Если вы ставите перед docker-jitsi-meet собственный nginx как reverse proxy (например, чтобы держать на одном сервере несколько сервисов на 443-м порту), велик шанс словить 502 Bad Gateway или разрыв соединения через несколько секунд после входа. Причина — Jitsi активно использует WebSocket (/xmpp-websocket и /colibri-ws) для сигнального канала и статистики моста, а стандартный nginx-конфиг не пробрасывает Upgrade/Connection заголовки.

Пример рабочего блока для внешнего nginx (Jitsi слушает локально на 8443, отдав внешний 443 самому nginx):

location /xmpp-websocket {
    proxy_pass https://127.0.0.1:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    tcp_nodelay on;
}

location /colibri-ws/ {
    proxy_pass https://127.0.0.1:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

location / {
    proxy_pass https://127.0.0.1:8443;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_ip;
    proxy_set_header X-Forwarded-Proto https;
}

Проще всего избежать этой возни вообще — не ставить внешний nginx перед Jitsi, а отдать ему 443-й порт напрямую (штатный docker-jitsi-meet уже включает свой web-контейнер с nginx внутри и сам получает Let's Encrypt). Внешний прокси нужен только если на одном IP крутится несколько разных сервисов. Общие принципы настройки reverse proxy и типовые грабли с WebSocket разобраны в статье про nginx как reverse proxy.

Сертификат не обновляется автоматически или Let's Encrypt отказывает

docker-jitsi-meet со встроенным ENABLE_LETSENCRYPT=1 обновляет сертификат сам через cron внутри контейнера web, но если DNS-запись на домен указывает не туда (например, вы сменили IP сервера при переезде и забыли поправить A-запись) — валидация ACME challenge падает молча, а старый сертификат продолжает работать до истечения 90 дней, что маскирует проблему.

Проверьте вручную:

dig +short meet.your-domain.ru
docker exec jitsi-web certbot certificates

Если IP не совпадает с реальным адресом сервера — правьте DNS у регистратора. Если DNS верный, а challenge всё равно падает — почти всегда виноват фаервол или другой сервис, занявший 80-й порт (ACME HTTP-01 challenge идёт именно по нему, даже если сайт работает на 443).

Типовые причины ошибок Let's Encrypt (превышение лимита запросов, неверный challenge, отсутствие автопродления) разобраны отдельно и актуальны в том числе для Jitsi — см. частые ошибки Let's Encrypt.

Сервер не тянет нагрузку: тормоза при росте числа участников

Jitsi не бесплатен по ресурсам — видео каждого участника с включённой камерой транслируется через JVB, и мост тратит CPU на пересылку и адаптацию потоков (simulcast). На слабом VPS (1-2 vCPU) конференция из 3-4 человек с видео у всех уже может ощутимо грузить процессор и давать заметные лаги.

Что реально помогает:

• Отключить видео у части участников (только звук) для больших встреч — самый действенный и бесплатный способ снизить нагрузку.
• В .env ограничить качество исходящего видео по умолчанию — RESOLUTION=480 вместо 720 заметно снижает нагрузку на кодирование/декодирование у JVB и у самих клиентов.
• Следить за метриками моста — у JVB есть встроенная страница статистики (colibri REST API), полезно смотреть bitrate и packet_loss при жалобах на качество.
• При регулярных конференциях от 15-20 человек с видео закладывайте минимум 4 vCPU / 8 ГБ RAM — но это ориентир, не точная цифра: реальное потребление сильно зависит от того, сколько участников включают камеру одновременно и в каком разрешении, проверяйте на своей нагрузке.
• Для действительно больших событий (сотни участников) в Jitsi есть режим Octo — горизонтальное масштабирование через несколько JVB-нод, но это отдельная тема настройки, а не быстрый фикс.

Ресурсы сервера имеет смысл выбирать под свой типичный сценарий использования заранее, а не расширять их «постфактум» посреди рабочих созвонов — на VPS с NVMe и достаточным запасом CPU JVB работает предсказуемо стабильнее.

Частые вопросы