Lecture YouTube, réseau et connexion

Les chemins d'extraction YouTube de PipePipe évoluent lorsque YouTube modifie ses requêtes. Cette page a été vérifiée avec le code actuel de la série 5.3.x et les dernières versions stable et préversion. Si une issue demande une préversion précise, testez exactement cette version et indiquez-la dans le rapport ; ne présentez pas une ancienne bêta comme le comportement actuel.

Toutes les vidéos YouTube échouent : vérifiez le filtrage DNS

Si toutes les vidéos YouTube publiques échouent presque immédiatement, consultez le rapport généré par PipePipe avant de changer l'endpoint d'extraction, de réinstaller l'application ou de mettre WebView à jour.

Étape 1 : confirmer la signature DNS

Si PipePipe affiche Network error, appuyez sur REPORT :

Sur la page Error report, utilisez l'icône de partage pour copier le texte généré dans une note locale, puis effectuez la recherche dans ce texte :

Ces écrans montrent PipePipe 5.2.4 sur Android 16. L'échec réseau contrôlé sert uniquement à repérer les boutons ; utilisez le texte de votre propre rapport pour le diagnostic.

Recherchez googleapis.com et google.com dans le rapport. Les formes suivantes indiquent un blocage DNS ou réseau local :

jnn-pa.googleapis.com/0.0.0.0:443
jnn-pa.googleapis.com/127.0.0.1:443
localhost/127.0.0.1:...

La requête n'a jamais atteint Google

0.0.0.0, 127.0.0.1 et localhost renvoient vers l'appareil au lieu du vrai service. PipePipe ne peut pas contourner cette redirection en changeant d'endpoint.

Étape 2 : trouver le filtre responsable

Vérifiez chaque couche séparément :

1. DNS privé Android : ouvrez Paramètres → Réseau et Internet → DNS privé. Sur Samsung, le chemin habituel est Paramètres → Connexions → Plus de paramètres de connexion → DNS privé. Notez le fournisseur choisi, puis consultez son tableau de bord ou son journal de requêtes.
2. VPN ou filtre local : consultez le journal des requêtes bloquées du VPN, du bloqueur de publicités, du pare-feu ou de l'application DNS pendant une nouvelle tentative.
3. Routeur ou DNS auto-hébergé : vérifiez le journal et la liste d'autorisation du routeur, de Pi-hole, d'AdGuard Home, de NextDNS ou du service équivalent.
4. Appareil rooté ou ROM custom : vérifiez si le fichier hosts redirige un domaine requis vers 0.0.0.0 ou 127.0.0.1.

3. Ouvrez DNS privé. Cette page permet aussi de voir si un VPN est actif.

4. Notez le mode ou le fournisseur actif. Si un nom d'hôte fournisseur est sélectionné, ouvrez le tableau de bord et le journal de requêtes de ce service. Le mode Automatic n'exclut pas un filtre sur le routeur ou ailleurs sur le réseau.

Les captures montrent Android 16 en anglais. Le nom et le chemin peuvent varier selon le constructeur.

Étape 3 : autoriser les familles de domaines requises

PipePipe a actuellement besoin de :

• googleapis.com et tous ses sous-domaines, dont jnn-pa.googleapis.com et youtubei.googleapis.com ;
• google.com et tous ses sous-domaines.

Ajoutez les deux familles à la liste d'autorisation du composant trouvé à l'étape 2. La syntaxe dépend de l'outil : domaine de base, wildcard comme *.googleapis.com ou règle propre au service. Configurez cette liste au lieu de désactiver durablement tout filtrage. N'autoriser que le nom visible aujourd'hui ne garantit pas qu'un autre hôte utilisé plus tard par YouTube fonctionnera.

Pourquoi PipePipe a besoin de ces adresses

Le client actuel contacte jnn-pa.googleapis.com pour préparer la preuve nécessaire à la lecture protégée, tandis que l'extracteur utilise youtubei.googleapis.com pour demander les informations YouTube. Si le DNS renvoie l'une de ces adresses vers le téléphone, l'échange s'arrête avant la lecture. Cela ne nécessite aucun service Google Play.

