Почему ваш парсер перестаёт работать после 10 000 запросов (и как это исправить)

Веб-скрейперы перестают работать после 10 000 запросов из-за четырех технических проблем: ухудшения репутации IP-адреса, обнаружения отпечатков, проблем с JavaScript и поведенческих аномалий. Эти сбои проявляются в виде ошибок 429, CAPTCHA, скрытой потери данных и сбоев конвейера.

В этой статье показано, как диагностировать каждый тип сбоя с помощью примеров на Python, и предлагаются готовые к использованию решения, включая ротацию прокси-серверов, регулирование запросов, стратегии пула соединений, а также рекомендации по переходу от сбора данных по каждому запросу к распределенным архитектурам веб-краулеров.

Почему веб-скрейперы перестают работать после 10 000 запросов?

При небольшом объеме трафика веб-сайт может воспринимать ваши действия как фоновый шум. При более высоком объеме современные системы защиты от ботов начинают анализировать вашу активность и применять соответствующие правила.

При приближении к отметке в 10 000 запросов вступают в действие несколько векторов обнаружения:

• Закономерности транспортного потока становятся поддающимися статистическому анализу.
• Пороги обнаружения ботов активируются
• Репутация IP-адреса начинает ухудшаться
• Аномалии поведения становятся очевидными со временем.

Современные системы защиты от ботов Анализ закономерностей происходит на основе множества запросов, а не только отдельных HTTP-вызовов. Это означает, что даже небольшие детали в поведении вашего парсера по сравнению с реальным браузером становятся обнаруживаемыми по мере роста объема данных.

Crawlbase В чем разница между веб-скрейпингом и самостоятельным сбором данных?

Вместо того чтобы создавать и поддерживать каждый слой самостоятельно, Crawlbase предоставляет вам готовый к использованию в производственной среде слой для сбора данных, позволяя сосредоточиться на извлечении информации и бизнес-логике.

Вот основные различия:

Проблема в масштабе	Подход «сделай сам»	Crawlbase подхода
Репутация IP-адреса ухудшается	Повернуть больше прокси	Использует управляемую маршрутизацию и средства защиты.
Отпечатки пальцев помечаются	Заголовки патчей бесконечно	Обеспечивает согласованность на уровне браузера.
Задания по JavaScript	Создавайте базы данных драматургов.	Используйте JavaScript-запросы при необходимости.
Страницы с CAPTCHA / проверкой	Повторяйте попытки, пока не получится.	Обнаружение и повторная попытка выполняются интеллектуально.
Тихие неудачи	Об этом узнаешь поздно.	Проверяйте и восстанавливайте данные стабильно.

Если объем работы по сбору данных имеет значение для получения дохода, аналитики или принятия решений по продукту, цель состоит не в том, чтобы «отправлять запросы». Цель — «постоянно получать корректные данные».

Каковы наиболее распространенные причины сбоев веб-скрейперов?

1. Ухудшение репутации интеллектуальной собственности.

Использование ротации прокси помогает, но само по себе этого недостаточно. Веб-сайты и системы защиты от ботов отслеживают:

• Репутация автономного системного номера (ASN)
• Использование прокси и повторное использование IP-адресов в разных сессиях
• Независимо от того, откуда поступают IP-адреса — из центров обработки данных, мобильных устройств или частных пулов.
• Историческое поведение диапазонов IP-адресов

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

2. Несоответствия в отпечатках браузера

Веб-серверы анализируют не только строки User-Agent. Они анализируют множество сигналов, которые вместе образуют «отпечаток пальца». Если рукопожатие TLS вашего парсера, подсказки клиента и наборы заголовков не совпадают с тем, что генерируют реальные браузеры, детекторы ботов оценивают ваш трафик как подозрительный. Академическое исследование Это показывает, что боты, пытающиеся изменить отпечатки пальцев, часто не могут добиться согласованности между атрибутами, что современные системы используют для обнаружения.

3. Нереалистичное поведение запроса

Реальные пользователи ведут себя не так, как парсеры.

Люди:

• Пауза между действиями
• Навигация по нелинейному маршруту
• Загрузите страницы разного формата, а не в идеальной последовательности.
• Создавайте «хаотичное» поведение, которое выглядит естественно.

Скребки часто:

• Обращайтесь к URL-адресам последовательно.
• Используйте фиксированное время или узкие петли.
• Никогда не загружайте дополнительные активы.
• Повторять одни и те же заголовки запроса бесконечно

