Какие приёмы веб-скрапинга позволяют обойти блокировки?

Этот материал мы задумывали как чуть более предметную версию общих советов – как парсить без блокировок. Дело в том, что методы выявления ботов и скриптов автоматизации совершенствуются каждый день, да и сами сайты становятся сложнее. Соответственно, уклоняться от блокировок всё тяжелее и тяжелее.

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

Какие механизмы защиты сейчас можно встретить на сайтах

Чтобы понять, какие методы для уклонения от блокировщиков существуют в веб-парсинге, нужно для начала разобраться с технологиями защиты. Зная основные подходы, можно выработать более-менее адекватные средства и логику обхода.

Итак, «база», которая всегда была и ещё какое-то время будет оставаться актуальной:

• Проверка IP-адреса клиента на качество. В первую очередь IP проверяются по спам-базам, а также на основе таблиц блокировки внутренней или внешней системы защиты. Даже расположение IP может иметь значение.
• Частота запросов с одного IP. Ни один живой человек не сможет открыть и просмотреть сотни или даже десятки страниц за несколько секунд. Подсчёт переходов с одного IP организовать проще простого.
• Адреса-ловушки и honeypot’ы. Тут логика простая – если клиент пытается обратиться к адресу сайта или к веб-форме (полю ввода), которые живой клиент никогда в жизни не найдёт на страницах, то он – бот. Такие ссылки или формы можно прятать в HTML-коде, а парсер будет ставить их в очередь на обход или пытаться заполнить. Первое же обращение – бан.
• Проверка User-Agent’а и HTTP-заголовков. То, как представляется клиент, очень важно. Даже если попытаться представиться именем любого современного браузера, то система защиты может сверить параметры комплексного цифрового отпечатка с эталоном. И если расхождения есть, то клиента могут либо заблокировать полностью, либо перенаправить на форму подтверждения «человечности» (например, CAPTCHA).

Надёжные методы для обхода CAPTCHA.

Более сложные системы защиты могут предусматривать следующие механизмы выявления ботов:

• Проверка исполнения JavaScript. Все современные браузеры без исключения умеют выполнять JS-скрипты на стороне клиента.
• Проброс специальных токенов. Обычно ими защищаются формы, но может защищаться и процесс подгрузки новых страниц.
• Анализ поведения пользователя – как он шевелит мышкой, прокручивает страницы, печатает символы в полях, переходит по ссылкам (боты могут обходить URL по алфавиту, по порядку расположения в коде страницы и т.п., человек так делать не будет).
• Усложнение HTML-кода и DOM-структуры – чтобы парсер не мог вычленить повторяющиеся конструкции и синтаксис для поиска нужного содержимого. Каждая страница технически становится уникальной.
• Проверка Cookies и других параметров цифрового отпечатка – шрифты, разрешение экрана, аппаратные характеристики и доступные устройства, локаль, языковые настройки, часовой пояс и прочее. В более сложных вариантах может даже производиться сверка местоположения маркеров (контрольных точек) для итогового рендеринга страниц при заявленных характеристиках устройства пользователя. Fingerprint и Web Scraping: как они связаны.
• Невидимая капча и WAF-системы. За защиту сайта может отвечать профильный сервис, который сам по себе имеет огромную базу по подозрительным действиям со стороны клиентов. Например, как Cloudflare.

Как обойти защиту Cloudflare от ботов: вариант веб-скрапинга с Puppeteer.

Что особо примечательно, топовые системы защиты научились быстро выявлять отпечатки headless-браузеров. Поэтому предварительный рендеринг через веб-драйверы может не спасти.

Согласитесь, впечатляет? Но нужно понимать, что любая система защиты требует вложений. У малых сайтов обычно нет продвинутых механизмов выявления ботов – максимум, простейшие скрипты на подсчёт частоты обращений. И то не всегда.

Какие методы для уклонения от блокировщиков существуют в веб-парсинге

Так как же быть? Есть ли лучшие практики для веб-парсинга? Да, есть и мы сейчас расскажем о них в порядке возрастания сложности противодействия основным механизмам защиты.

0. Чем дешевле получается парсинг, тем лучше

Напомним, универсального подхода парсинга, который бы подошёл ко всем типам сайтов нет и не будет. Это невозможно даже в теории, так как все сайты и их механизмы защиты разные.

Ключевым «мерилом» эффективности любого парсера можно назвать стоимость обработки одного запроса или страницы. Оценка условная и она может складываться из разных факторов. Но даже новичку будет понятно, что если вы используете рендеринг страниц в headless-браузере, имитируете разные механики «человеческого» поведения скриптов и распознаёте код с помощью ИИ, то это будет максимально дорого, так как для обсчёта одной страницы потребляется нереально много ресурсов и времени.

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

1. Качественные ротируемые прокси

Что называется «маст хэв» для любого скрипта при массовом сборе данных.

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

«Качество» прокси – это невозможность отделения IP вашего бота от IP реальных пользователей.

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

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

Нужны прокси для профессионального парсинга? Заказывайте их у нас. Froxy – это миллионы резидентных и мобильных прокси с максимальным уровнем доверия.

2. Парсинг по API должен быть в приоритете

Простой пример: мы недавно описывали, как парсить комментарии YouTube. Официальный API предоставляется абсолютно бесплатно – до 10 тыс. запросов в сутки, на каждый запрос можно получить до 100 комментариев. Если этого недостаточно, можно создать несколько аккаунтов и настроить их работу через несколько параллельных прокси для парсинга.

Да, сервис выдаёт только комментарии первого уровня, но зато кратно ускоряет процесс сбора и обработки данных, а также делает его недорогим. Смотри нулевой пункт.