Étape 4 : se reconnecter et vérifier le correctif

1. Reconnectez le Wi-Fi ou activez brièvement le mode avion pour éliminer les anciens résultats DNS.
2. Forcez l'arrêt de PipePipe, puis rouvrez l'application.
3. Relancez la même vidéo publique.
4. Générez un nouveau rapport et vérifiez que le domaine requis ne pointe plus vers 0.0.0.0, 127.0.0.1 ou localhost.

Un test temporaire en données mobiles ou sur un autre réseau non filtré peut confirmer le diagnostic. Il ne s'agit pas de laisser la protection désactivée.

L'avertissement épinglé #2757 documente les familles de domaines requises. Dans #2712, la lecture a été rétablie après l'autorisation de jnn-pa.googleapis.com. #2750 contient la même signature 0.0.0.0/localhost.

Si le rapport montre une vraie adresse publique

Une erreur ENETUNREACH, un délai dépassé ou un échec de connexion vers une vraie adresse IP est un autre cas : le DNS n'a pas redirigé le domaine localement. Continuez avec le test réseau contrôlé ci-dessous et notez le VPN, le FAI, le pays, l'endpoint et l'erreur exacte au lieu d'ajouter des exceptions DNS sans rapport.

AntiBotException

Sign in to confirm you're not a bot signifie que YouTube restreint une requête anonyme. Ce n'est pas une demande générique de vider le cache ou de mettre à jour WebView. Réessayez une fois, puis testez un autre réseau ou une autre sortie VPN. Notez l'endpoint d'extraction YouTube sélectionné avant de le signaler.

Utilisez la même vidéo publique à chaque essai. Notez pays/sortie réseau et si l'échec est immédiat ou arrive après quelques streams. Un résultat qui change seulement avec le réseau est une information utile ; ne publiez ni IP ni données de compte.

Source error ou buffering

Ces messages n'identifient pas une cause unique. Mettez PipePipe à jour, joignez le rapport d'erreur généré et indiquez l'URL, l'endpoint, l'état de connexion, le pays et l'état VPN/proxy. Précisez si l'échec arrive au démarrage, après une durée fixe, au changement de qualité, au retour dans l'app ou après un seek.

Pour les vidéos YouTube ordinaires qui ne sont pas des directs, MWEB (SABR) est actuellement le chemin de lecture basé sur une session lorsque la réponse MWEB expose les données SABR. VisionOS est un autre chemin d'extraction anonyme. Essayer un autre endpoint peut être une étape de diagnostic temporaire ; cela ne prouve pas que l'endpoint initial ou WebView est responsable.

Une seule vidéo (ou quelques-unes) échoue alors que les autres fonctionnent

C'est un point de départ différent de « toutes les vidéos échouent ». Relancez d'abord la même URL publique après avoir mis PipePipe à jour, puis notez le résultat. Si le reste de YouTube fonctionne, ne commencez pas par réinstaller WebView ou modifier le DNS.

1. Vérifiez si le contenu est un direct, un Short, une vidéo limitée par l'âge, réservée aux membres ou indisponible dans un navigateur normal. Notez-le dans le rapport.
2. Ouvrez Paramètres → Avancé → Point de terminaison d'extraction YouTube et notez la valeur sélectionnée. Dans les versions 5.3.x actuelles, un compte déconnecté peut choisir VisionOS ou MWEB (SABR) ; un compte connecté reste sur MWEB (SABR). Android VR appartient à une ancienne version et n'est plus proposé dans le sélecteur actuel.
3. Relancez la même URL une fois sans changer qualité, codec, réseau ou état de connexion.
4. Si l'échec reste présent, ne changez qu'une variable puis retestez la même URL. La comparaison utile est « même vidéo, un seul changement », pas une liste de réglages modifiés en même temps.
5. Joignez le rapport généré et précisez si les autres vidéos publiques fonctionnent encore.

Un échec isolé peut venir de la réponse renvoyée pour cette vidéo ou d'un format que l'appareil ne sait pas décoder. Il ne prouve pas à lui seul que PipePipe, WebView ou tout le réseau est cassé. Si le rapport contient video/av01, MediaCodec ou un nom de décodeur, consultez séparément le guide MediaCodec.

