Reproducción YouTube, red e inicio de sesión

YouTube cambia sus peticiones y PipePipe adapta sus rutas de extracción. Consulta GitHub Releases antes de diagnosticar e indica en el informe qué build tienes instalada. Si una issue pide probar una versión preliminar concreta, usa esa y dilo; no supongas que una beta antigua se comporta como la app actual.

Fallan todos los vídeos de YouTube: comprueba el filtrado DNS

Si todos los vídeos públicos de YouTube fallan casi de inmediato, consulta el informe generado por PipePipe antes de cambiar el endpoint de extracción, reinstalar la aplicación o actualizar WebView.

Paso 1: confirma la firma DNS

Si PipePipe muestra Network error, pulsa REPORT:

En la página Error report, pulsa el icono de compartir para copiar el texto generado en una nota local y busca dentro de ese texto:

Capturas de referencia en Android 16. El fallo de red controlado solo sirve para localizar los botones; usa el texto de tu propio informe para el diagnóstico.

Busca googleapis.com y google.com en el informe. Estas formas identifican un bloqueo DNS o de red 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 petición nunca llegó a Google

0.0.0.0, 127.0.0.1 y localhost apuntan al propio dispositivo en vez de al servicio real. PipePipe no puede evitar esa redirección cambiando de endpoint.

Paso 2: encuentra el filtro responsable

Comprueba estas capas una por una:

1. DNS privado de Android: abre Ajustes → Redes e Internet → DNS privado. En Samsung, la ruta habitual es Ajustes → Conexiones → Más ajustes de conexión → DNS privado. Anota el proveedor seleccionado y consulta su panel o registro de consultas.
2. VPN o filtro local: revisa el registro de peticiones bloqueadas de la VPN, bloqueador de anuncios, cortafuegos o aplicación DNS mientras vuelves a probar el vídeo.
3. Router o DNS autoalojado: revisa el registro y la lista de permitidos del router, Pi-hole, AdGuard Home, NextDNS o servicio equivalente.
4. Dispositivo rooteado o ROM personalizada: comprueba si el archivo hosts redirige un dominio necesario a 0.0.0.0 o 127.0.0.1.

3. Abre DNS privado. Esta página también muestra si hay una VPN activa.

4. Anota el modo o proveedor activo. Si está seleccionado un nombre de host de proveedor, abre el panel y el registro de consultas de ese servicio. El modo Automatic no descarta un filtro en el router o en otra parte de la red.

Las capturas muestran Android 16 en inglés. Los nombres y las rutas pueden variar según el fabricante.

Paso 3: permite las familias de dominios necesarias

PipePipe necesita actualmente:

• googleapis.com y todos sus subdominios, incluidos jnn-pa.googleapis.com y youtubei.googleapis.com;
• google.com y todos sus subdominios.

Añade ambas familias a la lista de permitidos del componente encontrado en el paso 2. La sintaxis depende de la herramienta: puede usar el dominio base, un comodín como *.googleapis.com o su propia regla. Configura esta lista en lugar de desactivar permanentemente todo el filtrado. Permitir solo el host visible hoy puede no cubrir otro host que YouTube use más adelante.

Por qué PipePipe necesita estas direcciones

El cliente actual contacta con jnn-pa.googleapis.com para preparar la prueba necesaria para la reproducción protegida, mientras que el extractor usa youtubei.googleapis.com para solicitar información de YouTube. Si el DNS devuelve cualquiera de estas direcciones al teléfono, el intercambio se detiene antes de la reproducción. Esto no requiere los servicios de Google Play.

Paso 4: vuelve a conectarte y verifica la solución

1. Vuelve a conectar el Wi-Fi o activa brevemente el modo avión para descartar resultados DNS antiguos.
2. Fuerza la detención de PipePipe y vuelve a abrirlo.
3. Reintenta el mismo vídeo público.
4. Genera un informe nuevo y confirma que el host necesario ya no resuelve a 0.0.0.0, 127.0.0.1 o localhost.

Una prueba temporal con datos móviles u otra red sin filtros puede confirmar el diagnóstico. No es una recomendación para dejar desactivada la protección.

El aviso fijado #2757 documenta las familias de dominios necesarias. En #2712, permitir jnn-pa.googleapis.com restauró la reproducción. #2750 contiene la misma firma 0.0.0.0/localhost.

Si el informe muestra una dirección pública real

