youtube-transcript-api von YouTube blockiert? 4 Lösungen, die funktionieren

Der Fehler: lokal grün, in Produktion blockiert

Die Python-Bibliothek youtube-transcript-api ist der verbreitetste Weg, YouTube-Transkripte programmatisch abzurufen. Auf dem eigenen Rechner funktioniert sie meist tadellos. Sobald der Code aber auf einem Cloud-Server läuft, schlagen die Anfragen mit Ausnahmen wie IpBlocked, RequestBlocked oder TooManyRequests fehl — oft mit einem Hinweis darauf, dass YouTube die IP-Adresse sperrt.

Dasselbe passiert bei jedem Scraping-Ansatz: Node.js-Transkript-Pakete, die Untertitel-Extraktion via yt-dlp und selbst gebaute Scraper laufen gegen dieselbe Wand. Auslöser ist nicht der Code, sondern der Ort, von dem die Anfragen kommen.

Läuft die Last auf AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io oder einem beliebigen VPS, sieht YouTube eine Rechenzentrums-IP. Diese IP-Bereiche sind öffentlich bekannt, werden massiv von Bots missbraucht und deshalb pauschal gesperrt. Private Anschlüsse wie das heimische WLAN werden dagegen selten blockiert — weshalb "bei mir läuft es" hier buchstäblich stimmt.

Warum YouTube diese Anfragen blockiert

YouTube-Transkripte werden von einem internen, nicht authentifizierten Endpunkt ausgeliefert, der nie für Dritte gedacht war. Eine offizielle öffentliche API zum Abruf von Transkripten beliebiger Videos gibt es nicht: Der Captions-Endpunkt der offiziellen Data API verlangt eine OAuth-Autorisierung durch den Kanalinhaber und funktioniert deshalb nur für eigene Videos.

Weil der interne Endpunkt kostenlos und ohne Authentifizierung erreichbar ist, wird er von KI-Firmen, SEO-Tools und Scrapern überrannt. YouTube reagiert auf die einzige Weise, die bleibt — mit aggressivem Rate-Limiting, flächendeckenden Sperren ganzer Rechenzentrums-IP-Bereiche und gelegentlichen Änderungen am Endpunkt, die Scraping-Bibliotheken über Nacht unbrauchbar machen.

Jede selbst gehostete Lösung steckt damit dauerhaft im Katz-und-Maus-Spiel. Die folgenden vier Lösungen sind von "maximal selbst gebaut" bis "vollständig verwaltet" sortiert.

Lösung 1: Anfragen über Residential-Proxys leiten

Der klassische Do-it-yourself-Weg: Anfragen über rotierende Residential-Proxys leiten, damit YouTube gewöhnliche Privatanschluss-IPs sieht statt des Servers. Aktuelle Versionen von youtube-transcript-api unterstützen das direkt — beim Erzeugen des Clients eine Proxy-Konfiguration übergeben (die Bibliothek bringt den Helfer WebshareProxyConfig mit, alternativ GenericProxyConfig für einen beliebigen HTTP- oder SOCKS-Proxy).

Das funktioniert, hat aber seinen Preis. Residential-Proxy-Traffic ist teuer (meist einige Dollar pro Gigabyte), die Qualität schwankt stark zwischen den Anbietern, und es entsteht eine neue Fehlerquelle: Wird eine Proxy-IP mitten in der Anfrage gesperrt, braucht es Retry-Logik, Health-Checks und Anbieter-Failover. Bei kleinen Volumen ist es zudem oft die langsamste Variante, weil jede Anfrage einen zusätzlichen Hop durch das Proxy-Netz nimmt.

Sinnvoll, wenn volle Kontrolle nötig ist, Entwicklungszeit für die Wartung da ist und das Volumen den Aufwand rechtfertigt.

Lösung 2: Den Abruf über einen Privatanschluss laufen lassen

Die einfachere Variante: Den Teil der Pipeline, der die Transkripte holt, an einem Ort mit privater IP betreiben — ein Raspberry Pi zu Hause, ein Rechner im Büro oder ein günstiger Mini-PC — und die Ergebnisse per Queue oder Webhook an die Cloud-Infrastruktur schicken.

Das spart die Proxy-Kosten komplett und funktioniert für kleine, private Workloads erstaunlich gut (etwa um Videos für eigene Notizen oder einen kleinen Newsletter zu transkribieren). Die Nachteile liegen auf der Hand: ein physischer Single Point of Failure, keine Skalierbarkeit und eine sperrige Architektur für ein produktives Produkt.

Lösung 3: Konsequent cachen und bei Fehlern zurückfahren

Unabhängig von der Abrufmethode senken zwei Praktiken die Sperrquote deutlich. Erstens: jedes abgerufene Transkript cachen — Transkripte ändern sich praktisch nie, es gibt also keinen Grund, dasselbe Video zweimal zu holen. Eine schlichte Datenbanktabelle mit der Video-ID als Schlüssel eliminiert den Großteil des wiederholten Traffics.

Zweitens: Sperren als Signal behandeln, nicht als Fehler, den man sofort erneut versucht. Exponentielles Backoff mit Jitter (1 s warten, dann 2 s, 4 s, 8 s …) hält die Anfragen unter dem Radar. Nach einer Sperre sofort weiter auf den Endpunkt zu hämmern, ist der schnellste Weg, den ganzen IP-Bereich zu verbrennen.

Das ist allerdings Schadensbegrenzung, keine Lösung: Auf einer Rechenzentrums-IP kann bereits die allererste Anfrage blockiert werden. Deshalb immer mit einer der anderen drei Lösungen kombinieren.

Lösung 4: Eine gehostete Transkript-API nutzen (keine Infrastruktur)

Die verwaltete Variante: Den Abruf einem Dienst überlassen, der das IP-Problem bereits gelöst hat. ParseJet bietet dafür einen einzigen Endpunkt — POST /v1/parse/youtube mit der Video-URL — und liefert das vollständige Transkript samt Videotitel, Kanal und Dauer als JSON. Sperren, Proxy-Verwaltung und Endpunkt-Änderungen werden serverseitig abgefangen; der eigene Code bleibt bei drei Zeilen.

Der Umstieg von youtube-transcript-api dauert wenige Minuten: den Bibliotheksaufruf durch einen HTTP-POST ersetzen (funktioniert aus Python, Node.js oder allem, was HTTP spricht — auch aus Serverless-Funktionen, wo der Bibliotheksansatz am ehesten blockiert wird). Eine bestimmte Untertitelsprache lässt sich über den Parameter language anfordern.

Das kostenlose Kontingent umfasst 300 Credits pro Monat (ein YouTube-Transkript kostet 5 Credits, also 60 Videos), bezahlte Pläne starten bei 19 $/Monat. Für die meisten Produkte ist das günstiger als Residential-Proxy-Traffic plus die Entwicklungszeit, ihn zu betreuen.

Welche Lösung passt wann?

Privatprojekt, geringes Volumen, technisch versiert: Lösung 2 (Rechner am Privatanschluss) ist kostenlos und zuverlässig genug.

Hohes Volumen mit eigenem Infrastruktur-Team: Lösung 1 (rotierende Residential-Proxys) bietet die meiste Kontrolle — Proxy-Kosten und laufende Wartung einkalkulieren.

Produktiv-App, Agent oder RAG-Pipeline, in der Transkripte ein Feature und nicht das Kerngeschäft sind: Lösung 4 (gehostete API) — ein HTTP-Aufruf, kein Katz-und-Maus-Spiel. In allen Fällen gilt: Lösung 3 (Caching und Backoff) obendrauf.