Подскажите, кто сейчас с какими прокси работает под парсинг.
Раньше хватало обычных серверных, сейчас всё чаще ловлю ограничения, капчи и обрезание запросов. Пробовал резидентные, местами лучше, но часто попадаются уже заюзанные IP, и результат нестабильный. Пока не до конца понимаю, проблема в самих прокси или уже в настройке и нагрузке.
Кто что сейчас использует, чтобы нормально держался парсинг?
Сначала стоит разделить две вещи, которые в таких обсуждениях постоянно смешивают: блокируют вас по IP или по клиенту. Пока это не измерено, выбор прокси — гадание, и можно потратить бюджет на дорогие резиденты без эффекта.
Быстрая диагностика (полчаса работы)
- Сделайте те же запросы со своего домашнего IP из обычного браузера. Если браузер ходит нормально, а скрипт с того же IP ловит капчу — проблема не в прокси, а в отпечатке клиента.
- Логируйте не только статус, но и тело ответа и заголовки. По ним видно, кто именно режет: Cloudflare (cf-ray, страница челленджа), DataDome (заголовок x-datadome / captcha-delivery.com), Akamai (_abck в куках), PerimeterX, либо самописный рейт-лимит (429 + Retry-After).
- Посмотрите, на каком по счёту запросе с одного IP начинается блок и уходит ли он со временем. Если блок наступает стабильно на N-м запросе — это рейт-лимит, лечится частотой и размером пула, а не типом прокси. Если первый же запрос с нового IP уходит в капчу — режут по репутации подсети или по отпечатку.
Про отпечаток
Если вы ходите голым python-requests/httpx или curl, вас определяют по TLS-отпечатку (JA3/JA4) и по HTTP/2-фрейминга ещё до того, как посмотрят на IP. Никакие резидентные прокси это не спасут. Варианты: curl_cffi или tls-client (имитируют отпечаток Chrome), либо реальный браузер через Playwright с антидетект-патчами. Плюс порядок и полнота заголовков — реальный Chrome шлёт sec-ch-ua, sec-fetch-*, Accept-Language в определённом порядке; библиотеки — нет.
Про сами прокси
- Датацентр — дёшево, годится для целей без антибота (свои сайты, API, выдача мелких сервисов). На крупных площадках сейчас режется целыми ASN, независимо от «свежести».
- ISP / статичные резидентные — по факту датацентровая стабильность и скорость, но ASN провайдера домашнего интернета. Для большинства задач это лучший баланс цена/качество, и главное — статичный IP позволяет держать сессию с куками.
- Ротируемые резидентные — нужны там, где нужен объём уникальных IP и гео. Оплата за трафик, поэтому обязательно блокируйте картинки, шрифты, медиа и по возможности работайте с внутренним JSON API цели, а не с рендером страниц.
- Мобильные — самые живучие (за одним IP сидят тысячи реальных людей, банить дорого), но дорогие и медленные. Имеет смысл только под небольшой объём по тяжёлым целям.
«Заюзанные IP» в резидентных пулах — это норма любого провайдера, пулы у многих перепродаются и частично пересекаются. Поэтому оценивать поставщика нужно не по обещаниям, а по success rate на вашей конкретной цели: 500–1000 запросов через каждый тестируемый пул одним и тем же кодом, считаете долю 200-х ответов без челленджа и стоимость одного успешного ответа. Разница между провайдерами по одной и той же цели бывает кратная, и предугадать её заранее нельзя.
Настройка, которая обычно даёт больше, чем смена провайдера
- Sticky-сессии, а не ротация на каждый запрос. Пользователь, который делает 20 запросов с 20 разных IP с одной кукой, — это готовый сигнал бота. Держите IP 3–10 минут и завершайте на нём логическую сессию.
- Один IP = одна «личность»: своя кука, свой User-Agent, свой отпечаток. Не переиспользуйте куки между IP.
- Согласованность гео: IP из Германии + Accept-Language: ru-RU + московский таймзон в браузере — палево.
- Частота: считайте не общий RPS, а RPS на IP. Обычно 0.2–1 запрос в секунду на IP с джиттером живёт долго, а 5 rps убивает даже мобильный.
- Backoff: при 429/403 убирайте IP из ротации на 10–30 минут, а не долбите дальше — так вы сжигаете пул.
И два соображения не про технику. Первое: часто дешевле снизить объём запросов, чем усиливать прокси — sitemap.xml, фиды, официальные API, инкрементальный обход только изменившегося, кэш. Второе: если цель защищена серьёзным коммерческим антиботом, гонка вооружений с ним постоянная, и готовые scraping API (где вам продают уже отрендеренный ответ) по TCO часто выигрывают у самостоятельной инфраструктуры. Ну и стоит посмотреть ToS цели и что вы собираете — у персональных данных и контента под копирайтом отдельные риски, не технические.
Если напишете, что за цель (или хотя бы какой антибот в ответах) и какой объём в сутки нужен, можно будет говорить конкретнее.
Ответ нейросети claude-opus-5. Проверяйте, прежде чем применять. И обязательно отпишитесь здесь, когда проверите.
Но когда защиту совсем убрали, то боты обошли весь форум и ушли, а теперь почти не заходят.