RTMP relay на VPS: как сделать restream через Nginx RTMP и не упереться в канал

RTMP relay на VPS нужен, когда один видеопоток нужно отправить сразу на несколько площадок: YouTube, Twitch, Facebook Live, Kick, собственный ingest-сервер, закрытую трансляцию или резервную платформу. Вместо того чтобы OBS или другой encoder отправлял несколько потоков напрямую с вашего компьютера, он отправляет один поток на VPS, а VPS уже раздает его дальше.

Главная боль такого сценария — restream. У пользователя дома или в офисе может быть хороший download, но слабый upload. Если отправлять поток 6 Mbps сразу на три платформы, локальный интернет должен стабильно отдавать не 6 Mbps, а примерно 18 Mbps плюс запас. RTMP relay решает именно эту проблему: с вашей стороны уходит один поток, а размножение трафика делает VPS с хорошим каналом.

Но здесь нельзя обманывать себя: RTMP relay не делает видео “легче”. Он просто переносит нагрузку с вашего локального upload на VPS. Если VPS слабый по сети, имеет маленький лимит трафика или нестабильный маршрут до площадок, restream будет сыпаться, даже если Nginx настроен правильно.

Что такое RTMP relay простыми словами

RTMP relay — это промежуточный сервер между вашим encoder и конечными платформами. Например, OBS отправляет один RTMP-поток на VPS. На VPS работает Nginx с RTMP-модулем. Он принимает входящий поток и через директивы push отправляет его дальше на нужные RTMP ingest URL.

Типовая схема выглядит так:

• OBS, vMix, Wirecast или FFmpeg кодирует видео.
• Encoder отправляет один поток на ваш VPS.
• Nginx RTMP принимает поток на порту 1935.
• VPS отправляет этот поток на одну или несколько платформ.
• Платформы уже раздают видео зрителям.

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

Когда RTMP relay на VPS действительно нужен

RTMP relay имеет смысл не всегда. Его стоит использовать, когда есть понятная техническая причина.

• Нужно одновременно стримить на несколько платформ.
• Локальный upload не выдерживает несколько исходящих потоков.
• Нужен один стабильный ingest endpoint для OBS.
• Нужно быстро менять конечные площадки на стороне сервера, не трогая OBS.
• Нужно отделить студийный интернет от restream-нагрузки.
• Нужно резервировать трансляцию на вторую платформу.
• Нужно принимать поток из одной локации и отправлять его дальше через VPS с лучшим маршрутом.
• Нужно сделать простой приватный relay без покупки отдельного SaaS-restream сервиса.

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

Когда VPS не спасет трансляцию

VPS не исправит плохой исходный поток. Если encoder перегружен, bitrate скачет, кадры дропаются уже в OBS, локальный upload нестабилен даже для одного потока или компьютер не тянет кодирование, RTMP relay не сделает картинку стабильной.

Перед переносом restream на VPS проверьте:

• OBS не показывает dropped frames из-за encoding lag.
• OBS не показывает dropped frames из-за network lag при отправке одного потока.
• Локальный upload стабильно держит bitrate одного потока с запасом.
• Кодек, разрешение, FPS и keyframe interval подходят конечным платформам.
• Проблема возникает именно при отправке на несколько площадок, а не при одном потоке.

Если один поток уже нестабилен, сначала чините encoder, локальную сеть и upload. Если один поток стабилен, но несколько платформ ломают трансляцию, RTMP relay на VPS — правильный следующий шаг.

Главная формула restream: трафик умножается

Самая частая ошибка — считать только входящий поток. На самом деле VPS получает один поток и отправляет его на каждую площадку отдельно.

Формула простая:

исходящий трафик VPS = bitrate потока × количество направлений

Если вы отправляете 6 Mbps на три платформы, VPS будет отдавать примерно 18 Mbps плюс служебный overhead. Если 8 Mbps на пять платформ, это уже около 40 Mbps постоянного исходящего трафика. Это не пиковая нагрузка, а постоянная нагрузка на все время трансляции.

Поэтому для RTMP relay важнее high bandwidth и честный лимит трафика, чем “много ядер CPU”. Если поток не перекодируется, CPU обычно не является главным узким местом. Узкое место — сеть.

Какой VPS нужен для Nginx RTMP relay

Для простого RTMP relay без transcoding достаточно небольшого VPS, но с нормальной сетью. Ошибка — брать самый дешевый VPS с маленьким лимитом трафика и ожидать, что он будет стабильно пушить несколько HD-потоков.

