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

MAATRIX

Owncast — это свой собственный Twitch: RTMP-приём стрима, HLS-раздача зрителям, встроенный чат и админка в одном бинарнике, без зависимости от чужой платформы и её правил модерации. Ставится он действительно быстро, но именно поэтому спотыкаются на мелочах — на сервере с закрытым фаерволом, за реверс-прокси без правильных заголовков, на диске, который через неделю стрима оказывается забит сегментами. Разбираем конкретные ошибки и что с ними делать.

Порт 1935 закрыт — OBS не может начать стрим

Самая частая причина, по которой «стрим не стартует», а на деле — стрим даже не доходит до сервера. OBS показывает «Failed to connect to server» или зависает на подключении, а Owncast в логах вообще молчит: пакеты просто не доходят до RTMP-порта.

Проверьте локальный фаервол:

sudo ufw status
sudo ufw allow 1935/tcp comment 'owncast rtmp'
sudo ufw allow 8080/tcp comment 'owncast web'
sudo ufw reload

Если сервер арендован в облаке — почти всегда есть ещё и фаервол на уровне провайдера (security group / cloud firewall), отдельный от ufw внутри системы. Его тоже нужно открыть на 1935/tcp и 8080/tcp (или на тот порт, который вы указали для веб-интерфейса), иначе внутренний ufw будет чист, а трафик всё равно срежется снаружи.

Проверить, что порт реально слушается процессом owncast, а не просто «открыт в фаерволе»:

sudo ss -tlnp | grep -E '1935|8080'

Если строки нет вообще — Owncast не запущен или упал (см. раздел про systemd ниже). Если строка есть, но подключение всё равно не идёт — проверьте с внешней машины telnet-ом или nc:

nc -zv your-server-ip 1935

Отдельная грабля — двойное NAT или Docker: если Owncast запущен в контейнере, порт нужно явно пробросить наружу (-p 1935:1935 -p 8080:8080), иначе он слушает только внутри контейнерной сети, а снаружи недоступен вообще.

Ошибки ffmpeg: «ffmpeg not found» и обрывы транскодинга

Owncast не кодирует видео сам — он делегирует это ffmpeg-у, и если бинарник не найден или несовместим, стрим либо не стартует, либо падает через минуту-две после начала. В логах это выглядит как unable to find ffmpeg или процесс просто исчезает без явной ошибки.

Проверьте, что ffmpeg вообще установлен и виден системе:

which ffmpeg
ffmpeg -version

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

./owncast -ffmpeg /usr/local/bin/ffmpeg

Если путь неверный (например, после переноса каталога на другой сервер или смены дистрибутива) — Owncast продолжит ссылаться на старый путь. Проверьте, что используется, через страницу диагностики в админке (/admin/hardware показывает загрузку CPU и активность транскодинга) или прямо в логе запуска — путь к ffmpeg печатается при старте.

Второй частый случай — CPU не тянет несколько выходных вариантов качества (adaptive bitrate). Каждая дополнительная дорожка транскодинга — это ещё один поток кодирования почти в реальном времени, и на слабом VPS с 1-2 vCPU второй-третий вариант начинает пропускать кадры или обрывать сегменты. Ориентировочно: passthrough (без перекодирования, просто ретрансляция входящего потока) почти не грузит CPU, а каждая дополнительная адаптивная дорожка в 720p/1080p требует заметной доли ядра — точная цифра зависит от пресета и битрейта, поэтому проверяйте по факту через /admin/hardware, а не по чужим бенчмаркам. Если видите постоянную загрузку CPU под 90-100% при одном зрителе — это почти всегда транскодинг, а не сеть.

Owncast за nginx: не грузится чат, WebSocket рвётся

Если Owncast стоит за nginx как реверс-прокси (а на боевом сервере он почти всегда так и стоит, ради HTTPS), самая типичная жалоба — видео идёт, а чат не подключается или подключается и тут же отваливается. Причина почти всегда одна: nginx не пробрасывает WebSocket-соединение, потому что забыты заголовки апгрейда протокола.

Правильный блок для проксирования Owncast:

server {
    listen 443 ssl;
    server_name stream.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 3600s;
    }
}

