HomeBlogTranscribePlansAPI Keys

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

Python-Traceback mit einem IpBlocked-Fehler von youtube-transcript-api auf einem Cloud-Server

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:

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

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.