Un error ENETUNREACH, un tiempo de espera agotado o un fallo de conexión a una IP pública real es distinto: el DNS no redirigió el host localmente. Continúa con la prueba de red controlada de abajo y anota VPN, ISP, país, endpoint y error exacto en vez de añadir excepciones DNS no relacionadas.

AntiBotException

Sign in to confirm you're not a bot significa que YouTube restringe una petición anónima. No es una petición genérica de borrar caché o actualizar WebView. Prueba una vez más y luego otra red o salida VPN. Anota el endpoint de extracción de YouTube antes de informarlo.

Usa el mismo vídeo público en cada prueba. Anota país/salida de red y si el fallo es inmediato o aparece después de algunos streams. Un resultado que cambia solo con la red es evidencia útil; no publiques IP ni datos de cuenta.

Source error o búfer

Estos mensajes no identifican una sola causa. Actualiza PipePipe, adjunta el informe generado e incluye URL, endpoint, sesión, país y estado de VPN/proxy. Di si falla al inicio, tras un tiempo fijo, al cambiar calidad, al volver a la app o tras seek.

Para vídeos normales de YouTube que no son directos, MWEB (SABR) es la ruta actual de reproducción basada en sesión cuando la respuesta MWEB expone datos SABR. VisionOS es una ruta de extracción anónima separada. Probar otro endpoint puede ser un diagnóstico temporal; no prueba que el endpoint inicial o WebView sean culpables.

Falla un vídeo (o unos pocos) mientras los demás funcionan

Este es un punto de partida distinto de «fallan todos los vídeos». Primero vuelve a probar la misma URL pública después de actualizar PipePipe y anota el resultado. Si el resto de YouTube funciona, no empieces reinstalando WebView ni cambiando el DNS.

1. Comprueba si es un directo, un Short, un vídeo restringido por edad, solo para miembros o no disponible en un navegador normal. Anótalo en el informe.
2. Abre Ajustes → Avanzado → Endpoint de extracción de YouTube y anota el valor seleccionado. Las opciones pueden depender del build instalado y del estado de sesión. Las capturas o issues antiguas pueden mencionar Android VR; fíate de lo que aparece en tus propios ajustes.
3. Vuelve a probar la misma URL una vez sin cambiar calidad, códec, red ni sesión.
4. Si sigue fallando, cambia solo una variable y vuelve a probar la misma URL. La comparación útil es «mismo vídeo, un cambio», no varios ajustes a la vez.
5. Adjunta el informe generado y di si los demás vídeos públicos siguen funcionando.

La reproducción se detiene hacia el minuto 1 con un 403

Este caso tiene una firma reconocible: el vídeo arranca con normalidad, se detiene hacia el segundo 59 con un Source error, y el informe contiene ERROR_CODE_IO_BAD_HTTP_STATUS con Response code: 403.

Mira la línea __Endpoint:__ de ese informe. Si dice visionos, ese endpoint es la causa. YouTube está retirando el cliente VisionOS: la respuesta del player se sigue extrayendo y sigue listando formatos, pero las peticiones de medios empiezan a ser rechazadas una vez que la reproducción está en marcha. No es un fallo de códec, WebView ni DNS.

Abre Ajustes → Avanzado → Endpoint de extracción de YouTube y selecciona MWEB (SABR). Una instalación anónima usa VisionOS por defecto, y una sesión iniciada ya está limitada a MWEB: por eso el síntoma llega sobre todo a quienes no han iniciado sesión.

El estado al que hay que llegar: MWEB (SABR) seleccionado. Este cambio reinicia la app, así que vuelve a abrir el vídeo después.

MWEB necesita que googleapis.com y google.com sean accesibles, porque el flujo del token proof-of-origin los usa. Si la reproducción sigue fallando tras el cambio, revisa la sección sobre filtrado DNS antes que cualquier otra cosa, y adjunta un informe nuevo que muestre el nuevo endpoint.

Las respuestas del mantenedor detrás de este diagnóstico están en #2931, #2935 y #2992. #3007 es un informe reciente con la misma firma a 0:59 y dos logs visionos.

Vídeos muy largos y cantidad de segmentos SABR

Un vídeo no deja de ser compatible solo por durar mucho. En la issue #2973, un vídeo de 36 horas fallaba con Invalid exact SABR segment count: su cronología MWEB/SABR contenía 23.954 segmentos mientras que el límite del cliente Android era de 10.000. Es una comprobación del número de segmentos en el reproductor, no un error del decodificador ni de WebView. La PR #99 de PipePipeClient documenta un cambio propuesto; consulta la issue y la PR para ver su estado actual y si la corrección ha llegado a una release. Un límite más alto tampoco puede garantizar la reproducción de todas las cronologías extremas que devuelva YouTube.

