Как обойти защиту Cloudflare от ботовПочему он вас помечает и как пройти проверку

Направьте обычный скрипт на requests к сайту, защищённому Cloudflare, и вы, как правило, получите 403 или страницу с проверкой ещё до того, как загрузится реальный контент. Это не ошибка в вашем коде. Система управления ботами Cloudflare стоит перед миллионами сайтов и делает именно то, для чего создана: отделяет браузеры от скриптов и отбрасывает скрипты. TLS-рукопожатие, которое открывает ваш HTTP-клиент, заголовки, которые он отправляет, и IP, с которого он выходит,, всё это читается как автоматизация, и вас помечают уже в первом раунде обмена.

Этот материал о надёжном доступе к публичным страницам в масштабе без срабатывания этих защит. Не о преодолении защиты ради доступа к данным, на которые у вас нет права. Защита Cloudflare от ботов, это законная оборона от DDoS, злоупотреблений с учётными данными и агрессивного скрапинга, и большая часть блокируемого ею трафика заслуживает блокировки. Цель здесь уже и честнее: заставить законный краулер публичного контента выглядеть как обычный браузерный трафик, которым он и является, чтобы перестать попадать в сеть, предназначенную для злоупотреблений. Понимая это, рассмотрим, как Cloudflare решает, что вы бот, почему наивные скраперы мгновенно проваливаются и что на самом деле проходит, слой за слоем.

Как Cloudflare решает, что вы бот

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

Пассивное обнаружение: что ваш запрос уже выдаёт

Пассивные проверки происходят до загрузки страницы, на запросе по мере его поступления.

• Репутация IP и ограничение частоты. Cloudflare оценивает IP, с которого исходит ваш трафик. Адреса из известных хостинговых и облачных ASN (диапазоны дата-центров) по умолчанию имеют низкий уровень доверия, а любой единственный IP, делающий быстрые повторные запросы, быстро попадает под ограничение частоты. Чистый скрипт с облачного сервера борется в гору ещё до отправки первого заголовка.
• Отпечатки TLS и JA3. Первое, что делает ваш клиент,, это открывает TLS-рукопожатие, и форма этого рукопожатия (список шифров, расширения и их порядок в Client Hello) образует отпечаток, часто резюмируемый как хеш JA3. Настоящие Chrome и Firefox создают хорошо известные отпечатки. HTTP-клиент Python или Go создаёт другой, который не испускает ни один браузер, и Cloudflare может пометить его ещё до завершения соединения.
• Последовательность заголовков и user-agent. Браузеры отправляют специфический упорядоченный набор заголовков и user-agent, соответствующий остальным. Скрипты, как правило, отправляют короткий набор заголовков, упускают те, которые браузер всегда включает, или заявляют о себе как о Chrome, неся профиль заголовков, который Chrome никогда не отправлял. Cloudflare проверяет это несоответствие напрямую.

Активное обнаружение: что от клиента требуют доказать

Если пассивные сигналы неоднозначны, Cloudflare эскалирует ситуацию и заставляет клиента поработать.

• JavaScript-проверки. Cloudflare возвращает промежуточную страницу с обфусцированным JavaScript, который клиент должен выполнить, чтобы получить токен доступа. Настоящий браузер запускает его и продолжает работу автоматически. HTTP-клиент, не выполняющий JavaScript, просто получает страницу с проверкой и останавливается.
• Turnstile и CAPTCHA. При большем подозрении Cloudflare представляет Turnstile (свою замену CAPTCHA) или полную проверку. Они специально созданы так, чтобы автоматизация не могла пройти их самостоятельно.
• Поведенческий анализ. Помимо первой страницы, Cloudflare следит за паттерном запросов: тайминг, порядок навигации и, в интерактивных проверках, такие сигналы, как движение указателя. Трафик, поступающий в идеально равномерном, машинно-точном ритме без вариаций, совершенно не похож на живого человека и подвергается эскалации.

Почему наивные скраперы мгновенно проваливаются

Простой вызов requests.get() или httpx проваливается по причинам, не связанным с вашей логикой парсинга. Он открывает TLS-рукопожатие с небраузерной подписью, отправляет тонкий набор заголовков и не может выполнить JavaScript. Поэтому он попадается на пассивном уровне из-за отпечатка и заголовков, а если каким-то образом проходит его, останавливается на активном, потому что нет движка для выполнения проверки. Нужная страница никогда не рендерится. Вы видите 403 или промежуточную страницу проверки, а не контент.

Добавление единственного прокси дата-центра не исправляет ситуацию. Это меняет выходной IP на другой адрес с низким доверием, и ничего не делает с отпечатком TLS, заголовками или отсутствующим движком JavaScript. Вы изменили один из четырёх сигналов, и не тот, который, скорее всего, неправилен. Вот почему «я добавил прокси и всё равно получаю блокировку», настолько распространённое сообщение. Прокси был нужен для одного уровня и не имел отношения к другим. Более широкая версия этой проблемы применительно к многим антибот-системам рассмотрена в материале о как скрапить сайты без блокировок.