Но если взять в противовес парсинг, например, данных из Google Trends, то тут уже официального API нет – он доступен пока только избранным. Попытка собрать данные «в лоб» будет максимально сложной и ресурсоёмкой – страницы Google Trends имеют нечитаемую DOM-структуру, она уникальна для каждой сессии за счёт автоматически генерируемых CSS-классов.

Читайте по теме: Скрапинг сайтов с динамическим контентом с Python.

В итоге выходом становится обращение к неофициальному API на уровне эндпоинтов. В сети масса готовых технических реализаций, которые извлекают данные в JSON-формате. Например, Python-библиотека pytrends-modern или исходный старый pytrends. Такой парсер не нуждается в разборе «нечитаемого» HTML-кода, работает быстро и не потребляет много ресурсов. Даже если для первичного обращения к сайту нужен headless-браузер – он извлекает только уникальный токен из сессии.

3. «Очеловечивание» поведения парсера с постепенным усложнением

Ещё одна из «лучших практик» профессионального веб-парсинга. Она тесно связана со скрытием следов и признаков известных библиотек или фреймворков для парсинга. Одно без другого просто невозможно.

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

Чтобы не тратить вычислительные ресурсы понапрасну, следует постепенно усложнять цифровой отпечаток бота – до тех пор, пока он не начнёт проходить проверки систем защиты.

Самые быстрые архитектуры – на основе HTTP-клиентов. Но они подходят только для сайтов, которые используют минимум JS-кода. К параметрам цифровых отпечатков здесь можно отнести: частоту запросов (решается сбалансированными задержками между запросами и ограничением числа параллельных потоков парсинга), наличие cookies, правильный User-Agent и некоторые другие HTTP-заголовки (реферер, локаль и т.п.).

import random
import time
import requests


def human_delay():
    """
    Реалистичные задержки между запросами.
    Короткие паузы происходят чаще,
    длинные — реже.
    """
    delay = random.uniform(1.5, 4.5)

    # Иногда пользователь "читает страницу"
    if random.random() < 0.2:
        delay += random.uniform(5, 12)

    time.sleep(round(delay, 2))


session = requests.Session()

# Базовые cookies, имитирующие обычную браузерную сессию
session.cookies.update({
    "_ga": "GA1.1.1742451113.1747821001",
    "_gid": "GA1.1.998877665.1747821001",
    "visitor_id": "v-1747821001551",
    "session_id": "8f31d7d2f8d04d0f92a1",
    "locale": "ru",
})

# Максимально правдоподобный профиль Chrome под Windows
HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/136.0.0.0 Safari/537.36"
    ),
    "Accept": (
        "text/html,application/xhtml+xml,"
        "application/xml;q=0.9,image/avif,image/webp,"
        "image/apng,*/*;q=0.8"
    ),
    "Accept-Language": (
        "ru-RU,ru;q=0.9,"
        "en-US;q=0.8,en;q=0.7"
    ),
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Cache-Control": "max-age=0",
    "DNT": "1",
    # Browser Client Hints
    "Sec-CH-UA": (
        '"Chromium";v="136", '
        '"Google Chrome";v="136", '
        '"Not.A/Brand";v="99"'
    ),
    "Sec-CH-UA-Mobile": "?0",
    "Sec-CH-UA-Platform": '"Windows"',
    # Fetch Metadata
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
    # Типичный Referer после перехода из поиска
    "Referer": "https://www.google.com/",
}

urls = [
    "https://example.org/",
    "https://example.org/catalog/",
    "https://example.org/product/123/",
]

for url in urls:
    human_delay()
    response = session.get(
        url,
        headers=HEADERS,
        timeout=20,
        allow_redirects=True,
    )
    print("=" * 80)
    print(f"URL: {url}")
    print(f"STATUS: {response.status_code}")
    print(f"CONTENT LENGTH: {len(response.text)}")

Крупные IT-корпорации и веб-сервисы давно перешли на JavaScript. Соответственно, для рендеринга содержимого уже нужны headless- или антидетект-браузеры. Технически каждый такой браузер уже имеет свой профиль, но его же можно настроить вручную. Плюс обязательно нужно помнить о необходимости скрытия стандартных признаков headless-браузеров, которые активны в нём «из коробки».

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

4. «Лучшие практики» с точки зрения этики – для соблюдения легальности парсинга

На первый взгляд всё просто:

• Не нарушай правила и директивы, которые обозначены для ботов в robots.txt.
• Соблюдай разумную нагрузку и не приводи к эффекту DDoS.
• Если есть официальный API и сжатие, используй их.
• Изучи пользовательское соглашение и не нарушай его требований.
• Собирай только те данные, которые тебе нужны.
• Исключай персональную информацию или обезличивай её.
• Максимально кешируй обращения и очищай очередь, чтобы не ходить по кругу – по одним и тем же страницам по несколько раз.
• Анализируй ошибки и увеличивай задержки при недоступности сервиса. Имей терпение.
• Сохраняй подробные логи, они могут помочь не только при анализе работы парсера, но и для твоей же защиты в случае споров и проблем.

Но на практике многие забывают об этих нюансах, как только получают свой первый рабочий скрипт парсинга – того, который возвращает данные в нужном формате.

До «этичности» нужно ещё дорасти. Понимание приходит только со временем.

Но чем этичнее будет работать ваш парсер, тем ниже будут шансы его блокировки.

Заключение

Учитывайте, что в некоторых ситуациях можно вообще не писать никаких парсеров, если воспользоваться облачными сервисами, такими как Froxy Scraper. Вы сможете получать необходимые данные в готовом виде – по нашему API.

Однако, если от создания своего парсера никак не отказаться, помните о правилах, которые мы обозначили выше.

Froxy в Telegram

Присоединяйтесь к нашему сообществу в Telegram, чтобы быть в курсе всех новостей.

Присоединиться