youtube-transcript-api блокируется YouTube? 4 рабочих решения

Ошибка: локально работает, в продакшене — блокировка

Python-библиотека youtube-transcript-api — самый популярный способ программно получать транскрипции с YouTube. На локальной машине она обычно работает безупречно. Но стоит коду переехать на облачный сервер, как запросы начинают падать с исключениями IpBlocked, RequestBlocked или TooManyRequests — часто с сообщением о том, что YouTube заблокировал ваш IP.

То же самое происходит с любым подходом, основанным на скрейпинге: Node.js-пакеты для субтитров, выгрузка через yt-dlp и самописные скрейперы упираются в ту же стену. Триггер — не ваш код, а то, откуда приходят запросы.

Если нагрузка крутится на AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io или на любом VPS, YouTube видит IP-адрес дата-центра. Эти диапазоны общеизвестны, ими активно злоупотребляют боты, и блокируют их оптом. Домашние (резидентные) подключения блокируют редко — поэтому «на моей машине работает» здесь буквально правда.

Почему YouTube блокирует такие запросы

Транскрипции отдаёт внутренний эндпоинт без авторизации, который никогда не задумывался для стороннего использования. Официального публичного API для получения транскрипций произвольных видео не существует: эндпоинт субтитров в официальном Data API требует OAuth-авторизации от владельца видео, то есть работает только с вашими собственными роликами.

Именно потому, что внутренний эндпоинт бесплатен и не требует авторизации, его нещадно долбят AI-компании, SEO-инструменты и скрейперы. YouTube отвечает единственным доступным ему способом — жёстким рейт-лимитом, массовой блокировкой диапазонов дата-центров и периодическими изменениями эндпоинта, которые за одну ночь ломают скрейпинговые библиотеки.

Это значит, что любое самостоятельное решение обречено на бесконечную игру в кошки-мышки. Четыре решения ниже отсортированы от самого «сделай сам» до полностью управляемого.

Решение 1: пускать запросы через резидентные прокси

Стандартный самодельный обходной путь — гонять запросы через ротируемые резидентные прокси, чтобы YouTube видел обычные домашние IP вместо вашего сервера. Свежие версии youtube-transcript-api поддерживают это из коробки: при создании клиента передайте конфигурацию прокси (в библиотеке есть хелпер WebshareProxyConfig, либо используйте GenericProxyConfig с любым HTTP/SOCKS-прокси).

Работает — но не бесплатно. Трафик резидентных прокси стоит дорого (обычно несколько долларов за гигабайт), качество у провайдеров разное, и вы получаете новый источник отказов: когда IP прокси блокируется посреди запроса, нужны ретраи, health-check и переключение между провайдерами. На малых объёмах это ещё и самый медленный вариант — каждый запрос идёт лишним хопом через прокси-сеть.

Выбирайте этот путь, если нужен полный контроль, есть инженерное время на поддержку, а объёмы достаточно велики, чтобы окупить настройку.

Решение 2: запускать сборщик на домашнем подключении

Вариант попроще: держать ту часть пайплайна, которая забирает транскрипции, там, где есть резидентный IP — на Raspberry Pi дома, на офисной машине или на дешёвом мини-ПК, — а результаты отправлять в облако через очередь или вебхук.

Так вы полностью избегаете расходов на прокси, и для небольших личных задач (транскрипции для своих заметок или маленькой рассылки) это работает на удивление хорошо. Минусы очевидны: физическая единая точка отказа, никакого масштабирования и неуклюжая архитектура для продуктового продакшена.

Решение 3: агрессивно кэшировать и отступать при ошибках

Каким бы способом вы ни забирали данные, две практики резко снижают долю блокировок. Первая — кэшировать каждую полученную транскрипцию: они практически не меняются, так что запрашивать одно и то же видео дважды незачем. Обычная таблица в базе с ключом по ID видео убирает большую часть повторного трафика.

Вторая — воспринимать блокировку как сигнал, а не как ошибку, которую надо немедленно повторить. Экспоненциальная задержка с джиттером (подождать 1 с, потом 2, 4, 8...) помогает не попадаться на радары. Долбить эндпоинт сразу после блокировки — кратчайший путь к бану всего вашего диапазона IP.

Учтите: это смягчение, а не решение — на IP дата-центра могут заблокировать даже самый первый запрос. Комбинируйте с одним из трёх остальных вариантов.

Решение 4: взять готовый API транскрипций (без своей инфраструктуры)

Управляемый вариант: отдать проблему с IP сервису, который её уже решил. У ParseJet один эндпоинт — POST /v1/parse/youtube со ссылкой на видео — и он возвращает полную транскрипцию вместе с названием, каналом и длительностью в JSON. Блокировки, управление прокси и изменения эндпоинта остаются на стороне сервера, так что ваш код — это три строки, и он такими тремя строками и остаётся.

Переезд с youtube-transcript-api занимает несколько минут: замените вызов библиотеки одним HTTP POST (работает из Python, Node.js и вообще откуда угодно, где есть HTTP — включая serverless-функции, где библиотечный подход блокируется чаще всего). Конкретный язык субтитров запрашивается параметром language.

Бесплатный тариф включает 300 кредитов в месяц (транскрипция YouTube стоит 5 кредитов, то есть 60 видео), платные тарифы начинаются от $19/мес. Для большинства продуктов это дешевле, чем трафик резидентных прокси плюс инженерное время на присмотр за ними.

Какое решение выбрать?

Личный проект, небольшие объёмы, вы не боитесь техники: решение 2 (машина с домашним IP) — бесплатно и достаточно надёжно.

Большие объёмы и своя инфраструктурная команда: решение 1 (ротируемые резидентные прокси) даёт максимум контроля — заложите бюджет на прокси и на постоянную поддержку.

Продуктовое приложение, агент или RAG-пайплайн, где транскрипции — это фича, а не суть вашего бизнеса: решение 4 (готовый API) — один HTTP-вызов и никаких кошек-мышек. И в любом случае добавьте сверху решение 3 (кэш и бэкофф).