Что на самом деле проходит, в порядке приоритета

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

1. Ротирующие жилые IP при низкой частоте на IP. Это проходит репутацию IP и ограничение частоты. Жилые прокси выходят через реальные соединения потребительских ISP, поэтому Cloudflare воспринимает их как обычных посетителей, а не хостинговый трафик. Ротация по пулу поддерживает низкую частоту запросов на любом одном адресе, поэтому ограничение частоты не срабатывает даже при высоком общем объёме. Смотрите материал о сравнении прокси дата-центров и жилых прокси о том, почему происхождение IP так важно, и о ротирующих жилых прокси для понимания паттерна ротации.
2. Настоящий движок браузера, выполняющий проверку. Это проходит уровень JavaScript-проверки. Puppeteer, Playwright или безголовый Chrome действительно запускают обфусцированный скрипт проверки и получают токен доступа, что невозможно для простого HTTP-клиента. Плагин stealth снижает специфичные для безголового режима признаки (флаги автоматизации и особенности среды, выдающие управляемый браузер), чтобы движок воспринимался как обычный.
3. Согласованные заголовки и совпадающий отпечаток TLS. Это проходит проверки отпечатков и согласованности заголовков. TLS-рукопожатие и заголовки должны соответствовать браузеру, за который вы себя выдаёте: если user-agent говорит Chrome, отпечаток JA3 и набор заголовков тоже должны быть Chrome. Настоящие движки браузеров получают это бесплатно, что и является частью причины, почему они проходят там, где ручной словарь заголовков, нет. Для более глубокого понимания механики смотрите материал об отпечатках браузера.
4. Поведение в темпе человека. Это проходит поведенческий анализ. Варьируйте тайминг запросов, избегайте жёсткого цикла и навигируйте в правдоподобном порядке. Цель, не симулировать человека, кликающего мышью; цель, избегать идеально равномерного, роботизированного ритма, который сам по себе сигнализирует об автоматизации. Воспринимайте изменение статус-кодов как сигнал: запуск, начинающий возвращать 403 или страницы проверки, говорит вам о том, что какой-то уровень больше не удовлетворён. В материале о кодах ошибок статуса прокси объясняется, как их читать.

Одна техника стоит отдельного упоминания, чтобы вы могли её пропустить: обращение к IP-адресу источника напрямую в обход Cloudflare. В более старых руководствах она называется «обнаружение IP источника», и это ненадёжный и не рекомендуемый подход. Большинство источников настроены на отклонение трафика, прошедшего не через Cloudflare, обнаруженный IP устаревает, и весь подход воспринимается как враждебный, а не как законный доступ к публичной странице. Оставайтесь на пути, загружающем страницу так, как это делал бы посетитель.

Сигнал Cloudflare и что его проходит

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

Делать это самостоятельно и во что это обходится

Вы можете собрать полный стек самостоятельно. Поднимите пул ротирующих жилых IP, запустите парк безголовых экземпляров Chrome с плагином stealth для прохождения проверок, поддерживайте согласованность профилей TLS и заголовков с используемой версией браузера и регулируйте трафик. Это работает. Это также постоянная нагрузка на обслуживание: плагины stealth отстают от выпусков браузеров, скрипты проверок меняются, отпечатки переклассифицируются, а парк безголовых браузеров должен масштабироваться вместе с вашим объёмом. Для разовой выгрузки это может быть нормально. Для пайплайна, который должен продолжать работать, вы теперь обслуживаете антибот-инфраструктуру вместо того, чтобы создавать то, что использует данные.

Альтернатива, свернуть все четыре уровня за одной конечной точкой, чтобы ваш код оставался простым HTTP-запросом. Именно это делает Crawlbase Smart AI Proxy.

Рабочий пример со Smart AI Proxy

Smart AI Proxy, это шлюз с обратным подключением: один хост и порт, к которому вы направляете обычный HTTP-клиент, с ротацией, рендерингом, согласованностью отпечатков и обработкой проверок на стороне сервера. Вы передаёте токен доступа в качестве имени пользователя прокси. С точки зрения вашего кода это просто прокси, поэтому приведённый ниже запрос выглядит как любой другой requests.get().

Сначала установите единственную зависимость.

pip install requests

Затем направьте запрос к публичной странице с защитой Cloudflare через шлюз. Токен указывается в URL прокси, и этот же прокси используется как для HTTP, так и для HTTPS-трафика.

import requests

# Backconnect gateway: token as the username, rotation and rendering server-side.
proxy_url = "http://[email protected]:8012"
proxies = {"http": proxy_url, "https": proxy_url}

