Ваш приватный HLS-поток загружается для вас, а не для ваших зрителей

Вы проверяете страницу на ноутбуке, проигрыватель запускается, и заявка закрывается. Зритель на другом конце открывает ту же страницу и получает индикатор загрузки, который никогда не завершается. Обычное объяснение — VPN стоит на сервере, поэтому воспроизведение должно работать; но именно браузер является компонентом, который запрашивает плейлист, и у него собственный сетевой путь. Страница, встроенная на сервере с приватным доступом, не одалживает этот доступ тому, кто её загружает.

Речь идёт о существующей странице ASP.NET, которая воспроизводит источник HLS, например http://10.5.5.9:8080/live/stream.m3u8, а это иллюстративный приватный адрес. Работают две схемы; одна из них, вероятно, не та, которую вы построили.

Миф: загрузившаяся страница доказывает медийный путь

HTML этой страницы приходит с вашего веб-сервера, по любому маршруту, который есть у вашего веб-сервера. Плейлист и сегменты приходят с медийного источника, по любому маршруту, который есть у запрашивающего компонента. Когда проигрыватель работает в браузере зрителя, это два разных клиента, два разных адреса источника и часто два разных домена отказа. Успех первого ничего не говорит о втором.

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

Что плейлист запрашивает дальше

RFC 8216 разделяет медиаплейлисты, перечисляющие сегменты, и мастер-плейлисты, перечисляющие другие плейлисты, и разрешает относительные URI относительно URI плейлиста, который их содержит. Именно это правило люди и пропускают. Успешное получение одного файла .m3u8 не является тестом воспроизведения, потому что полученный файл — индекс, а не медиа.

Идите по цепочке так, как это делает проигрыватель: откройте выбранный плейлист, затем запросите ресурсы, которые он называет, затем проследуйте любое перенаправление. Плейлист, отданный через доступный веб-сервер, всё равно может отправить зрителя на недоступный приватный адрес. Точно так же перенос относительного плейлиста на другой URL меняет базу, относительно которой разрешаются его записи, и поэтому перезапись первого видимого URL и остановка на этом обычно даёт плейлист, который выглядит корректным, но не может воспроизводиться.

Прямой просмотр: зрителю нужен путь

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

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

Доставка со стороны сервера: одна контролируемая точка входа

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

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

Для существующего источника HLS сначала проверьте, достаточно ли контролируемого перенаправления; VPN посередине не означает, что требуется транскодирование. Затем проверьте фактическое сочетание браузера и кодека, потому что доступный ответ и поддерживаемый формат — два разных условия. Сохраняйте TLS, аутентификацию и требования безопасности браузера у источника нетронутыми — встроенный проигрыватель не является от них исключением.

Проверяйте цепочку, а не URL

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

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

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

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