O teu fluxo HLS privado cárgase para ti, non para os teus espectadores

Probas a páxina no teu portátil, o reprodutor arrinca e o tícket péchase. O espectador da outra banda abre a mesma páxina e obtén un indicador de carga que nunca remata. A explicación habitual é que a VPN está no servidor, así que a reprodución debería funcionar — pero é o navegador o compoñente que pide a lista de reprodución, e ten a súa propia ruta de rede. Unha páxina incrustada nun servidor con acceso privado non presta ese acceso a quen a carga.

Trátase dunha páxina ASP.NET existente que reproduce unha fonte HLS como http://10.5.5.9:8080/live/stream.m3u8, que é un enderezo privado ilustrativo. Funcionan dúas disposicións; unha delas probablemente non é a que construíches.

Mito: unha páxina que carga demostra a ruta dos medios

O HTML desa páxina vén do teu servidor web, pola ruta que teña o teu servidor web. A lista de reprodución e os segmentos veñen da orixe dos medios, pola ruta que teña o compoñente que fai a petición. Cando o reprodutor se executa no navegador do espectador, son dous clientes distintos, dous enderezos de orixe distintos e a miúdo dous dominios de fallo distintos. Ver que o primeiro ten éxito non di nada sobre o segundo.

O que a túa proba demostrou en realidade é máis estreito do que parecía: a túa máquina chega á vez á páxina pública e ao servidor privado de medios. A máquina do espectador nunca formou parte do experimento.

Que pide a lista de reprodución a continuación

RFC 8216 separa as listas de reprodución de medios, que enumeran segmentos, das listas mestras, que enumeran outras listas, e resolve os URI relativos contra o URI da lista que os contén. Esa regra é a parte que a xente salta. Descargar con éxito un ficheiro .m3u8 non é unha proba de reprodución, porque o ficheiro descargado é un índice, non os medios.

Segue a cadea tal como fai o reprodutor: abre a lista seleccionada, logo pide os recursos que nomea e despois segue calquera redirección. Unha lista servida a través dun servidor web accesible aínda pode enviar o espectador a un enderezo privado inaccesible. Do mesmo xeito, mover unha lista relativa a outra URL cambia a base contra a que se resolven as súas entradas, e por iso reescribir a primeira URL visible e deter alí adoita producir unha lista que parece válida pero non se pode reproducir.

Visualización directa: o espectador necesita a ruta

Se os espectadores deben chegar directamente ao servidor de medios, os seus dispositivos necesitan a VPN aprobada ou outra ruta privada, un DNS que resolva os nomes que realmente usaches, permiso para chegar a eses destinos e calquera autenticación que esixa o servizo de medios. Comproba cada cousa no dispositivo do espectador e non no servidor. Un navegador nun teléfono co perfil de VPN instalado pero sen conectar é un fallo frecuente e totalmente reproducible.

Esta disposición mantén a orixe privada e traslada o requisito de acceso ao público. É unha decisión de política tanto como técnica, así que confirma que cada espectador previsto ten permiso para ter esa ruta antes de deseñar arredor dela.

Entrega desde o servidor: un único punto de entrada controlado

A alternativa é un frontend de medios autorizado que obtén a orixe pola súa ruta privada e republica só os recursos que ve o espectador. Mantén a lista, os segmentos e calquera recurso de chave coherentes con ese único punto de entrada, ou o reprodutor descargará unha lista reescrita a través do frontend e os segmentos directamente desde un enderezo ao que o espectador non pode chegar.

Restrinxe a orixe e as rutas permitidas nese frontend. Unha URL arbitraria proporcionada polo usuario converte un proxy útil nun descargador sen restricións da túa rede interna, o que é un problema moito peor ca un fluxo que non se reproduce. Pon a orixe e o prefixo de ruta nunha lista de permitidos en lugar de validar a cadea a posteriori.

Para unha fonte HLS existente, comproba primeiro se abonda co reenvío controlado; unha VPN no medio non implica que faga falta transcodificar. Despois valida a combinación real de navegador e códec, porque unha resposta accesible e un formato compatible son condicións separadas. Mantén intactos o TLS, a autenticación e os requisitos de seguridade do navegador da orixe — un reprodutor incrustado non é unha excepción a eles.

Proba a cadea, non a URL

Executa as comprobacións desde o compoñente que realmente fará cada petición e trata cada paso como o seu propio resultado:

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

Logo repíteo no navegador do propio espectador co fluxo previsto, non cun patrón de proba da túa mesa. A carga da páxina, a carga da lista, a obtención do segmento e un fallo de autorización son catro resultados distintos, e queres ter observado os catro antes de dalo por arranxado. Non instales un complemento de navegador antigo porque un exemplo vello reproduciu así un fluxo; a peza que falta adoita ser a ruta do espectador ou a URL do segmento sen asinar.

Cando a disposición sexa deliberada, escríbea nunha liña: quen obtén os medios, por que ruta e que pode pedir o espectador. Esa frase resolve a maioría das discusións futuras sobre para quen é realmente o fluxo.