Чем больше движение, тем заметнее становится закономерность.

4. Контроль доступа на основе JavaScript

Многие сайты используют JavaScript для следующих целей:

• Установить сессионные файлы cookie
• Запуск ботов: испытания
• Разблокируйте настоящий HTML
• Решите, показывать ли реальный контент или страницу-заглушку.

Вот почему попытки парсинга сайтов Amazon, Airbnb и подобных им часто заканчиваются непонятными результатами:

• Вы получаете HTTP 200 OK
• Но страница неполная, заблокирована или на ней отсутствуют необходимые вам данные.

Если вы не выполняете JavaScript, когда это необходимо, ваш парсер может «успешно работать», в то время как ваш конвейер обработки данных незаметно завершается с ошибкой.

5. Узкие места инфраструктуры

Даже если сайт вас никогда не блокирует, многие парсеры перестают работать из-за технических проблем:

• Исчерпание пула соединений
• Отсутствие экспоненциальной задержки
• Повторные попытки в случае шторма (повторные попытки увеличивают трафик и ускоряют блокировку)
• Отсутствует проверка содержимого.
• Отсутствует автоматический выключатель для защиты от повторных сбоев.

Эти проблемы редко проявляются во время локального тестирования. Они проявляются при длительной работе в больших объемах данных.

Как выглядит ошибка веб-скрейпера в реальных логах?

Это наиболее распространенный тип отказов:

403 Запрещено
Перенаправление на /captcha
Повторная попытка с новым прокси-сервером.
403 Запрещено

Сбой, остающийся незамеченным, хуже, потому что ваша система считает, что всё сработало. Пример:

200 ОК
Размер ответа: 700 байт

Но HTML-код содержит примерно следующее:

<название>Момент...</название>

Ваш парсер сообщает об успехе, но вы собираете мусор. Именно так конвейеры обработки данных ломаются незаметно для окружающих, пока не произойдет сбой в работе панелей мониторинга или последующих заданий.

Как исправить ошибки при веб-скрейпинге?

Наиболее распространенная ошибка, которую допускают команды, — это рассматривать это как «проблему, связанную с использованием посредников».

Они продолжают добавлять патчи:

• Больше прокси-провайдеров
• Повторные попытки
• Ещё несколько случайных заголовков
• Дальнейшие задержки

Такой подход обычно только усугубляет ситуацию, поскольку увеличивает трафик и усиливает подозрительные действия.

Настоящее решение проблемы заключается в устранении первопричин:

• Репутация IP-адреса и стратегия маршрутизации
• согласованность отпечатков браузера
• Рендеринг JavaScript при необходимости
• Обнаружение блоков и адаптивная логика повторных попыток
• Проверка возвращаемого HTML-кода перед его анализом.

Именно здесь и находится управляемая инфраструктура для сканирования, например... Crawlbase становится практическим решением.

Как вы используете Crawlbase для сбора данных

CrawlbaseОсновное решение заключается в следующем: Crawling APIДля отправки запроса к API достаточно просто отправить HTTP GET-запрос, используя любой удобный для вас инструмент или язык программирования. В приведенном ниже примере мы будем использовать Питон.

Вот как выполнить обычный запрос (без рендеринга JavaScript). Используйте этот способ, когда страница в основном статична и не требует запуска в браузере.

Импортировать Запросы
Импортировать urllib.parse
CRAWLBASE_TOKEN = "ВАШ_НОРМАЛЬНЫЙ_ТОКЕН"
target_url = "https://www.amazon.com/s?k=iPhone+17"
encoded_url = urllib.parse.quote(target_url, safe="")
ответ = запросы.получить(
    "https://api.crawlbase.com/",
    параметры={
        "токен": CRAWLBASE_TOKEN,
        "URL": encoded_url
    },
    тайм-аут =30
)
Распечатать("Статус:", ответ.код_статуса)
Распечатать("Предварительный просмотр тела:", response.text[:500])

Хотя это выглядит как простой HTTP-запрос, ключевое значение имеет то, что происходит за кулисами: маршрутизация запросов, предотвращение блокировок и средства контроля надежности, разработанные для производственных нагрузок.

Теперь для Рендеринг JavaScriptПросто замените свой API-ключ на... Crawlbase JavaScript-токен.

