Разработчики, использующие Playwright для веб-скрейпинга, сталкиваются с тем, что их самый первый запрос отклоняется, даже если скрипт запускает полноценный экземпляр Chromium, устанавливает настоящий User-Agent и вставляет задержки, имитирующие поведение человека. Сервер блокирует запрос во время TLS-рукопожатия (handshake) — этот метод называется TLS-фингерпринтингом (TLS fingerprinting).

Что такое TLS-фингерпринтинг

Когда браузер открывает HTTPS-соединение, он отправляет сообщение ClientHello. В этом пакете перечислены версия TLS, поддерживаемые наборы шифров (cipher suites), набор расширений (эллиптические кривые, алгоритмы подписи) и несколько других полей. Именно эта уникальная комбинация позволяет идентифицировать сетевой стек.

Исследователи хешируют эти необработанные поля в компактный идентификатор, называемый JA3 (или его более современный аналог JA4). Настоящий браузер Chrome создает один хеш, а библиотека HTTP на Python — другой. Если хеш, полученный сервером, не соответствует заявленному User-Agent, запрос помечается как автоматизированный.

Почему стандартный браузер Playwright всё равно может быть помечен

Стандартная сборка Chromium в Playwright обычно выдает правильный фингерпринт Chrome, но многие скрейперы добавляют шаги, которые нарушают согласованность:

  1. Смешанные стратегии запросов — разработчики часто позволяют Playwright отрисовывать тяжелые страницы, в то время как легковесный HTTP-клиент загружает вспомогательные ресурсы (JSON, изображения и т. д.). Эти быстрые вызовы несут фингерпринт библиотеки, а не Chrome, и сервер мгновенно замечает несоответствие.
  2. Прокси с терминацией TLS — некоторые прокси-сервисы расшифровывают TLS-поток, проверяют или изменяют трафик, а затем повторно шифруют его. В итоге сервер видит фингерпринт прокси-сервера и может заблокировать его как небраузерный клиент.
  3. Другие уровни протокола — системы защиты от скрейпинга также сравнивают настройки HTTP/2, порядок заголовков и репутацию IP-адреса. Несоответствие на любом из этих уровней может привести к блокировке.

От JA3 к JA4: гонка вооружений

JA3 был первым широко распространенным методом TLS-фингерпринтинга. Теперь Chrome при каждом запуске рандомизирует порядок расширений, что делает хеш JA3 нестабильным для реального браузера. JA4 решает эту проблему, сортируя список расширений перед хешированием, что позволяет получить стабильный идентификатор, даже если Chrome меняет порядок. Инструменты обнаружения, использующие JA4, могут надежно отличать реальные экземпляры Chrome от скриптовых клиентов, которые просто копируют статический хеш JA3.

Что разработчики могут сделать уже сегодня

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

  • Приведите User-Agent, TLS-рукопожатие, настройки HTTP/2 и порядок заголовков в соответствие с одной и той же версией браузера и ОС.
  • Перестаньте смешивать инструмент автоматизации полноценного браузера с отдельным HTTP-клиентом. Если важна скорость, позвольте Playwright обрабатывать все сетевые вызовы, даже самые тривиальные.
  • Выбирайте прокси, которые пропускают TLS насквозь (pass-through) без терминации соединения, или настраивайте их так, чтобы они пересылали исходное TLS-рукопожатие без изменений.
  • Следите за сервисами репутации IP-адресов; использование «чистого» пула IP снижает вероятность блокировки на основе истории злоупотреблений.

Цена игнорирования согласованности фингерпринтов

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

Контраргумент: почему сайты используют TLS-фингерпринтинг

Владельцы сайтов рассматривают TLS-фингерпринтинг как законный метод защиты. Автоматизированный скрейпинг может перегружать серверы, обходить платные подписки (paywalls) или массово собирать персональные данные. Проверяя соответствие TLS-фингерпринта заявленному браузеру, сайт отсеивает огромный класс примитивных ботов, не мешая реальным пользователям. Этот метод менее навязчив, чем CAPTCHA, и сохраняет удобство использования сайта.

За чем следить дальше

  • Внедрение JA4 — ожидайте, что в ближайшие месяцы всё больше поставщиков решений по безопасности и CDN-провайдеров внедрят методы обнаружения на базе JA4.
  • Рандомизация на уровне браузера — Chrome и другие браузеры могут продолжать варьировать параметры TLS, что заставит инструменты фингерпринтинга искать более сложные сигналы, такие как тайминг трафика или паттерны выполнения JavaScript.
  • Реакция рынка прокси — вероятно, появятся сервисы, обещающие «TLS-прозрачную» маршрутизацию, чтобы удовлетворить потребность сообщества скрейперов в неизменных рукопожатиях.

Итог

Если ваш Playwright-скрейпер отклоняется еще до загрузки страницы, причиной, почти наверняка, является несоответствие TLS-отпечатка. Решение — это не быстрый патч; оно требует строгого приведения каждого уровня протокола в соответствие с заявленным профилем браузера. Согласованность User-Agent, TLS-рукопожатия, настроек HTTP/2, порядка заголовков и поведения прокси — единственный надежный способ оставаться незамеченным для современных систем защиты от скрейпинга.