url = "https://example.com/protected-page"
resp = requests.get(url, proxies=proxies, verify=False)

print(resp.status_code)
print(resp.text[:500])

Замените YOUR_CRAWLBASE_TOKEN на свой токен из панели управления. Шлюз загружает страницу так, как это делал бы настоящий браузер: жилой IP, рукопожатие браузерного вида, выполнение проверки при её появлении, и передаёт вашему скрипту готовый HTML. Ваш код никогда не взаимодействует с пулом прокси или безголовым браузером; он делает один обычный GET и читает результат. Флаг verify=False отключает локальную проверку сертификата для подключения к прокси, что ожидаемо при таком типе шлюза.

Если вам нужно то же покрытие без интерфейса в стиле прокси, паттерн ротирующих прокси и Crawling API предоставляют тот же движок через URL запроса, что предпочитают некоторые пайплайны.

Честная часть: ToS и законность

Разрешено ли вам скрапить определённый сайт, зависит от его условий использования и юрисдикции, в которой работаете вы и сайт, и это реальное ограничение, а не сноска. Наличие Cloudflare перед сайтом само по себе не решает вопрос, но собственные правила сайта решают. Несколько принципов, которых стоит придерживаться: собирайте только публичные данные, соблюдайте robots.txt сайта и заявленные ожидания по частоте, и никогда не преследуйте контент за аутентификацией или персональные данные, для сбора которых у вас нет оснований. Публичные страницы для анализа, одно; сбор данных за логином или персональной информации, другое, и именно здесь живут правовые и этические риски. Если проекту нужно больше, чем публичные данные, правильный ответ, официальный API или соглашение с сайтом, а не более агрессивный скрапер. Если вы сталкиваетесь с интерактивными проверками в рамках законного доступа, материал о как обойти CAPTCHA при веб-скрапинге охватывает эту тему в той же ответственной рамке.

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

Почему мой скрапер получает 403 от Cloudflare даже с прокси?

Прокси меняет только IP, что является одним из четырёх сигналов, которые проверяет Cloudflare. Если вы использовали прокси дата-центра, IP всё ещё низкодоверенный; в любом случае ваш отпечаток TLS, заголовки и отсутствующий движок JavaScript остаются неизменными. Чтобы устранить ошибку 403, вам обычно нужен ротирующий жилой IP плюс настоящий движок браузера, выполняющий проверку, а не просто другой выходной адрес.

Что такое JA3 или отпечаток TLS и почему он помечает мой скрипт?

Ваше TLS-рукопожатие имеет узнаваемую форму: список шифров и расширения в определённом порядке, которые можно хешировать в отпечаток, часто называемый JA3. Настоящие браузеры создают хорошо известные отпечатки, тогда как HTTP-клиенты Python и Go создают отпечатки, которые не испускает ни один браузер. Cloudflare может пометить это несоответствие во время рукопожатия, до того как ваш запрос достигнет страницы, поэтому скрипт может провалиться даже с идеальными заголовками.

Нужен ли мне безголовый браузер для обхода Cloudflare?

Вам нужно что-то, что выполняет JavaScript-проверку, что простой HTTP-клиент не может сделать. Это может быть ваш собственный безголовый Chrome, Puppeteer или Playwright (желательно с плагином stealth), или шлюз, который выполняет рендеринг на стороне сервера. Управляемая конечная точка, обрабатывающая рендеринг и IP в одном запросе, позволяет избежать самостоятельного запуска и масштабирования парка браузеров.

Пройдут ли только ротирующие жилые прокси Cloudflare?

Они проходят репутацию IP и ограничение частоты, но не уровень JavaScript-проверки или отпечатков. Если сайт выполняет только пассивные проверки IP, жилой ротации может быть достаточно; если он выдаёт активную проверку, вам всё равно нужен движок браузера для её выполнения. Воспринимайте IP как необходимое, но не всегда достаточное условие, и соответствуйте остальному стеку уровню проверки, с которой вы фактически сталкиваетесь.

Законно ли обходить Cloudflare для веб-скрапинга?

Это зависит от условий использования сайта и вашей юрисдикции, а не от наличия Cloudflare. Доступ к публичным данным при соблюдении robots.txt и разумных ограничений частоты обычно более защищаем, чем сбор данных за аутентификацией или персональных данных, который несёт реальные правовые и этические риски. В сомнительных случаях оставайтесь на публичном контенте и используйте официальный API или соглашение для всего остального.

Стоит ли мне найти IP источника, чтобы полностью обойти Cloudflare?

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

HR

Hassan Rehan

Инженер-программист · Crawlbase

Инженер-программист в Crawlbase, пишет практические руководства по ротирующимся прокси, скрейпингу и тонкостям подключения прокси к реальному коду.