Si aparece este error exacto, consulta la issue y las notas de release para ver el estado actual. Incluye en el informe la línea exacta del error, la URL y duración del vídeo, el build instalado, el endpoint seleccionado y la calidad. Otra aplicación puede usar una ruta de extracción de YouTube distinta; que allí funcione no demuestra que PipePipe recibiera los mismos datos del flujo.

Un fallo aislado puede venir de la respuesta de ese vídeo o de un formato que el dispositivo no puede decodificar. Por sí solo no demuestra que PipePipe, WebView o toda la red estén rotos. Si el informe contiene video/av01, MediaCodec o un nombre de decodificador, consulta la guía de MediaCodec como comprobación separada.

Opciones de endpoint

Los nombres, la disponibilidad y los valores predeterminados pueden cambiar según el build, las respuestas de YouTube y el estado de sesión. Fíate del selector de tu app e indica exactamente lo que muestra.

Prueba de reproducción controlada

1. Empieza con un vídeo público y anota endpoint.
2. Prueba una vez en red normal sin cambiar varios ajustes.
3. Si falla, repite una vez con el mismo vídeo y anota tiempo/posición.
4. Si procede, cambia solo una variable —red/salida VPN, endpoint o sesión— y vuelve a probar.
5. Adjunta informe generado y ambos resultados.

Así se separa un fallo de extracción repetible de un incidente aislado de red/sesión y se evita afirmar que cinco cambios fueron la solución.

Reproducción con sesión

La sesión se reserva para bloqueos IP, contenido de edad/miembros o traducción automática de YouTube. Sus limitaciones actuales incluyen formatos AVC, sin descarga solo audio, sin retroceso en un directo ya iniciado y extracción menos predecible. Si falla después de iniciar sesión, prueba una vez sin sesión e informa ambos resultados.

No publiques cookies, tokens, correo de cuenta ni grabación del flujo de inicio. «Con sesión/sin sesión» y error visible bastan para el primer informe.

El endpoint es evidencia, no un botón mágico

Un endpoint elige ruta de petición/extracción. Puede hacer aparecer o desaparecer un síntoma y debe anotarse, pero un endpoint que funciona una vez no prueba que los demás estén rotos. Indica endpoint por defecto, los probados y resultado para la misma URL. No mezcles pruebas de endpoint con una issue WebView salvo que aparezca el mensaje WebView exacto.

Un endpoint también puede dejar de funcionar porque YouTube retire el cliente que hay detrás. Cuando eso pasa, cambiar de endpoint es la solución, no solo un paso de diagnóstico. VisionOS está retirándose: un informe visionos que se detiene hacia 0:59 con un 403 corresponde a MWEB (SABR).

Captura de referencia: Android 16/API 36 en una instalación anónima. 1 es el selector; las opciones disponibles en tu build pueden ser distintas.

La issue #2686 es un ejemplo histórico de comparación de endpoints: el mantenedor preguntó si estaba seleccionado Android VR (DASH) y aconsejó probar MWEB (SABR). En el selector actual esa opción ya no existe. Trátalo como evidencia histórica, no como la promesa de que MWEB arregle cualquier fallo de red o cuenta.

El historial de issues muestra por qué importa indicar la fase exacta. En #2901, la reproducción se detenía al apagar la pantalla y el informe incluía un destino UnknownHost. En #2905, la reproducción funcionaba pero una descarga SABR fallaba con una VPN. Son dos informes «YouTube/SABR», pero necesitan evidencias distintas y no deben reducirse a un diagnóstico genérico de WebView o DNS.

Informe mínimo de reproducción

URL de vídeo y servicio:
Versión PipePipe / Android:
Endpoint antes y durante el fallo:
Con sesión o sin sesión:
País de red / VPN o proxy:
Tipo de vídeo y calidad/códec seleccionados, si se muestran:
DNS privado / bloqueador / cortafuegos y host bloqueado, si lo hay:
Punto del fallo (inicio / tiempo / seek / calidad / volver a app):
Mensaje visible e informe generado:
Prueba de una variable y resultado:

No confundir con WebView

El mensaje exacto WebView unavailable tiene su guía propia. Un WebView reciente no excluye red o SABR, y Source error no prueba que WebView necesite actualizarse.