Вернуться в блог

Веб-скрапинг ограничен? Решаем проблемы фингерпринтинга, IP-блокировок, CAPTCHA и входа в несколько аккаунтов

Отталкиваясь от 403/429, фингерпринтинга, CAPTCHA, динамических страниц и сеансов входа, статья объясняет реальные причины ограничений веб-скрапинга и предлагает подход, в котором на первом месте авторизованные API, ограничение скорости, экспоненциальный откат, инкрементальный кэш и соответствующий требованиям аккаунт-среда.

Когда скрапер сталкивается с 403, 429, CAPTCHA или повторяющимися ошибками входа, правильный путь — не ротация IP, не маскировка отпечатков и не попытки «притвориться живым человеком». Эти сигналы обычно означают, что частота запросов, область доступа, способ аутентификации или поведение автоматизации вышло за границу, которую сайт готов терпеть. Если продолжать «обходить» ограничение, оно почти всегда усилится, а попутно можно нарушить условия использования, договоры, авторские права или правила защиты данных.

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

Начните с симптома и сужайте причину

СимптомТипичная причинаКорректная реакция
429 Too Many RequestsСлишком быстрые, слишком параллельные или повторяющиеся запросыСнизить скорость, соблюдать Retry-After, использовать экспоненциальный откат
403 ForbiddenНеавторизованный путь, блокировка политикой, отсутствующая сессияПроверить права, условия, robots.txt и способ аутентификации
Появляется CAPTCHAСайт требует подтверждения человека или блокирует автоматизациюПоставить задачу на паузу, пройти вручную или запросить API
Вход постоянно сбоитИстёкшие cookies, перезапись сессий, ошибка аутентификацииИспользовать официальный OAuth или сервисные аккаунты, аккуратно передавать сессии
На странице есть контент, но скрипт его не получаетРендеринг JavaScript, асинхронная загрузка APIИспользовать официальный API; с разрешения — отрендерить в браузере и читать DOM
Селекторы внезапно перестают работатьИзменение DOM, A/B-тест, смена языкаИспользовать семантические локаторы, структурные тесты и оповещения, не полагаться на хардкод иерархий
Дубликаты или пропуски данныхПагинация, курсоры, часовые пояса, окно обновленияВвести уникальные ключи, инкрементальную отметку и механизм перезапуска

Меняйте по одной переменной за раз и сохраняйте логи. Если одновременно поменять IP, User-Agent, аккаунт и парсер, успех может быть случайным, а понять, что именно помогло, не получится.

Шаг 1: убедитесь, что у вас есть право собирать эти данные

До старта ответьте на четыре вопроса:

  1. Данные публичны или доступны только после входа, оплаты или определённой роли?
  2. Есть ли у сайта API, экспорт, лента, webhook или партнёрский интерфейс данных?
  3. Разрешают ли условия использования, robots.txt, договоры и местное право выбранную цель?
  4. Содержат ли данные персональную информацию, защищённый авторским правом контент или иные чувствительные поля?

robots.txt — стандартный способ, которым сайт сообщает автоматическим клиентам, какие пути разрешены и запрещены. RFC 9309 описывает синтаксис и правила сопоставления Robots Exclusion Protocol и явно указывает, что robots.txt не является разрешением на доступ. Иными словами, разрешение в robots.txt не даёт полного права копировать, обрабатывать или коммерчески использовать данные; к запрещённым путям нельзя подбираться через другой вход.

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

Шаг 2: выбирайте стабильные точки входа

Обычный порядок приоритета:

  1. Официальные API, webhook-и или экспорт данных;
  2. Публичные ленты, sitemap-ы или массовые файлы;
  3. Обычные HTTP-страницы, на которые получено разрешение;
  4. Автоматизация браузера — только если действительно нужен рендеринг JavaScript;
  5. Страницы, требующие ручного аккаунта и взаимодействия — в последнюю очередь.

API обычно дают определения полей, пагинацию, лимиты скорости и коды ошибок, что дешевле в сопровождении, чем разбор UI. Веб-страница — поверхность для человеческих глаз; она может измениться в любой момент, и её нельзя считать стабильной базой данных.

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

Шаг 3: с 429 и блокировками IP работаем через снижение нагрузки, а не сокрытие источника

Установите потолки скорости и параллельности

Начните с одного воркера и достаточно длинного интервала, наблюдайте за временем ответа и долей ошибок. Когда сервер возвращает Retry-After, ждите именно столько. Если заголовка нет, используйте экспоненциальный откат со случайным джиттером, чтобы несколько задач не ретраили одновременно.

Простая политика:

ожидание = min(потолок, база × 2^попытки) + джиттер

Когда число попыток достигает максимума, остановитесь и поднимите тревогу. Не зацикливайтесь бесконечно.

Кэш и инкрементальные обновления

Кэшируйте один и тот же URL и, если поддерживается, отправляйте условные запросы с ETag или Last-Modified. Сохраняйте время последнего обновления или курсор, чтобы забирать только новое и изменённое. Разделение полного обхода и ежедневной инкрементальной задачи заметно снижает объём запросов.

Честно идентифицируйте клиента

Соответствующий правилам краулер использует стабильный, настоящий User-Agent, указывает своё назначение и предоставляет контактную страницу или e-mail. Маскировка под обычный браузер и частая смена идентичности мешают сайту отличать хороший трафик от плохого и повышают шанс блокировки.

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

