Votre flux HLS privé se charge pour vous, pas pour vos spectateurs

Vous testez la page sur votre ordinateur portable, le lecteur démarre et le ticket est fermé. Le spectateur en face ouvre la même page et obtient un indicateur de chargement qui ne se résout jamais. L’explication habituelle est que le VPN est sur le serveur, donc la lecture devrait fonctionner — mais c’est le navigateur qui demande la playlist, et il a son propre chemin réseau. Une page intégrée sur un serveur à accès privé ne prête pas cet accès à qui la charge.

Il s’agit d’une page ASP.NET existante qui lit une source HLS comme http://10.5.5.9:8080/live/stream.m3u8, une adresse privée illustrative. Deux agencements fonctionnent ; l’un d’eux n’est probablement pas celui que vous avez construit.

Mythe : une page qui charge prouve le chemin des médias

Le HTML de cette page vient de votre serveur web, par la route dont dispose votre serveur web. La playlist et les segments viennent de l’origine des médias, par la route dont dispose le composant qui fait la requête. Quand le lecteur tourne dans le navigateur du spectateur, ce sont deux clients différents, deux adresses source différentes et souvent deux domaines de panne différents. Voir le premier réussir ne dit rien du second.

Ce que votre test a réellement prouvé est plus étroit qu’il n’y paraissait : votre machine atteint à la fois la page publique et l’hôte média privé. La machine du spectateur n’a jamais fait partie de l’expérience.

Ce que la playlist demande ensuite

RFC 8216 sépare les playlists de médias, qui énumèrent des segments, des playlists maîtresses, qui énumèrent d’autres playlists, et résout les URI relatifs par rapport à l’URI de la playlist qui les contient. C’est précisément cette règle que les gens sautent. Récupérer avec succès un fichier .m3u8 n’est pas un test de lecture, car le fichier récupéré est un index, pas le média.

Suivez la chaîne comme le fait le lecteur : ouvrez la playlist choisie, demandez ensuite les ressources qu’elle nomme, puis suivez toute redirection. Une playlist servie par un serveur web joignable peut encore envoyer le spectateur vers une adresse privée injoignable. De même, déplacer une playlist relative vers une autre URL change la base par rapport à laquelle ses entrées sont résolues, ce qui explique pourquoi réécrire la première URL visible et s’arrêter là produit souvent une playlist d’apparence valide qui ne peut pas être lue.

Visionnage direct : le spectateur a besoin du chemin

Si les spectateurs doivent atteindre directement l’hôte média, leurs appareils ont besoin du VPN approuvé ou d’un autre chemin privé, d’un DNS qui résout les noms que vous avez réellement utilisés, de l’autorisation d’atteindre ces destinations et de toute authentification exigée par le service média. Vérifiez chacun sur l’appareil du spectateur plutôt que sur le serveur. Un navigateur sur un téléphone dont le profil VPN est installé mais non connecté est une panne fréquente et parfaitement reproductible.

Cet agencement garde l’origine privée et reporte l’exigence d’accès sur le public. C’est une décision de politique autant que de technique, alors confirmez que chaque spectateur prévu a le droit de détenir ce chemin avant de concevoir autour de lui.

Diffusion côté serveur : un point d’entrée contrôlé

L’alternative est un frontal média autorisé qui récupère l’origine par son chemin privé et republie uniquement les ressources destinées au spectateur. Gardez la playlist, les segments et toute ressource de clé cohérents avec ce point d’entrée unique, sinon le lecteur récupérera une playlist réécrite via le frontal et les segments directement à une adresse que le spectateur ne peut pas atteindre.

Restreignez l’origine et les chemins autorisés dans ce frontal. Une URL arbitraire fournie par l’utilisateur transforme un proxy utile en récupérateur illimité de votre réseau interne, ce qui est un problème bien pire qu’un flux qui ne se lit pas. Placez l’origine et le préfixe de chemin sur une liste d’autorisation au lieu de valider la chaîne après coup.

Pour une source HLS existante, vérifiez d’abord si le transfert contrôlé suffit ; un VPN au milieu n’implique pas qu’un transcodage soit nécessaire. Validez ensuite la combinaison réelle de navigateur et de codec, car une réponse joignable et un format pris en charge sont deux conditions distinctes. Gardez le TLS, l’authentification et les exigences de sécurité du navigateur de l’origine intacts — un lecteur intégré n’en est pas une exception.

Testez la chaîne, pas l’URL

Exécutez les contrôles depuis le composant qui fera réellement chaque requête, et traitez chaque étape comme son propre résultat :

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

Répétez ensuite dans le navigateur du spectateur lui-même avec le flux prévu, pas avec un motif de test depuis votre bureau. Le chargement de la page, celui de la playlist, la récupération du segment et un échec d’autorisation sont quatre résultats distincts, et vous voulez avoir observé les quatre avant de déclarer le problème corrigé. N’installez pas d’extension de navigateur obsolète parce qu’un vieil exemple lisait ainsi un flux ; la pièce manquante est généralement le chemin du spectateur ou l’URL de segment non signé.

Une fois l’agencement délibéré, écrivez-le en une ligne : qui récupère les médias, par quel chemin et ce que le spectateur a le droit de demander. Cette phrase règle la plupart des discussions futures sur celui à qui le flux est vraiment destiné.