Импортировать Запросы
Импортировать urllib.parse
CRAWLBASE_TOKEN = "YOUR_JS_TOKEN"
target_url = "https://www.airbnb.com/rooms/1448335788418493498"
encoded_url = urllib.parse.quote(target_url, safe="")
ответ = запросы.получить(
    "https://api.crawlbase.com/",
    параметры={
        "токен": CRAWLBASE_TOKEN,
        "URL": encoded_url
    },
    тайм-аут =30
)
Распечатать("Статус:", ответ.код_статуса)
Распечатать("Предварительный просмотр тела:", response.text[:500])

Рендеринг с помощью JavaScript означает выполнение страницы в среде, аналогичной браузерной, чтобы динамический контент, сессионные файлы cookie и логика на стороне клиента загружались корректно до извлечения HTML-кода.

Это помогает предотвратить наиболее распространенную ошибку, когда «выглядит успешно, но на самом деле таковым не является»: 200 OK Ответы, содержащие текст-заполнитель вместо реальных данных.

Когда следует использовать Crawlbase Crawler Вместо API

Сбор данных по каждому запросу может быть эффективным, но становится ненадежным по мере роста объема запросов.

Использовать Crawlbase Crawler (Также известный как Enterprise Crawler) когда вам это понадобится:

1. Асинхронное сканирование десятков тысяч и миллионов страниц.
2. Запускать длительные задачи, которые должны выдерживать периодическую блокировку.
3. Масштабирование без создания собственной системы очередей и повторных попыток.
4. Автоматическое восстановление после сбоев и частичного выполнения программ.
5. Стандартизация процесса сбора данных между командами и проектами.

Другими словами: если ваша рабочая нагрузка представляет собой «задачу сканирования», а не «несколько URL-адресов», то модель сканирования обычно подходит лучше. Для настройки всего процесса от начала до конца вы можете следовать инструкциям. Crawlbase руководство по как использовать Crawler.

Что делает Crawlbase Надежность в масштабах предприятия

Веб-сайты, которые сложно индексировать, постоянно развиваются. Меняются средства защиты от ботов, HTML-код, а правила доступа ужесточаются.

Crawlbase Разработан для обработки больших объемов данных, требующих стабильной работы в течение недель или месяцев, а не только во время однодневного тестирования. Это включает в себя постоянные улучшения для решения следующих задач:

• Изменения в обнаружении ботов
• Задания по JavaScript
• Контроль доступа на основе сессий
• прерывания в стиле CAPTCHA
• Проверка и восстановление ответа

Если ваш конвейер обработки данных зависит от согласованности данных, это важнее, чем любой из этих «хитрых приёмов».

Окончательный вердикт

Парсеры не перестают работать после 10 000 запросов из-за плохого кода. Они перестают работать, потому что веб-сайты созданы для обнаружения масштабируемости.

Если вы хотите быстро стабилизировать свой конвейер сбора данных, начните с... Crawlbase Crawling API для надежного сбора данных по запросам, и перейти к Crawlbase Crawler когда вам требуется масштабируемый, долгосрочный, основанный на задачах сбор данных.

Зарегистрируйте Crawlbase и запустите сегодня свой первый тестовый обход.

Часто задаваемые вопросы (FAQ):

В: Почему скрейперы работают при тестировании, но терпят неудачу в больших масштабах?

A. Потому что на ранних этапах тестирования не срабатывают те же пороговые значения для защиты от ботов. Когда вы начинаете обрабатывать большой объем трафика, его становится легче анализировать, и небольшие несоответствия в поведении, заголовках и шаблонах сессий выявляются со временем.

В: Почему у меня возникает 200 OK Ответы есть, но данные отсутствуют?

A. Обычно это происходит из-за скрытой блокировки. Сервер возвращает действительный HTTP-статус, но HTML-код представляет собой страницу-заполнитель или страницу с запросом на проверку подлинности, а не реальный контент. Это часто случается на сайтах с большим количеством JavaScript или когда защита от ботов решает ухудшить качество ответа вместо того, чтобы полностью его заблокировать.

В: Когда следует использовать JavaScript-запросы вместо обычных запросов?

A. Используйте JavaScript-запросы, когда необходимый контент генерируется в браузере или когда сайт использует JavaScript для установки сессионных файлов cookie, выполнения проверок или разблокировки реального HTML-кода. Обычные запросы лучше подходят для страниц, где контент доступен непосредственно в исходном HTML-коде.