Choix d'endpoint actuels

État du compte	Choix affichés dans les versions 5.3.x actuelles	Défaut
Déconnecté	VisionOS, MWEB (SABR)	VisionOS
Connecté	MWEB (SABR)	MWEB (SABR)
Anciennes captures/issues	Android VR peut apparaître	Ce n'est plus un choix actuel

Les libellés et les défauts peuvent encore changer après une modification de YouTube. Signalez toujours ce que la version installée affiche réellement.

Test de lecture contrôlé

1. Commencez avec une vidéo publique et notez l'endpoint.
2. Testez une fois sur le réseau normal sans changer plusieurs réglages.
3. En cas d'échec, répétez une fois avec la même vidéo et notez temps/position.
4. Si nécessaire, ne changez qu'une variable — réseau/sortie VPN, endpoint ou connexion — et retestez la même vidéo.
5. Joignez le rapport généré et les deux résultats.

Cela sépare un échec d'extraction répétable d'un incident réseau/session isolé et évite d'affirmer que cinq changements ont été le correctif.

Lecture connectée

La connexion est surtout utile en cas de blocage IP, de contenu restreint par âge, de contenu réservé aux membres ou de traduction automatique YouTube. Ses limites actuelles incluent les formats vidéo AVC, l'absence de téléchargement audio seul, l'absence de retour en arrière dans un live déjà commencé et une extraction moins prévisible. Si l'échec commence après connexion, testez une fois déconnecté et signalez les deux résultats.

Ne publiez ni cookies, ni jetons, ni e-mail de compte, ni capture du flux de connexion. « connecté/déconnecté » et l'erreur visible suffisent au premier rapport.

L'endpoint est une information, pas un bouton magique

Un endpoint choisit un chemin de requête/extraction. Il peut faire apparaître ou disparaître un symptôme et doit être noté, mais un endpoint qui réussit une fois ne prouve pas que tous les autres sont cassés. Donnez l'endpoint par défaut, ceux testés et le résultat pour la même URL. Gardez les essais d'endpoint hors d'une issue WebView sauf si le message WebView exact est aussi présent.

Capture historique : PipePipe 5.2.3 sur Android 16/API 36. Elle montre un endpoint qui n'est plus proposé dans les versions 5.3.x actuelles ; utilisez le tableau ci-dessus pour les choix actuels.

Capture actuelle : PipePipe 5.3.1-beta · Android 16/API 36. Hors connexion, les choix affichés sont VisionOS et MWEB (SABR) ; l'option sélectionnée est visible dans la fenêtre.

L'issue résolue #2686 est un exemple historique de comparaison d'endpoints : le mainteneur a demandé si Android VR (DASH) était choisi et conseillé de tester MWEB (SABR). Dans la capture, 1 est MWEB et 2 Android VR. C'est un élément historique, pas une instruction actuelle ni la promesse que MWEB résout chaque problème de réseau ou de compte.

Les issues récentes montrent pourquoi il faut préciser l'étape concernée. Dans #2901, la lecture s'arrêtait après la mise en veille du téléphone et le rapport contenait une destination UnknownHost. Dans #2905, la lecture fonctionnait mais un téléchargement SABR échouait avec un VPN. Ce sont deux rapports « YouTube/SABR », mais ils ne demandent pas les mêmes éléments et ne doivent pas être réduits à un diagnostic WebView ou DNS générique.

Rapport minimal de lecture

URL vidéo et service :
Version PipePipe / Android :
Endpoint avant et pendant l'échec :
Connecté ou déconnecté :
Pays réseau / VPN ou proxy :
Type de vidéo et qualité/codec choisi, si affiché :
DNS privé / bloqueur / pare-feu et domaine bloqué, le cas échéant :
Moment de l'échec (début / temps / seek / qualité / retour app) :
Message visible et rapport généré :
Retest d'une seule variable et résultat :

Ne pas confondre avec WebView

Le message exact WebView indisponible a son guide dédié. Une WebView récente n'exclut pas un problème réseau ou SABR, et un Source error ne prouve pas qu'il faut mettre WebView à jour.