Свой сервер для стрима: канал, кодеки и задержка эфира

Отдельный сервер для стрима нужен тогда, когда одного канала на чужой площадке уже мало: вы хотите вести эфир сразу на несколько сервисов, писать архив, показывать плеер на своём сайте или укоротить задержку. Технически это обычный виртуальный сервер (VPS) — арендованная часть физической машины, где вы сами ставите софт и открываете порты; подходящие тарифы собраны в разделе VPS для сайтов и приложений. Компьютер стримера при такой схеме отдаёт наружу один поток, а размножает его уже сервер.

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

Что делает сервер трансляций и когда он окупается

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

Смысл появляется в момент, когда потоков становится больше одного. Домашний интернет обычно асимметричен: приём 100 Мбит/с, а отдача 20–30 Мбит/с. Один эфир 1080p при 6 Мбит/с такой канал вытянет, но три копии на три площадки — уже нет: они требуют около 18 Мбит/с чистого исходящего трафика плюс запас.

Вторая причина — независимость: если видео идёт со своего домена, плеер, страница и архив принадлежат вам. Третья — стабильность: у машины в дата-центре нет ни соседей по Wi-Fi, ни ночных перебоев у провайдера. Не окупается сервер в одном случае: когда вы ведёте один эфир на одну площадку и домашней отдачи хватает.

Битрейт и канал: главный расчёт перед арендой

Битрейт — это сколько данных в секунду занимает видео. Именно он, а не разрешение само по себе, определяет требования к каналу: поток 1080p при 6 Мбит/с — это 6 мегабит, уходящих в сеть каждую секунду.

Канал берут с запасом минимум в полтора раза от суммы всех исходящих потоков, поэтому 1080p на 6 Мбит/с требует отдачи от 10 Мбит/с. Запас уходит на всплески битрейта в динамичных сценах и повторную отправку потерянных пакетов.

Цифры ориентировочные: точное значение зависит от подвижности картинки, а строка 1080p/60 — базовый расчёт, если свой битрейт вы не знаете. Тарифы начального уровня дают порт 100 Мбит/с или 1 Гбит/с, так что упираются обычно не в скорость, а в лимит трафика. При ежедневных эфирах смотрите раздел VPS без лимита трафика.

Сколько трафика съедает месяц эфиров

Перевести мегабиты в гигабайты просто: делите битрейт на 8 и умножайте на секунды. Поток 6 Мбит/с — это 0,75 МБ в секунду, то есть примерно 2,7 ГБ за час эфира.

Дальше арифметика. Эфир на 4 часа — около 11 ГБ отдачи на одну площадку, а ретрансляция на три утраивает объём до 32 ГБ. Двадцать эфиров в месяц дают порядка 650 ГБ — без учёта зрителей, которые смотрят прямо с вашего сервера.

Кодеки и транскодирование: где сервер упирается в процессор

Кодек — это алгоритм сжатия видео. Практический стандарт для трансляций — H.264: его понимают все площадки и все браузеры. Более новый H.265 сжимает то же качество примерно на 30–40 % компактнее, но принимают его далеко не везде.

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

Транскодирование на лету упирается в процессор и требует от 4 ядер. Одна пересборка 1080p в реальном времени съедает 2–3 виртуальных ядра целиком; чтобы отдать зрителю лесенку из 1080p, 720p и 480p, закладывайте 6–8 ядер. Экономить тут нельзя: как только процессор не успевает, кодировщик пропускает кадры, и это видно в эфире сразу. Если несколько качеств не нужны, перекодирование лучше не включать вовсе — тогда хватит тарифа на 1 ядро и 1 ГБ памяти.

Задержка: почему «прямой эфир» идёт с опозданием

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

Величина зависит от протокола доставки. RTMP — старый протокол публикации потока, который принимают почти все площадки; через сервер он даёт 3–8 секунд. HLS нарезает видео на файлы-сегменты, и плеер копит их перед стартом: при сегментах по 6 секунд типичная задержка выходит 20–30 секунд. Режим LL-HLS с сегментами по 1–2 секунды укорачивает её до 3–5 секунд.

Задержка ниже 5 секунд достигается только на низкоуровневых протоколах, которые не разбивают поток на файлы. WebRTC — технология передачи медиа прямо между браузерами — доводит показатель до 0,5–1 секунды, но платит за это сложностью настройки и жадностью к ресурсам. Протокол SRT даёт 1–2 секунды и хорошо переносит потери в сети. Выбирайте по задаче: для лекции или концерта 20 секунд никто не заметит, а для аукциона или викторины со зрителями критична каждая секунда.

