youtube-transcript-api blockiert? IP-Sperren auf AWS/GCP beheben

Das Skript lief wochenlang perfekt auf deinem Laptop. Dann hast du es deployt — Lambda, eine EC2-Kiste, Cloud Run, ein Heroku-Dyno, egal — und jeder einzelne Aufruf von youtube-transcript-api stirbt jetzt mit so etwas wie:
youtube_transcript_api._errors.IpBlocked:
Could not retrieve a transcript for the video ...
YouTube is blocking requests from your IP.
Oder die Browser-Variante derselben Wand: „Sign in to confirm you're not a bot." An deinem Code hat sich nichts geändert. Die Bibliothek ist nicht kaputt. Deine IP-Adresse ist das Problem.
Warum es nur in Produktion kaputtgeht
youtube-transcript-api funktioniert, indem es Untertiteldaten genauso abruft wie der YouTube-Player — kein API-Key, nur HTTP-Anfragen an YouTube. YouTube toleriert das von Wohnanschluss-Verbindungen, weshalb sich die lokale Entwicklung problemlos anfühlt. Aber die IP-Bereiche von AWS, GCP, Azure und Heroku sind öffentlich bekannt, und YouTube stellt Traffic aus diesen ASNs pauschal infrage. Es spielt keine Rolle, dass du drei Anfragen am Tag machst; die Sperre gilt der Netzwerk-Nachbarschaft, nicht deinem Verhalten. Instanz neu starten, neue Elastic IP holen, Funktion neu deployen — du landest auf einer anderen Adresse aus demselben gesperrten Pool.
Das lohnt sich zu verinnerlichen, denn der erste Instinkt (Retries einbauen, Delays einbauen, User-Agents rotieren) hilft nicht. Das Signal, auf das YouTube achtet, ist, woher die Pakete kommen.
Fix 1: eigene Residential-Proxys betreiben
Die Bibliothek unterstützt das direkt — sie bringt WebshareProxyConfig und eine GenericProxyConfig für beliebige Anbieter mit. Route die Anfragen über Residential-IPs und die Sperren hören größtenteils auf. Es funktioniert wirklich; so überlebt jeder, der YouTube in großem Stil scrapt.
Die ehrliche Kostenrechnung allerdings:
- Geld: Residential-Bandbreite kostet je nach Anbieter grob 3–8 $/GB, und ordentliche Anbieter wollen monatliche Verpflichtungen — realistisch 30–100 $/Monat, bevor du irgendetwas abgerufen hast. Jeder Transkript-Abruf ist klein (ein paar hundert KB), Bandbreite ist also nicht der Schmerz; die Mindestbeträge und der Account-Overhead sind es.
- Engineering: Rotation, Retry-bei-Sperre-Logik und Monitoring gehören dir. Auch Residential-IPs werden infrage gestellt, nur seltener — du musst Ausfälle also weiterhin erkennen und umrouten.
- Laufende Aufmerksamkeit: YouTube ändert Dinge. Proxy-Setups, die im März funktionierten, brauchen im Juni Pflege.
Wenn du ohnehin Proxy-Infrastruktur für anderes Scraping betreibst, ist das Anflanschen vertretbar. Wenn Transkripte das Einzige sind, was du brauchst, verpflichtest du dich, eine Proxy-Flotte zu betreiben, um einen einzigen Funktionsaufruf zu stützen.
Fix 2: einen Endpoint aufrufen, der diesen Kampf bereits führt
youtube2text.org erledigt die Residential-Proxy-Rotation serverseitig, deine Cloud-Funktion macht also eine langweilige HTTPS-Anfrage an eine normale API. Die Migration ist fast ein Find-and-Replace.
Vorher:
from youtube_transcript_api import YouTubeTranscriptApi
transcript = YouTubeTranscriptApi().fetch(video_id)
text = " ".join(snippet.text for snippet in transcript)
Nachher:
import requests
r = requests.get(
"https://youtube2text.org/api/transcribe",
params={"url": video_id}, # full URLs work too
headers={"x-api-key": "yt_YOUR_KEY"},
)
text = r.json()["result"]["content"]
Um es vor der Account-Erstellung auszuprobieren, hol dir den geteilten Demo-Key — curl -s https://youtube2text.org/api/demo-key — der 5 Videos/Monat pro IP erlaubt. Fehler kommen als strukturiertes JSON mit Codes zurück, die sich zu behandeln lohnen: TRANSCRIPT_UNAVAILABLE (404) heißt, das Video hat wirklich keine Untertitel — keine Sperre, und kein Proxy wird das beheben; RATE_LIMIT_EXCEEDED (429) enthält einen Retry-Hinweis. Eine ausführlichere Python-Anleitung gibt es im Python-Integrationsguide.
Welcher Fix zu dir passt
- Bleib bei youtube-transcript-api + eigenen Proxys, wenn du täglich Tausende Transkripte abrufst, schon Proxy-Accounts hast und jemand das Setup verantwortet. Bei dem Volumen kann Pro-GB-Preisgestaltung Pro-Video-Preise schlagen.
- Wechsle zu einem gehosteten Endpoint, wenn Transkripte ein Feature sind, nicht dein Produkt. Ein HTTP-Aufruf, JSON raus, und das Blocking-Problem ist der Pager von jemand anderem.
- Keiner der beiden behebt fehlende Untertitel. Für Videos, die
TRANSCRIPT_UNAVAILABLEliefern, ist der Fallback Speech-to-Text — siehe Whisper vs. YouTube-Untertitel dazu, wann sich die Kosten lohnen. Und falls du gerade stattdessen yt-dlp ausprobieren wolltest: Es trifft auf dieselbe IP-Sperre von Datacenter-Adressen aus.
Dein eigener Key (getrennt vom geteilten Demo-Kontingent) kostet eine Google-Anmeldung unter youtube2text.org/app/keys — der Free-Tier bietet 5 Videos/Monat, bezahlte Pläne von 5,99 $/Monat für 50 Videos bis 19,99 $ unbegrenzt. Keine Telefonnummer, keine Karte für den Free-Tier.