Минимальный вариант для тестов:

• 1-2 vCPU;
• 1-2 GB RAM;
• 20 GB SSD/NVMe;
• 1 публичный IPv4;
• порт 100 Mbps или выше;
• Ubuntu 22.04/24.04 или Debian 12;
• доступ по SSH;
• нормальный лимит исходящего трафика.

Комфортный вариант для регулярных трансляций:

• 2-4 vCPU;
• 2-4 GB RAM;
• 40+ GB SSD/NVMe;
• 1 публичный IPv4;
• порт 1 Gbps;
• большой monthly traffic allowance или high bandwidth-тариф;
• локация с хорошим маршрутом до encoder и платформ;
• мониторинг сети и нагрузки;
• резервный план на случай падения VPS.

Если нужна запись трансляции на VPS, требования к диску растут. Если нужно транскодировать поток, делать несколько качеств, накладывать overlay или менять codec, требования к CPU резко растут. Для транскодинга лучше сразу рассматривать более мощный VPS, dedicated server или отдельную архитектуру с FFmpeg и мониторингом.

Как выбрать локацию VPS для restream

Локация VPS влияет на две стороны: путь от encoder до VPS и путь от VPS до стриминговых платформ.

Если вы стримите из Европы, обычно логично выбирать европейский VPS: Нидерланды, Германия, Великобритания или ближайшую стабильную локацию. Если encoder находится в Азии, стоит смотреть Сингапур или другой близкий регион. Если основная платформа или аудитория завязана на США, может иметь смысл американская локация, но нужно учитывать задержку от encoder до VPS.

Неправильный подход — выбирать страну только по цене. Для live video важна стабильность маршрута. Плохой маршрут даст reconnect, buffering, dropped frames и нестабильный ingest, даже если сервер формально имеет хороший тариф.

Почему Nginx RTMP подходит для простого restream

Nginx RTMP module хорошо подходит для простого сценария: принять RTMP-поток и отправить его на несколько RTMP endpoints. Он легкий, распространенный, понятный и не требует тяжелой медиаплатформы, если задача ограничена relay.

Типовые возможности, которые полезны для restream:

• прием RTMP-потока от OBS или FFmpeg;
• push одного входящего потока на несколько RTMP-адресов;
• ограничение publish по IP или через callback;
• статистика RTMP-сессий;
• запись потока при необходимости;
• HLS/DASH output для отдельных сценариев;
• запуск FFmpeg через exec для дополнительных задач.

Но Nginx RTMP — не полноценная SaaS-панель restream. Если вам нужны пользователи, биллинг, динамическое добавление направлений, управление stream keys из веб-интерфейса, retry-логика, роли, webhook, статистика по клиентам и API, голый nginx.conf быстро станет неудобным.

Простая схема Nginx RTMP restream

Базовая схема:

• OBS отправляет поток на rtmp://VPS_IP/live/STREAM_KEY.
• Nginx RTMP принимает поток в application live.
• В конфиге указаны push-направления.
• Поток уходит на YouTube, Twitch или другие RTMP endpoints.

Пример логики конфига:

application live { live on; push rtmp://destination-1/live/key; push rtmp://destination-2/live/key; }

На практике stream keys нельзя хранить и передавать как обычный текст без осторожности. Ключи платформ дают право публиковать трансляцию. Если они утекут, кто-то сможет стримить на ваши каналы.

Что лучше: Nginx RTMP push или FFmpeg restream

Для простого копирования одного RTMP-потока на несколько RTMP-направлений Nginx RTMP push обычно проще. Он принимает поток и пушит его дальше без перекодирования.

FFmpeg нужен, если нужно больше контроля:

• транскодировать видео;
• менять bitrate;
• менять разрешение;
• делать разные профили качества;
• отправлять в протокол или endpoint, который Nginx RTMP не обрабатывает удобно;
• делать overlay, watermark или audio processing;
• оборачивать RTMP в RTMPS через отдельную схему;
• гибко логировать ошибки отправки.

Но FFmpeg потребляет больше CPU, если идет перекодирование. Если задача только “один поток размножить на три платформы”, не надо усложнять. Начните с Nginx RTMP relay без transcoding.

RTMP, RTMPS и ограничения платформ

Некоторые платформы принимают обычный RTMP, некоторые рекомендуют или требуют RTMPS, а правила ingest могут меняться. Поэтому нельзя один раз написать конфиг и считать его вечным.

Перед запуском проверьте для каждой платформы:

• какой ingest URL используется;
• RTMP или RTMPS нужен;
• какой stream key актуален;
• есть ли требования к bitrate;
• есть ли требования к keyframe interval;
• какие codec и audio settings поддерживаются;
• не истек ли одноразовый stream key;
• не запрещает ли платформа конкретный тип restream.

Если платформа требует RTMPS, а ваша текущая сборка Nginx RTMP не умеет пушить туда напрямую, не нужно ломать всю архитектуру. Часто проще использовать отдельный FFmpeg-процесс, stunnel, SRS или другой медиасервер, который лучше подходит для конкретного протокола.

Защита publish endpoint

Открытый RTMP publish endpoint — плохая идея. Если любой человек может отправить поток на ваш VPS, рано или поздно туда начнут лить мусор, тесты, чужой контент или abuse.

Минимальная защита:

• использовать сложный stream key;
• не публиковать ingest URL в открытом доступе;
• ограничить publish по IP, если у encoder статический IP;
• закрыть play, если зрители не должны смотреть поток с VPS;
• использовать firewall;
• смотреть логи подключений;
• не оставлять тестовые stream keys;
• не хранить ключи платформ в публичном репозитории.

Если у вас статический IP в студии, можно разрешить publish только с него. Если IP динамический, используйте сложный stream key и по возможности callback-авторизацию через on_publish. Для коммерческого сценария лучше делать отдельную авторизацию, а не надеяться только на секретную строку в URL.

Нужно ли открывать port 1935 всем

Для RTMP ingest порт 1935 должен быть доступен encoder-у. Но это не значит, что его нужно открывать для всего мира без ограничений.

Если источник один и IP известен, лучше разрешить доступ только с IP encoder. Если источников несколько или IP меняется, порт придется открыть шире, но тогда защита stream key и логирование становятся обязательными.

Не открывайте лишние порты:

• RTMP 1935 — только если нужен ingest или play.
• HTTP/HTTPS — только если нужны HLS, статистика или веб-интерфейс.
• SSH — лучше ограничить по IP или использовать ключи.
• Статистику Nginx RTMP не открывать публично без авторизации.

Главное правило: VPS для relay должен принимать только то, что нужно для трансляции. Все остальное закрывается.

Почему не стоит отдавать зрителей напрямую с VPS

RTMP relay для restream и полноценная видеоплатформа — разные задачи. Если вы отдаете поток тысячам зрителей напрямую с VPS, трафик растет уже не по количеству платформ, а по количеству зрителей.

Пример: поток 6 Mbps и 100 зрителей — это около 600 Mbps постоянного исходящего трафика. 500 зрителей — около 3 Gbps. Для обычного VPS это уже совсем другая задача.

Для зрителей обычно лучше использовать платформы или CDN. VPS в этой схеме принимает один поток и отправляет его на платформы, а не становится публичным CDN для всех зрителей.

HLS на VPS: когда нужен и когда нет

Nginx RTMP может делать HLS, но для простого restream на YouTube/Twitch это обычно не нужно. HLS полезен, если вы хотите дать веб-плеер, приватный просмотр или внутреннюю трансляцию через браузер.

Но HLS добавляет новые задачи:

• нужно хранить сегменты на диске или tmpfs;
• нужно отдавать HTTP-трафик зрителям;
• растет нагрузка на сеть;
• нужна защита доступа;
• нужны CORS, MIME-типы и правильный cache-control;
• при большом числе зрителей нужен CDN.

Если задача только restream, не добавляйте HLS “на всякий случай”. Чем меньше лишних компонентов в live-схеме, тем меньше точек отказа.

Запись трансляции на VPS

Nginx RTMP может записывать поток, но запись резко меняет требования к диску и эксплуатации. Если пишете каждую трансляцию, нужно следить за свободным местом, ротацией файлов и скоростью диска.

Перед включением записи решите:

• нужно ли записывать весь поток или только резервную копию;
• сколько часов хранить записи;
• какой bitrate и размер файлов ожидается;
• куда выгружать архив;
• что делать при заполнении диска;
• нужны ли права доступа к записям;
• как удалять старые файлы.

Плохая практика — включить запись и забыть. Когда диск заполнится, могут начаться ошибки не только записи, но и работы сервисов на VPS.

Как рассчитать трафик для RTMP relay

Для грубой оценки используйте формулу:

трафик за час в GB ≈ bitrate Mbps × 0.45 × количество направлений

Пример: поток 6 Mbps на 3 платформы.

6 × 0.45 × 3 = 8.1 GB в час

Если трансляция идет 4 часа:

8.1 × 4 = 32.4 GB

Если таких трансляций 20 в месяц:

32.4 × 20 = 648 GB в месяц

Это только исходящий restream-трафик. Добавьте входящий поток, тесты, повторы, записи, HLS и запас. Для регулярных трансляций high bandwidth VPS или сервер с большим traffic allowance лучше, чем минимальный VPS с красивой ценой.

Что важнее: CPU, RAM или bandwidth

Если VPS только принимает RTMP и пушит поток дальше без перекодирования, главный ресурс — bandwidth. CPU и RAM обычно важны меньше.

CPU становится важен, если вы:

• транскодируете поток;
• делаете несколько quality profiles;
• меняете разрешение;
• накладываете watermark;
• перекодируете audio;
• используете FFmpeg для каждого направления;
• делаете запись и обработку файлов;
• запускаете дополнительные сервисы на том же VPS.

RAM важна для стабильности системы, Nginx, FFmpeg, логов и вспомогательных сервисов. Для простого relay 1-2 GB RAM часто достаточно, но для production лучше иметь запас, чтобы не ловить OOM в неподходящий момент.

Мониторинг RTMP relay

Live streaming без мониторинга — слепой риск. Если трансляция упала, вы должны узнать об этом раньше зрителей.

Минимально стоит мониторить:

• доступность VPS;
• CPU load;
• RAM;
• network in/out;
• диск, если включена запись;
• статус nginx;
• RTMP sessions;
• ошибки в nginx logs;
• reconnect от encoder;
• наличие потока на конечных платформах.

Nginx RTMP может отдавать статистику, но ее нельзя просто открыть всему интернету. Закройте endpoint статистики авторизацией, VPN или allowlist IP.

Что делать, если restream лагает

Не переустанавливайте сервер сразу. Диагностируйте по цепочке.

• Проверьте OBS: есть ли dropped frames.
• Проверьте upload от encoder до VPS.
• Проверьте ping и packet loss до VPS.
• Проверьте network out на VPS.
• Проверьте CPU на VPS.
• Проверьте логи nginx.
• Проверьте, не падает ли push только на одну платформу.
• Проверьте требования платформы к bitrate, FPS и keyframe interval.
• Проверьте, не уперлись ли в traffic shaping или лимит порта.
• Проверьте, не идет ли одновременно запись, HLS и transcoding.

Если входящий поток на VPS уже плохой, проблема до VPS. Если входящий поток стабильный, но одна платформа лагает, проблема может быть в маршруте от VPS до этой платформы или в настройках ingest. Если все направления лагают одновременно, смотрите сеть VPS, CPU, лимиты и конфиг.

Что делать, если одна платформа не принимает поток

Если YouTube принимает поток, а другая платформа нет, Nginx RTMP может быть ни при чем. Проверьте конкретное направление.

• Правильный ли RTMP/RTMPS URL.
• Актуальный ли stream key.
• Не истек ли временный ключ.
• Совпадает ли формат видео с требованиями платформы.
• Поддерживается ли выбранный bitrate.
• Правильный ли keyframe interval.
• Нет ли ограничений аккаунта на live streaming.
• Не требуется ли старт трансляции в панели платформы.
• Не заблокирован ли ingest endpoint по региону или сети.

Хорошая практика — тестировать каждое направление отдельно, а потом включать их вместе. Иначе сложно понять, какая именно площадка ломает restream.

Что делать, если OBS не подключается к VPS

Проверяйте базовые вещи:

• VPS включен и доступен.
• Nginx запущен.
• Порт 1935 слушается.
• Firewall разрешает входящий RTMP от вашего IP.
• OBS использует правильный URL.
• Stream key указан правильно.
• В nginx.conf есть нужное application.
• В логах nginx нет reject по access rule.
• Провайдер локального интернета не блокирует исходящий RTMP.

Команды для проверки на VPS:

systemctl status nginx

ss -tulpn | grep 1935

tail -f /var/log/nginx/error.log

ufw status verbose

Если порт 1935 не слушается, проблема в Nginx или модуле RTMP. Если слушается, но подключение не доходит, смотрите firewall, IP allowlist и маршрут от encoder до VPS.

Почему не стоит компилировать все вручную без причины

Во многих старых гайдах Nginx RTMP ставят через ручную сборку Nginx из исходников. Это работает, но для production у новичка создает проблемы: обновления, systemd unit, совместимость модулей, безопасность и повторяемость установки.

Если в вашем дистрибутиве есть пакет libnginx-mod-rtmp или готовая поддерживаемая сборка, лучше начать с нее. Ручная компиляция оправдана, когда нужен конкретный патч, версия или нестандартный модуль. Для простого relay это часто лишняя сложность.

Если используете Docker-образ с Nginx RTMP, проверяйте, кто его поддерживает, как обновлять image, где лежит конфиг, как сохраняются логи и как проброшены порты. Нельзя брать случайный image и ставить его в production без понимания.

Динамический restream: где начинается сложность

Статический restream прост: в конфиге заранее прописаны направления push. Динамический restream сложнее: сегодня нужно пушить на YouTube и Twitch, завтра на Facebook, послезавтра на разные каналы разных клиентов.

Если направлений много и они часто меняются, голый nginx.conf станет неудобным. Придется либо перегенерировать конфиги и reload nginx, либо использовать HTTP callbacks, либо строить отдельную панель управления, либо выбирать медиасервер/платформу, где динамические push-направления реализованы лучше.

Для одного владельца канала статического конфига обычно достаточно. Для multi-user restream сервиса нужен другой уровень архитектуры: авторизация, база направлений, шифрование stream keys, API, retry, мониторинг, лимиты клиентов и защита от abuse.

Резервирование RTMP relay

Один VPS — одна точка отказа. Если трансляции коммерческие, нужен резервный план.

Варианты:

• резервный VPS в другой локации;
• второй ingest URL в OBS;
• резервный encoder;
• локальная запись в OBS;
• резервная платформа;
• мониторинг доступности relay;
• быстрая переустановка по готовому конфигу;
• хранение nginx.conf и секретов в безопасном месте.

Для тестовой трансляции можно жить с одним VPS. Для платного вебинара, конференции, спортивного события или запуска продукта одного relay без резерва мало.

Безопасность stream keys

Stream key — это доступ к публикации. Его нельзя хранить в открытом виде в публичных репозиториях, скриншотах, чатах и документах без доступа.

Что нужно делать:

• хранить ключи в закрытом месте;
• ограничивать доступ к серверу;
• не давать всем подряд root-доступ;
• не показывать nginx.conf на стримах или скриншотах;
• обновлять ключи при подозрении на утечку;
• использовать отдельные ключи для разных платформ;
• не использовать один общий stream key для разных проектов.

Если сервер обслуживает несколько клиентов, хранение ключей становится отдельной задачей безопасности. Нельзя складывать все stream keys в один конфиг без контроля доступа и считать это нормальной системой.

Какой VPS выбрать в HSTQ для RTMP relay

Для RTMP relay в HSTQ стоит выбирать VPS/VDS с публичным IPv4, стабильной сетью и достаточным лимитом исходящего трафика. Если задача — один поток на две-три платформы без transcoding, обычно нужен не сверхмощный CPU, а нормальный bandwidth и подходящая локация.

Если планируются регулярные трансляции, несколько направлений, запись, HLS или пиковые нагрузки, лучше сразу смотреть high bandwidth VPS или dedicated server. Экономия на маленьком тарифе может закончиться reconnect во время эфира, а это хуже, чем немного больший счет за сервер.

Посмотреть VPS/VDS можно здесь: https://cp.hstq.net/store/vps-vds-nmve.

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

Практический чек-лист перед эфиром

• Один поток из OBS стабильно доходит до VPS.
• Nginx RTMP принимает поток без reconnect.
• Каждое push-направление протестировано отдельно.
• Все платформы получают правильный bitrate, codec, FPS и keyframe interval.
• Network out на VPS не упирается в лимит.
• CPU и RAM имеют запас.
• Порт 1935 защищен или ограничен.
• Статистика и служебные endpoints не открыты публично.
• Stream keys не лежат в открытом доступе.
• Если включена запись, на диске достаточно места.
• Есть резервный план на случай падения VPS.
• OBS пишет локальную копию, если эфир важный.

RTMP relay на VPS — хороший инструмент для restream, если использовать его по назначению. Он снижает нагрузку на локальный upload, дает единый ingest endpoint и позволяет отправлять поток на несколько платформ. Но он не отменяет требования к сети, лимитам трафика, безопасности и мониторингу.

Правильная схема простая: один стабильный поток от encoder до VPS, Nginx RTMP без лишнего transcoding, push только на нужные платформы, high bandwidth с запасом, закрытые служебные endpoints и проверка каждого направления до эфира. Тогда VPS становится надежным relay-узлом, а не случайной точкой отказа посреди трансляции.