Какая конфигурация нужна под ваш сценарий

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

Память сам процесс раздачи расходует скромно, сотнями мегабайт. Основные потребители — перекодирование (процессор) и запись архива (диск). Диск берите на NVMe: запись эфира идёт непрерывным потоком, и медленный накопитель тут заметен.

Час записи 1080p при 6 Мбит/с — те же 2,7 ГБ, то есть на 100 ГБ помещается около 37 часов эфира. Под полный архив за год сразу смотрите тарифы из раздела VPS с большим диском.

Сколько стоит сервер для стрима

В разделе VPS каталога сейчас 44 провайдера, и стартовые тарифы отличаются в разы. Для ретрансляции без перекодирования подходит нижний ценовой ярус: 1 ядро и 1 ГБ памяти для пересылки потока достаточно.

Данные проверены 04.09.2026.

Стартовая цена — это вход в линейку, а не цена вашей будущей конфигурации: тариф на 4 ядра и 4 ГБ обойдётся ощутимо дороже. Зато число тарифов показывает, насколько плавно можно расти: у RuVDS их 440, и переход между ступенями почти не создаёт переплаты, а там, где тарифов 12, шаг крупный.

Практическая раскладка такая. Пробный сервер под ретрансляцию — 60–150 ₽/мес. Рабочая машина с записью архива — от 145 ₽/мес за 2 ядра, 2 ГБ и 100 ГБ диска, у большинства провайдеров 300–600 ₽/мес. Конфигурация с перекодированием в несколько качеств стартует примерно от 1500 ₽/мес, потому что там нужны 4–8 ядер.

Где разместить сервер и при чём тут расстояние

Между вашим компьютером и сервером поток идёт по сети, и каждый лишний тысячекилометровый прыжок добавляет задержку и риск потерь. Пинг — время отклика в миллисекундах — внутри Москвы обычно 3–15 мс, из Москвы во Франкфурт около 30–45 мс, а до США уже 100–150 мс.

Для публикации потока важнее не сам пинг, а стабильность: RTMP работает поверх TCP и при потерях пакетов переспрашивает данные, из-за чего кодировщик копит буфер и рвёт соединение. Первый критерий — короткий и ровный маршрут от вас до сервера. Если аудитория в России, берите площадку в РФ: тарифы собраны в разделе VPS в России.

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

Запуск сервера трансляций на Ubuntu по шагам

Самая простая рабочая связка — Nginx с модулем RTMP. Nginx здесь принимает поток от OBS на порт 1935/TCP и рассылает копии на площадки. Ниже порядок действий на чистой Ubuntu 22.04; каждая команда выполняется от администратора через sudo.

1. Возьмите сервер: для чистой ретрансляции хватит 1 ядра и 1 ГБ памяти, с запасом на запись архива берите 2 ядра, 2 ГБ и 20 ГБ диска. Подключитесь к нему по SSH — защищённому протоколу доступа к консоли.
2. Выполните apt update && apt install -y nginx libnginx-mod-rtmp: команда ставит веб-сервер с модулем приёма потоков, подробности — в гайде как установить Nginx на Ubuntu.
3. Добавьте в конец /etc/nginx/nginx.conf блок rtmp с директивами listen 1935; и application live { live on; record off; } — это точка приёма потока с именем live.
4. Откройте порт командой ufw allow 1935/tcp: иначе сетевой фильтр отбросит соединение от OBS молча, без сообщения об ошибке.
5. Проверьте настройки через nginx -t и примените их через systemctl reload nginx — первая команда ищет опечатки, вторая перечитывает конфигурацию без остановки сервиса.
6. В OBS в поле «Сервер» укажите rtmp://IP-адрес/live, в поле «Ключ потока» — любое слово, и запустите эфир.
7. Держите открытыми htop (показывает загрузку процессора и памяти) и iftop (показывает скорость сетевого обмена): отдача не должна превышать 70 % от ширины порта.

На весь путь уходит 20–30 минут. Если OBS пишет «не удалось подключиться», в девяти случаях из десяти дело в закрытом порте 1935/TCP или опечатке в конфигурации.

Ретрансляция на несколько площадок

Ретрансляция — это когда сервер берёт один входящий поток и отправляет его копии на два, три и больше внешних сервисов одновременно. Настраивается она в том же блоке rtmp: для каждой площадки добавляется строка push с её адресом публикации и вашим ключом потока.

