Кратко — причин несколько, но по описанию (сначала всё работало, потом периодически ни один ingest не доступен; разные сервера «прыгают») наиболее вероятные: проблемы у провайдера (пейринг/маршрутизация/перегрузка/трафик‑форминг для RTMP/RTMPS), локальные проблемы (маршрутизатор/MTU/QoS/дуплекс/пакетная потеря) или (реже) временные проблемы на стороне Twitch/CDN. Ниже — что проверить и какие есть пути решения.
Что проверить первым делом (порядок и команды)
1) Базовый тест канала связи
- Speedtest (upload) — убедитесь, что заявленная скорость загрузки стабильна и достаточна для вашего битрейта.
- Проверьте, не загружают ли сеть другие устройства (резервные копии, торренты и т.п.).
2) Проверить потерю пакетов/маршрут до Twitch
- Узнайте точный хост ingest, к которому вы пытаетесь подключиться (в OBS в логах или в Twitch Test). Это будет что‑то вроде live-*.twitch.tv.
- На Windows: PowerShell:
Test-NetConnection <hostname> -Port 443
tracert <hostname>
WinMTR <hostname> (скачайте WinMTR и запустите тест ~2–5 минут)
- На Linux/macOS:
mtr -rw <hostname> (или mtr -c 200 -w <hostname>)
traceroute <hostname>
- Что смотреть: стабильность задержки и, главное, потерю пакетов на финальном хопе. Если финальный хоп или последние хопы показывают потери — проблема в пути к Twitch (пейринг/провайдер). Если потеря начинается на первом/втором хопе — локальная сеть/модем/роутер.
3) Трассировка TCP (проверить блокировку портов / RST)
- На Linux: tcptraceroute <hostname> 443
- На Windows: в PowerShell Test-NetConnection <hostname> -Port 443 (покажет, удаётся ли TCP‑соединение).
- Если TCP соединение сбрасывается (RST) или не устанавливается — возможно DPI/блокировка RTMP/RTMPS.
4) Захват трафика (если умеете)
- Wireshark/tcpdump, фильтр по IP/портам Twitch (1935, 443): посмотреть retransmits, RST, ICMP unreachable.
tcpdump -i <iface> host <IP_ingest> and \(port 1935 or port 443\) -w twitch.pcap
- Ищите: повторные передачи, RST, большие задержки между сегментами.
5) Быстрый тест «обхода» — VPN
- Попробуйте стримить через VPN-сервис (сервер в Европе, рядом с выбранным ingest). Если через VPN всё стабильно — почти наверняка проблема с маршрутом/провайдером или пейрингом.
Интерпретация типичных результатов
- Потеря пакетов на последних хопах / high latency → проблема у провайдера или на пути к CDN/ingest.
- Потеря на первом/втором хопе → локальная сеть/роутер/модем.
- Проблем исчезают при использовании VPN → провайдер/пейринг/DPI.
- TCP‑RST/завершение соединения → возможно DPI/блокировка RTMP или проблемы TLS/RTMPS.
Короткие практические решения (что можно сделать прямо сейчас)
- Переключиться на RTMPS (порт 443) вместо 1935 (OBS обычно использует rtmps:// by default, но можно вручную выставить сервер).
- Понизить битрейт, разрешение и FPS — временно уменьшит нагрузку и снизит шанс срывов.
- Использовать проводное подключение (Ethernet) и избегать Wi‑Fi.
- Перезагрузить модем/роутер, поставить модем в bridge mode (если двойной NAT), обновить прошивку.
- Отключить hardware acceleration в OBS (иногда драйверы/кодеки создают проблемы).
- Включить QoS на роутере и приоритизировать исходящий трафик с компьютера/порта.
- Попробовать стрим через VPN или через VPS/ретранслятор (на VPS запускаете собственный RTMP сервер и с него отправляете на Twitch) — как обходной путь.
Долгосрочные / «правильные» варианты
- Обратиться в техподдержку провайдера с логами (см. ниже) и требованием проверить маршрутизацию/пейринг к Twitch. Попросите escalation/network ops.
- Если провайдер идентифицирует проблему — они должны править маршрут/пейринг или устранить shaping.
- Если провайдер не помогает: использовать VPN для постоянного обхода или арендовать недорогой VPS в нужном регионе и ретранслировать туда (OBS -> VPS RTMP -> Twitch). Это реально решает проблему, но увеличивает задержку/затраты.
Что прислать провайдеру / Twitch (шаблон и какие данные)
- Время(а) проблемы (точные UTC).
- MTR/WinMTR log (2–5 минут) до конкретного ingest (укажите hostname и IP).
- traceroute/tracert (полный вывод).
- Результаты ping (пара минут).
- Результаты Test-NetConnection/TCP traceroute (если были).
- Укажите, что тесты к другим сервисам стабильны (если проверяли), и что через VPN проблема уходит (если проверяли).
Это позволит провайдеру искать проблему у своего upstream/peering.
Пример короткого текста в техподдержку провайдера
(на русском)
"Добрый день. Со времени переезда у меня стабильно падает качество исходящего видеопотока на Twitch: сильные просадки битрейта, потеря кадров, иногда невозможно установить соединение с ingest-серверами Twitch. Прилагаю MTR/trace и логи — наблюдается потеря пакетов/высокая задержка на пути к IP <ip_ingest> (host <hostname>) в период с <время>. Прошу проверить маршрут/пейринг/shape трафика к CDN/Twitch и при необходимости передать запрос на уровень Network Operations."
Если захотите — помогу разобрать ваши MTR / OBS-логи
Можете прислать вывод WinMTR/mtr и OBS логи (или скрин ошибок Twitch Test). Я подскажу, где именно видна потеря/блокировка и какое следующее действие наиболее целесообразно.
Если нужен — дам пошаговую инструкцию по настройке VPS/ретрансляции и как настроить OBS на кастомный RTMP (быстрый обходной вариант).