¿YouTube bloquea youtube-transcript-api? 4 soluciones que funcionan

El error: funciona en local, bloqueado en producción

La librería de Python youtube-transcript-api es la forma más popular de obtener transcripciones de YouTube de forma programática. En tu máquina local suele funcionar sin un solo fallo. Pero en cuanto el código se ejecuta en un servidor en la nube, las peticiones empiezan a fallar con excepciones del tipo IpBlocked, RequestBlocked o TooManyRequests, a menudo con un mensaje que indica que YouTube está bloqueando tu IP.

Lo mismo le pasa a cualquier enfoque basado en scraping: los paquetes de transcripciones de Node.js, la extracción de subtítulos con yt-dlp y los scrapers caseros chocan todos contra el mismo muro. El detonante no es tu código, sino desde dónde salen tus peticiones.

Si tu carga de trabajo se ejecuta en AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io o cualquier VPS, YouTube ve una IP de centro de datos. Esos rangos de IP son públicos, están muy explotados por bots y se bloquean en bloque. Las conexiones residenciales (como el wifi de tu casa) rara vez se bloquean, y por eso aquí el clásico "en mi máquina funciona" es literalmente cierto.

Por qué YouTube bloquea estas peticiones

Las transcripciones de YouTube las sirve un endpoint interno y sin autenticación que nunca se diseñó para que lo usaran terceros. No existe ninguna API pública oficial para obtener la transcripción de un video cualquiera: el endpoint de subtítulos de la Data API oficial requiere autorización OAuth del propietario del video, así que solo sirve para tus propios videos.

Como ese endpoint interno es gratuito y no requiere autenticación, lo machacan empresas de IA, herramientas de SEO y todo tipo de scrapers. YouTube responde de la única forma que puede: limitando el número de peticiones de forma agresiva, bloqueando rangos enteros de IP de centros de datos y cambiando de vez en cuando el endpoint, lo que rompe las librerías de scraping de la noche a la mañana.

Esto significa que cualquier solución autoalojada entra en un juego del gato y el ratón permanente. Las cuatro soluciones que siguen van de la más artesanal a la más gestionada.

Solución 1: enrutar las peticiones por proxies residenciales

El arreglo clásico es enrutar tus peticiones a través de proxies residenciales rotativos, para que YouTube vea IP domésticas normales en lugar de tu servidor. Las versiones recientes de youtube-transcript-api lo soportan directamente: basta con pasar una configuración de proxy al construir el cliente (la librería incluye el helper WebshareProxyConfig, o puedes usar GenericProxyConfig con cualquier proxy HTTP o SOCKS).

Funciona, pero tiene un coste real. El ancho de banda de los proxies residenciales es caro (unos pocos dólares por GB), la calidad varía muchísimo de un proveedor a otro y estrenas un nuevo modo de fallo: cuando una IP del proxy se bloquea a mitad de una petición, necesitas lógica de reintentos, comprobaciones de estado y conmutación entre proveedores. Con volúmenes bajos también puede ser la opción más lenta, porque cada petición da un salto extra por la red de proxies.

Elige esta vía si necesitas control total, tienes tiempo de ingeniería para mantenerla y tu volumen es lo bastante alto como para justificar el montaje.

Solución 2: ejecutar el descargador en una conexión residencial

Una variante más sencilla: ejecuta la parte de tu pipeline que descarga las transcripciones en algún sitio con IP residencial —una Raspberry Pi en casa, un equipo de la oficina o un mini-PC barato— y que envíe los resultados a tu infraestructura en la nube mediante una cola o un webhook.

Así te ahorras por completo el coste de los proxies y, sorprendentemente, funciona bastante bien para cargas pequeñas y personales (transcribir videos para tus notas o para una newsletter modesta, por ejemplo). Los inconvenientes son evidentes: es un punto único de fallo físico, no escala y resulta una arquitectura incómoda para un producto en producción.

Solución 3: cachear a lo bestia y aplicar backoff ante los errores

Sea cual sea el método de descarga que uses, hay dos prácticas que reducen drásticamente la tasa de bloqueos. La primera: cachea todas las transcripciones que obtengas. Las transcripciones casi nunca cambian, así que no hay ninguna razón para pedir el mismo video dos veces. Una simple tabla en la base de datos indexada por ID de video elimina la mayor parte del tráfico repetido.

La segunda: trata los bloqueos como una señal, no como un error que haya que reintentar al instante. Un backoff exponencial con jitter (esperar 1 s, luego 2 s, 4 s, 8 s...) te mantiene bajo el radar. Machacar el endpoint después de un bloqueo es la forma más rápida de que baneen tu rango de IP entero.

Ten en cuenta que esto es mitigación, no una solución: en una IP de centro de datos, incluso tu primerísima petición puede acabar bloqueada. Combínalo con una de las otras tres soluciones.

Solución 4: usar una API de transcripciones alojada (sin infraestructura que mantener)

La opción gestionada: deja que un servicio que ya ha resuelto el problema de las IP obtenga las transcripciones por ti. ParseJet expone un único endpoint —POST /v1/parse/youtube con la URL del video— y devuelve la transcripción completa en JSON, junto con el título, el canal y la duración del video. Los bloqueos, la gestión de proxies y los cambios de endpoint se resuelven en el servidor, así que tu código son tres líneas y sigue siendo tres líneas.

Migrar desde youtube-transcript-api lleva unos minutos: sustituye la llamada a la librería por un único POST HTTP (funciona desde Python, Node.js o cualquier cosa que hable HTTP, incluidas las funciones serverless, que es justo donde el enfoque de librería tiene más papeletas para acabar bloqueado). Puedes pedir un idioma de subtítulos concreto con el parámetro language.

El plan gratuito incluye 300 créditos al mes (una transcripción de YouTube cuesta 5 créditos, o sea, 60 videos) y los planes de pago empiezan en 19 $/mes. Para la mayoría de productos, eso sale más barato que el ancho de banda de los proxies residenciales más el tiempo de ingeniería para vigilarlos.

¿Qué solución te conviene?

Proyecto personal, poco volumen y algo de soltura técnica: la solución 2 (una máquina residencial) es gratis y lo bastante fiable.

Volumen alto con ingeniería de infraestructura dedicada: la solución 1 (proxies residenciales rotativos) te da el máximo control; presupuesta el coste de los proxies y su mantenimiento continuo.

Aplicación en producción, agente o pipeline RAG donde las transcripciones son una función más y no tu negocio principal: la solución 4 (API alojada), una llamada HTTP y se acabó el gato y el ratón. En todos los casos, añade encima la solución 3 (caché y backoff).