Ключевые строки здесь — proxy_http_version 1.1 и пара Upgrade/Connection. Без них nginx работает как обычный HTTP-прокси, чат (который живёт на WebSocket-соединении к /ws) устанавливает handshake и почти сразу рвётся, потому что nginx не понимает, что соединение нужно держать открытым в апгрейженном режиме. proxy_read_timeout тоже важен: значение по умолчанию (обычно 60 секунд) периодически рвёт долгоживущее соединение чата, и зрителям кажется, что чат «глючит» каждую минуту.

После правки конфига — обязательно nginx -t перед перезапуском, чтобы не уронить рабочий сайт опечаткой:

sudo nginx -t && sudo systemctl reload nginx

Более полный разбор настройки самого nginx как прокси — в статье про nginx как реверс-прокси на VPS, там же типовые грабли с апстримами.

Диск быстро заполняется HLS-сегментами

Owncast режет видеопоток на короткие HLS-сегменты (.ts-файлы) в рабочей директории — это нормально, так работает HLS в принципе. Проблема начинается, когда сегменты не удаляются вовремя: либо включена запись прошлых трансляций (VOD), либо настройки хранения выставлены на удержание слишком большого числа сегментов, либо диск на сервере изначально маленький для видео.

Проверить, что именно ест место:

du -sh /path/to/owncast/data/*
df -h

В админке (/admin, раздел настроек видео) стоит явно посмотреть:

• сколько вариантов качества включено одновременно (каждый — своя копия HLS-сегментов);
• включено ли сохранение прошлых трансляций (Video Storage → Store Past Broadcasts) — если да, диск будет расти постоянно, а не только во время эфира;
• настроена ли выгрузка в S3-совместимое хранилище для сегментов и VOD — это снимает нагрузку с локального диска сервера полностью, но требует отдельного бакета и ключей доступа.

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

Owncast не стартует или падает без причины

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

Если Owncast запущен как systemd-сервис, первым делом смотрим статус и живой лог:

sudo systemctl status owncast
sudo journalctl -u owncast -f --since "10 min ago"

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

• порт уже занят — предыдущий процесс owncast не завершился корректно и всё ещё держит 8080 или 1935; найдите и добейте его: sudo lsof -i :8080 и kill <pid>;
• нет прав на директорию данных — если сервис запущен от отдельного пользователя (что правильно с точки зрения безопасности), а каталог data/ принадлежит root, запись в базу и на диск падает с ошибкой доступа; поправьте владельца: sudo chown -R owncast:owncast /path/to/owncast/data;
• заблокированная база — SQLite-база Owncast не любит одновременного доступа двух процессов; если сервис перезапускался некорректно (например, kill -9 вместо graceful stop), файл базы может остаться заблокированным до перезагрузки или ручной проверки целостности.

Минимальный юнит systemd, если настраиваете с нуля:

[Unit]
Description=Owncast streaming server
After=network.target

[Service]
Type=simple
User=owncast
WorkingDirectory=/opt/owncast
ExecStart=/opt/owncast/owncast
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Restart=on-failure спасает от разовых сбоев, но если сервис уходит в цикл рестартов — это симптом, а не решение, разбирайтесь по логу, а не полагайтесь на автоперезапуск.

HTTPS и админка: сертификат и доступ

Owncast сам по себе отдаёт только HTTP — HTTPS вешается через реверс-прокси (см. раздел про nginx выше) с сертификатом Let's Encrypt. Если сертификат не выпускается, чаще всего дело в том, что домен ещё не указывает на IP сервера на момент проверки ACME, либо порт 80 занят самим Owncast и недоступен для HTTP-01 challenge. Подробный разбор именно этой темы — в статье про установку Let's Encrypt SSL на VPS.

Отдельно: не забудьте про смену пароля админки и стрим-ключа сразу после установки. Owncast генерирует их автоматически при первом запуске (или использует значения по умолчанию, если не переопределены при установке) — если оставить дефолтные значения на сервере, доступном из интернета, чат и трансляцию рано или поздно займёт кто-то посторонний. Смена делается прямо в админке (/admin → Config → Server Setup), новый стрим-ключ нужно будет прописать и в OBS в поле Stream Key.

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