Как прикинуться человеком: парсинг без блокировок

Есть такой тест Тьюринга — машина пытается убедить человека, что она тоже человек. В парсинге всё работает ровно наоборот: это сайт пытается понять, что ты не человек, а ты пытаешься убедить его в обратном. И чем лучше ты понимаешь, как именно сайт на тебя смотрит — тем проще это сделать. Разберём по слоям.

Слой первый: выглядеть как человек

Я пишу парсеры на Playwright — это инструмент, который управляет настоящим браузером: Chromium, WebKit или Firefox. Не эмулирует HTTP-запросы, а запускает реальный движок, как это делает обычный пользователь.

Но одного этого мало. Дело в том, что headless-браузер по умолчанию выдаёт себя сам: в заголовках есть характерные признаки, navigator.webdriver торчит как флаг, параметры окружения отличаются от обычного Chrome. Антибот-системы знают эти признаки наизусть, и никакой маскировки тут нет — просто написано “я бот” другими словами. Playwright позволяет всё это перенастроить: правильный User-Agent, правильные заголовки, правильные параметры запуска.

Следующий шаг — настройка fingerprint. Надо понимать, что крупные сайты — это большие системы, получающие данные из множества источников: рекламные трекеры, счётчики посещений, метки отслеживающих систем, поведенческие аналитики. Всё это формирует профиль ещё до того, как вы зашли на целевой сайт, и этому профилю надо соответствовать. Браузер с пустыми куками сразу вызывает вопрос — либо параноик, либо бот, чаще конечно второе. Поэтому перед стартом сессии я прохожусь по небольшому списку обычных сайтов, на которых есть и счётчики и рекламные трекеры — всё для того, чтобы эти системы создали у себя наш fingerprint, и при заходе на целевой сайт уже дали сигнал: человек свой, вот его профиль.

И последнее в этом слое — IP-адрес. Серверные адреса из датацентров палятся быстро, потому что их диапазоны хорошо известны антибот-системам — такие адреса сразу выглядят как красный флаг для любого крупного сайта. Выбор здесь однозначный: резидентные прокси. Да, дороже в разы, но работают там, где серверные уже не пустят.

Слой второй: вести себя как человека

Хорошо, технически мы уже похожи на человека. Но этого недостаточно — надо ещё и вести себя соответственно.

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

Казалось бы, мы теряем время на эти лишние действия. На самом деле нет — и вот почему. Сессия, которая ведёт себя естественно, живёт дольше, а поднять новую сессию стоит ресурсов: новый адрес из пула прокси, новый инстанс браузера, новый прогрев куков. Потратить несколько секунд на скролл чтобы сессия работала часами — это не потеря, это инвестиция. Разница между “100 страниц за один прогон” и “тысячи попыток вхолостую” вполне ощутимая.

Ещё один момент, который не очевиден сразу: я всегда захожу сначала на главную страницу сервиса, а уже потом перехожу к нужному разделу. Пользователь, который появляется прямо на странице с результатами поиска или на карточке товара и сразу начинает активно кликать — выглядит подозрительно, потому что так люди себя не ведут. Зашёл на главную, осмотрелся, пошёл дальше — совсем другое дело.

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

Отдельно про капчу. Многие воспринимают её как задачу которую надо решить: купить сервис распознавания, встроить в пайплайн, и двигаться дальше. Но это неправильная постановка вопроса, потому что капча — это не препятствие, это индикатор. Она говорит о том, что система уже считает тебя подозрительным, и степень подозрения напрямую влияет на то, что ты увидишь. Яндекс, например, иногда показывает капчу которая решается одним кликом в нужное поле — но только если ты просто подозреваемый. Если тебя считают ботом — покажут графическую: сложную, медленную, дорогую в решении. Правильная цель не “решать капчи быстро”, а “никогда до них не доходить”.

Слой третий: думать как инженер

Современные сайты часто отдают данные не в HTML, а через XHR-запросы: страница загружается, а потом подтягивает данные отдельными запросами к API. Когда видишь это в DevTools, возникает соблазн найти эти endpoints и дёргать их напрямую через обычный fetch, минуя браузер совсем — быстро, дёшево, никаких накладных расходов.

Владельцы сайтов не дураки: endpoints закрываются токеном, проверяют строго кто их запросил и откуда, заодно проверяется fingerprint — в результате данные вы получите в лучшем случае пару раз, а дальше 429 ошибка остановит ваш парсинг навсегда.

А вот что работает хорошо. Когда Playwright открывает страницу, все XHR-запросы проходят через браузер со всеми правильными заголовками, куками и контекстом — именно так, как это делает живой пользователь. Через page.on('response', ...) можно слушать все сетевые события и перехватывать нужные ответы прямо в момент загрузки страницы. Браузер получил JSON — мы его тоже получили, асинхронно и без лишних движений. Не надо парсить DOM, не надо искать данные в селекторах, которые сломаются при следующем редизайне.

Какой именно запрос перехватывать — надо посмотреть руками в DevTools один раз и разобраться в структуре. Это и есть работа инженера: понять как устроена система, выбрать оптимальную стратегию, принять решение. Не закидывать всё в LLM с надеждой на чудо — здесь нужно думать, а не генерировать.

Масштабирование: больше надо — больше взял

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

Важный принцип здесь — не пытаться выжать максимум из одной сессии, гоняя её на пределе. Это прямой путь к блокировкам, капчам и нестабильной работе. Гораздо лучше иметь десять спокойных инстансов в нормальном темпе, чем один агрессивный, который постоянно валится и требует перезапуска.

Архитектура: один раз настроил — используешь везде

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

Для каждого нового сайта пишется только модуль с бизнес-логикой — какие данные нужны, где они лежат, как до них добраться. Всё специфичное для конкретного ресурса только здесь, инфраструктура общая. Новый проект — это не “написать парсер с нуля”, а “описать что и откуда брать”. Время на старт минимальное, надёжность высокая.

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