youtube-transcript-api blokowane przez YouTube? 4 działające rozwiązania

Błąd: lokalnie działa, na produkcji blokada

Pythonowa biblioteka youtube-transcript-api to najpopularniejszy sposób na programowe pobieranie transkrypcji z YouTube. Na lokalnej maszynie zwykle działa bezbłędnie. Ale gdy tylko kod trafi na serwer w chmurze, żądania zaczynają kończyć się wyjątkami IpBlocked, RequestBlocked albo TooManyRequests — często z komunikatem sugerującym, że YouTube zablokował Twoje IP.

To samo spotyka każde podejście oparte na scrapowaniu: pakiety transkrypcyjne w Node.js, pobieranie napisów przez yt-dlp i własnoręcznie napisane scrapery uderzają w tę samą ścianę. Problemem nie jest Twój kod, lecz miejsce, z którego wychodzą żądania.

Jeśli Twoje zadanie działa na AWS Lambda, Google Cloud Run, Vercelu, Railway, Fly.io albo dowolnym VPS-ie, YouTube widzi adres IP centrum danych. Te zakresy adresów są publicznie znane, masowo nadużywane przez boty i blokowane hurtowo. Łącza domowe (jak Twoje Wi-Fi) blokowane są rzadko — dlatego „u mnie działa” jest tu dosłownie prawdą.

Dlaczego YouTube blokuje takie żądania

Transkrypcje YouTube są serwowane przez wewnętrzny, nieuwierzytelniony endpoint, którego nigdy nie zaprojektowano do użytku przez firmy trzecie. Nie istnieje oficjalne publiczne API do pobierania transkrypcji dowolnych filmów: endpoint captions w oficjalnym Data API wymaga autoryzacji OAuth od właściciela filmu, więc zadziała wyłącznie dla Twoich własnych materiałów.

Ponieważ wewnętrzny endpoint jest darmowy i nie wymaga uwierzytelnienia, jest bezlitośnie eksploatowany przez firmy AI, narzędzia SEO i scrapery. YouTube reaguje jedynym dostępnym sposobem — agresywnym limitowaniem żądań i hurtowym blokowaniem zakresów IP centrów danych, a od czasu do czasu zmienia endpoint, co z dnia na dzień psuje biblioteki scrapujące.

Oznacza to, że każde samodzielnie utrzymywane rozwiązanie skazane jest na wieczną grę w kotka i myszkę. Cztery poniższe rozwiązania uszeregowaliśmy od najbardziej „zrób to sam” do w pełni zarządzanego.

Rozwiązanie 1: kieruj żądania przez proxy rezydencjalne

Standardowy sposób „zrób to sam” to kierowanie żądań przez rotujące proxy rezydencjalne, dzięki czemu YouTube widzi zwykłe domowe adresy IP zamiast Twojego serwera. Nowsze wersje youtube-transcript-api wspierają to wprost: przy tworzeniu klienta przekazujesz konfigurację proxy (biblioteka udostępnia pomocnika WebshareProxyConfig, a przez GenericProxyConfig podłączysz dowolne proxy HTTP lub SOCKS).

To działa, ale ma realną cenę. Transfer przez proxy rezydencjalne jest drogi (zwykle kilka dolarów za gigabajt), jakość dostawców bywa bardzo różna, a Ty dokładasz sobie nowy tryb awarii: gdy IP proxy zostanie zablokowane w trakcie żądania, potrzebujesz logiki ponawiania, health-checków i przełączania między dostawcami. Przy małych wolumenach bywa to też najwolniejsza opcja, bo każde żądanie wykonuje dodatkowy skok przez sieć proxy.

Wybierz tę drogę, jeśli potrzebujesz pełnej kontroli, masz czas inżynierski na utrzymanie tego rozwiązania, a Twój wolumen uzasadnia koszt wdrożenia.

Rozwiązanie 2: uruchom pobieranie na łączu domowym

Prostszy wariant: uruchom tę część potoku, która pobiera transkrypcje, tam, gdzie masz adres IP z sieci domowej — na Raspberry Pi w domu, komputerze w biurze albo tanim mini-PC — a wyniki niech przesyła do infrastruktury w chmurze przez kolejkę lub webhook.

Takie podejście całkowicie eliminuje koszty proxy i zaskakująco dobrze sprawdza się przy małych, prywatnych zastosowaniach (transkrypcje filmów do własnych notatek czy niewielkiego newslettera). Wady są oczywiste: to fizyczny pojedynczy punkt awarii, rozwiązanie się nie skaluje, a architektura jest niezręczna dla produktu na produkcji.

Rozwiązanie 3: agresywnie cachuj i wycofuj się przy błędach

Niezależnie od metody pobierania dwie praktyki drastycznie zmniejszają liczbę blokad. Po pierwsze, cachuj każdą pobraną transkrypcję — transkrypcje praktycznie się nie zmieniają, więc nie ma powodu pobierać tego samego filmu dwa razy. Zwykła tabela w bazie z kluczem po identyfikatorze wideo eliminuje większość powtórzonego ruchu.

Po drugie, traktuj blokadę jako sygnał, a nie błąd do natychmiastowego ponowienia. Wykładniczy backoff z losowym odchyleniem (odczekaj 1 s, potem 2 s, 4 s, 8 s...) pozwala pozostać poniżej radaru. Dobijanie się do endpointu tuż po blokadzie to najszybsza droga do zbanowania całego Twojego zakresu IP.

Pamiętaj: to łagodzenie skutków, a nie rozwiązanie — na adresie IP z centrum danych nawet pierwsze żądanie może zostać zablokowane. Połącz je z jednym z pozostałych trzech sposobów.

Rozwiązanie 4: skorzystaj z hostowanego API do transkrypcji

Opcja zarządzana: pozwól, aby transkrypcje pobierał serwis, który problem blokad już rozwiązał. ParseJet udostępnia jeden endpoint — POST /v1/parse/youtube z adresem filmu — i zwraca pełną transkrypcję razem z tytułem, nazwą kanału i czasem trwania w formacie JSON. Blokady, zarządzanie proxy i zmiany w endpointach są obsługiwane po stronie serwera, więc Twój kod ma trzy linijki i takim pozostanie.

Migracja z youtube-transcript-api zajmuje kilka minut: zastępujesz wywołanie biblioteki jednym żądaniem POST (działa z Pythona, Node.js i wszystkiego, co mówi po HTTP — również z funkcji serverless, gdzie biblioteka blokowana jest najczęściej). Konkretny język napisów wskażesz parametrem language.

Darmowy pakiet obejmuje 300 kredytów miesięcznie (transkrypcja z YouTube kosztuje 5 kredytów, czyli 60 filmów), a płatne plany zaczynają się od 19 USD/miesiąc. Dla większości produktów to taniej niż transfer przez proxy rezydencjalne plus czas inżynierów na pilnowanie tego wszystkiego.

Które rozwiązanie wybrać?

Projekt prywatny, mały wolumen, komfort techniczny: rozwiązanie 2 (maszyna na łączu domowym) jest darmowe i wystarczająco niezawodne.

Duży wolumen i własny zespół infrastruktury: rozwiązanie 1 (rotujące proxy rezydencjalne) daje największą kontrolę — zaplanuj budżet na proxy i bieżące utrzymanie.

Aplikacja produkcyjna, agent lub potok RAG, w którym transkrypcje są funkcją, a nie sednem biznesu: rozwiązanie 4 (hostowane API) — jedno wywołanie HTTP i koniec gry w kotka i myszkę. W każdym z tych scenariuszy dołóż jeszcze rozwiązanie 3 (cache i backoff).