Схема экономит ресурсы вашего компьютера. Без сервера OBS кодировал бы три независимых потока: тройная нагрузка на процессор и тройной трафик из дома. С сервером компьютер отдаёт один поток на 6 Мбит/с, а утроение происходит в дата-центре, где канал на порядок шире.

Важная тонкость: у площадок разные требования к параметрам. Одна принимает 1080p при 60 кадрах, другая ограничивает вход 6 Мбит/с, третья требует ключевой кадр (полный, несжатый относительно соседей снимок картинки) раз в 2 секунды. Пока поток идёт без перекодирования, нужно уложиться в самые строгие требования из списка — иначе придётся добавлять ядра под транскодирование для каждой площадки. Индикатор состояния потока в панели каждой площадки проверяйте в первые минуты эфира, а не после него.

Архив, защита и наблюдение за сервером

Запись архива включается директивой record all; в настройках приложения — сервер начнёт складывать файлы в указанную папку. Час 1080p занимает около 2,7 ГБ, поэтому сразу заведите правило: удалять или выгружать записи старше 30 дней, иначе диск кончится в самый неподходящий момент.

Публичный RTMP-порт видят все, и без ограничений на него быстро находятся посторонние. Минимальный набор мер — сложный ключ потока, разрешение публикации только с вашего IP-адреса и запрет на приём потоков извне для всех остальных. Отдельно посмотрите на защиту от атак: раздача видео с одного адреса — заметная цель, и базовые меры описаны в разделе защиты от DDoS для сайта.

Наблюдение сводится к трём метрикам: загрузка процессора, свободное место на диске и исходящая скорость. Настройте уведомление хотя бы на заполнение диска выше 85 % — это самая частая причина внезапно оборвавшейся записи. И держите план Б: на случай отказа сервера OBS переключается напрямую на основную площадку за полминуты.

Частые ошибки

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

• Считать канал по битрейту без запаса: 6 Мбит/с потока на канале 6 Мбит/с гарантируют рассыпающуюся картинку.
• Включать перекодирование там, где хватает копирования потока, и платить за 4 лишних ядра.
• Брать тариф с лимитом трафика 500 ГБ, а потом обнаружить, что 20 эфиров дают 650 ГБ отдачи.
• Забыть открыть порт 1935/TCP и полчаса искать причину в настройках OBS.
• Оставить ключ потока вида test и получить чужое видео в своём эфире.
• Не проверить связку целиком до анонса: первый настоящий эфир — плохое место для отладки.

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

Можно ли вести трансляцию с виртуального хостинга? Нет. Виртуальный хостинг рассчитан на сайты и не даёт держать постоянный процесс и слушать порт 1935/TCP. Нужен VPS или выделенный сервер с полным доступом к системе.

Сколько ядер нужно для ретрансляции на три площадки? Одного. Пересылка без перекодирования почти не нагружает процессор. Четыре ядра и больше нужны только при транскодировании.

Насколько сервер увеличит задержку? На 1–3 секунды по сравнению с прямой публикацией на площадку. Основная задержка всё равно возникает в плеере зрителя.

Windows или Linux? Практичнее Linux: связка Nginx с RTMP-модулем ставится на Ubuntu двумя командами и работает на 1 ГБ памяти. Windows нужен, только если вы завязаны на программу, которая существует лишь под него.

Сколько трафика заложить на месяц? Считайте по битрейту: поток 6 Мбит/с расходует 2,7 ГБ в час. При 20 эфирах по 4 часа с ретрансляцией на три площадки выходит порядка 650 ГБ.

Нужен ли отдельный IP-адрес? Одного выделенного адреса, который входит почти во все тарифы VPS, достаточно: приём потока и раздача зрителям живут на разных портах.

Что делать, если картинка сыпется у части зрителей? Это проблема доставки, а не сервера. Проверьте исходящую загрузку: если она стабильно выше 70 % ширины порта, снижайте битрейт или переносите раздачу на сеть доставки контента.

Итог

Сервер для трансляций размножает поток на площадки, снимает нагрузку с домашнего канала и хранит архив. Расчёт начинается с битрейта: 6 Мбит/с требуют 10 Мбит/с отдачи, три площадки — 30 Мбит/с, месяц эфиров — около 650 ГБ трафика. Ядра нужны только под перекодирование: без него хватает одного, с ним закладывайте 4–8.

Стартовать можно с тарифа за 59–150 ₽/мес и добавлять ресурсы по факту. Конфигурацию удобно подобрать в разделе VPS для сайтов и приложений, а под хранение и отдачу готовых роликов посмотрите разбор хостинга для видео.