Шаг 4: фингерпринтинг и поведенческий анализ

Отпечаток браузера сочетает сигналы User-Agent, ОС, языка, часового пояса, разрешения, Canvas и WebGL. Сайт также может анализировать ритм запросов, маршруты навигации и поведение в сессии. OWASP относит Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing и т.п. к отдельным категориям автоматизированных угроз — именно поэтому сайты часто комбинируют несколько сигналов.

Для авторизованных задач цель — не плодить «человеческие» идентичности, а держать среду стабильной и понятной:

  • один бизнес-аккаунт = одна фиксированная среда и обычная аутентификация;
  • параметры браузера соответствуют реальному региону и устройству;
  • не менять отпечаток случайным образом ради обхода блокировок;
  • писать в лог частоту сбора, ID задачи и ответственного;
  • согласовать с сайтом число аккаунтов, параллельность и объём данных.

Если сайт всё равно ошибочно классифицирует авторизованную задачу, передайте ему таймстампы, User-Agent, выходной IP и примеры запросов и попросите внести в белый список или выдать выделенный интерфейс.

Шаг 5: при появлении CAPTCHA автоматизацию останавливаем

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

Правильный порядок:

  1. немедленно поставить на паузу текущий аккаунт и очередь задач;
  2. сохранить частоту запросов, маршруты и лог ошибок прямо перед срабатыванием;
  3. уполномоченный человек выполняет нужную проверку на официальной странице;
  4. проверить, не было ли запросов слишком много, не истекла ли сессия и не использовался ли запрещённый путь;
  5. для долгосрочной автоматизации — запросить у сайта API, сервисный аккаунт или белый список.

Даже если человек один раз прошёл CAPTCHA, это не даёт права бесконечно слать автоматические запросы. Сначала устраните причину.

Шаг 6: вход и мульти-аккаунт — только с формальными правами

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

Когда сессия браузера действительно нужна:

  • один легитимный бизнес-аккаунт = одна стабильная среда;
  • cookies шифруются, имеют срок действия и возможность отзыва;
  • MFA включена, автоматизация не должна обходить второй фактор;
  • запрещено одновременное сбрасывание паролей и копирование cookies несколькими людьми;
  • фиксируйте, кто и когда запустил задачу;
  • при увольнении, завершении проекта или смене роли сразу отзывайте доступ.

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

Шаг 7: сделать парсинг динамических страниц устойчивее к редизайну

Используйте семантические и стабильные атрибуты

Опирайтесь на заголовки, шапки, атрибуты доступности и публичные тестовые идентификаторы сайта. Избегайте хрупких иерархий вроде div:nth-child(7). После обновления страницы перечитывайте DOM, не полагайтесь, что старый узел остался.

Отделяйте извлечение от бизнес-логики

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

Делайте образцы и оповещения

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

Где PurpleMark уместен в авторизованном скрапинге

Когда команде приходится одновременно поддерживать несколько авторизованных аккаунтов, разные клиентские среды или разные регионы, в PurpleMark web app можно создать отдельную браузерную среду для каждого бизнес-аккаунта и хранить в ней соответствующие cookies, страницу, открываемую после входа, и обычную сетевую конфигурацию. При повторном открытии среды браузер сразу возвращается к последней сессии и рабочей странице — несколько человек не делят один набор cookies и не приходится каждый раз логиниться заново.

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

PurpleMark помогает команде долгосрочно вести «аккаунты, среды, сессии и ответственность» в одном рабочем пространстве, но он не предназначен для обхода IP-блокировок, CAPTCHA, ограничений на число аккаунтов или защиты сайта от автоматизации. Сначала получите разрешение, потом говорите об автоматизации.

Поддерживаемая архитектура скрапинга

Удобно делить систему на пять слоёв:

  1. Планирование: частота, параллельность, приоритет задач и пауза;
  2. Доступ: API, HTTP или авторизованная сессия браузера;
  3. Парсинг: преобразование ответов в структурированные поля;
  4. Качество: дедупликация, проверка типов, оповещения о пропусках и журнал версий;
  5. Управление: права, источник, цель, срок хранения и удаление.

Каждая запись хранит URL источника, время сбора и версию парсера. При ошибке можно прицельно перезапустить затронутые записи, а не переобходить весь сайт.

Часто задаваемые вопросы

Решает ли ротация прокси проблему IP-блокировки?

Она может временно сменить выходной адрес, но не решает проблему частоты, прав и поведения. Ротация прокси ради продолжения доступа может считаться обходом. Сначала остановите задачу, снизьте частоту и свяжитесь с сайтом.

Можно ли автоматически распознавать CAPTCHA?

Нет. CAPTCHA — сигнал к паузе или привлечению человека. Для постоянной автоматизации запросите API, сервисный аккаунт или белый список.

Если robots.txt разрешает — можно всегда скрапить?

Не обязательно. robots.txt — не разрешение на доступ; нужно учитывать условия, авторские права, приватность, договоры и цель использования данных.

Делает ли антидетект-браузер скрапинг «невидимым»?

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

Заключение

Ограничения веб-скрапинга — это не только «техническая задача антибота». 403, 429, фингерпринтинг, CAPTCHA и лимиты на мульти-аккаунт — всё это про права, нагрузку и управление идентичностью.

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