Как использовать ротирующие проксиРотация по запросу и sticky-сессии в коде

Ротирующий прокси, это один хост и порт, который со временем выдаёт разные выходные IP, поэтому скрапер, отправляющий тысячу запросов, не отправляет их все с одного адреса, который целевой ресурс может ограничить и заблокировать. Вы указываете свой HTTP-клиент на ротирующий эндпоинт вместо сайта, а ротация происходит за ним. Вот и весь механизм. Всё остальное (по запросу или sticky, резидентский или дата-центровый, строить или купить), это выбор, надстроенный поверх него.

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

Единственное решение, которое важно: ротация на запрос или sticky-сессия

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

Логика проста. Когда каждый запрос независим (вы загружаете одну страницу товара за другой и ничто не переходит между запросами), свежий IP при каждом запросе распределяет нагрузку, чтобы ни один адрес не достигал лимита. Но как только запросы зависят друг от друга, авторизация, устанавливающая куки, корзина, в которую добавляют товар и потом оформляют заказ, ротация в середине потока вас ломает. Сайт видит, как ваша сессия перепрыгивает из одной страны в другую между двумя кликами, и отсеивает вас. Здесь нужна sticky-сессия: один выходной IP на всю последовательность, затем новый для следующего пользователя.

Ротация на каждый запрос в Python

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

# Per-request rotation: one endpoint, a new exit IP each call.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"
proxies = {"http": endpoint, "https": endpoint}

# Hit an echo service 3 times; each line should show a different IP.
for _ in range(3):
    resp = requests.get("https://httpbin.org/ip", proxies=proxies, verify=False)
    print(resp.json()["origin"])

Замените httpbin.org/ip на ваш реальный целевой ресурс, и та же конфигурация прокси пропускает каждый запрос через ротирующий выход. Флаг verify=False пропускает проверку TLS, поскольку трафик ретранслируется через туннель прокси; в продакшене вы бы указали requests на CA-bundle провайдера вместо отключения проверки. С этого момента парсинг, обычный BeautifulSoup или что угодно, что вы уже используете; прокси для него невидим.

Sticky-сессии в Python

Для сценария, который должен выглядеть как один пользователь, вы удерживаете выходной IP на протяжении принадлежащих ему запросов. С управляемым эндпоинтом обычный механизм, использовать единый requests.Session (чтобы куки сохранялись) и передавать идентификатор сессии, который шлюз использует для привязки одного IP на заданное окно. Сессия переносит авторизационный куки от запроса к запросу; привязанный IP не даёт сайту видеть, как ваш "пользователь" телепортируется в середине сценария.

# Sticky session: one IP + one cookie jar across a multi-step flow.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"

session = requests.Session()  # persists cookies across requests
session.proxies = {"http": endpoint, "https": endpoint}

# Step 1: log in (sets a cookie). Step 2: read a gated page.
# Same IP + same cookie jar make both look like one visitor.
session.post("https://example.com/login", data={"user": "u", "pass": "p"}, verify=False)
resp = session.get("https://example.com/account/orders", verify=False)
print(resp.status_code)

Конкретный способ запросить sticky-окно (заголовок, токен сессии в имени пользователя или отдельный порт) зависит от провайдера, поэтому сверяйтесь с его документацией по имени параметра. Шаблон универсален: удерживайте IP для запросов, разделяющих состояние, и освобождайте его, когда пользователь завершил сессию.

Собственная реализация ротации

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

# Manual rotation: cycle a list of proxies yourself.
import requests, itertools

pool = [
    "http://user:pass@ip1:port",
    "http://user:pass@ip2:port",
    "http://user:pass@ip3:port",
]
rotation = itertools.cycle(pool)  # round-robin instead of random

def fetch(url):
    proxy = next(rotation)
    return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)

Round-robin через itertools.cycle предсказуемее случайного выбора, потому что распределяет нагрузку равномерно. Но обратите внимание, чего этот код не делает: он не обрабатывает мёртвый IP в пуле, прокси, возвращающий страницу блокировки с кодом 200, повторные попытки с неудавшимся запросом через другой выход или удаление помеченных IP. В реальном запуске именно эти случаи составляют большую часть работы, и именно их управляемый ротирующий эндпоинт берёт на себя. Полный шаблон цикличной смены адресов разобран в статье как ротировать IP-адрес.

Когда управляемый эндпоинт лучше собственного решения

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

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

Есть ещё одна ступень выше этого. Когда целевой ресурс также требует рендеринга браузера, отправляет CAPTCHA-вызовы или требует правдоподобного отпечатка, ротация IP, лишь часть борьбы, и стоит прочитать сравнение backconnect-прокси против crawling API. Ротирующий эндпоинт выдаёт вам чистый IP и отступает; crawling API владеет ротацией, рендерингом и повторными попытками от начала до конца и возвращает готовую страницу.

Типичные сбои и как их читать

Ротирующие прокси выходят из строя небольшим числом узнаваемых способов. Знание того, на что вы смотрите, сберегает часы догадок.

Вас всё равно блокируют. Обычно одна из двух причин: вы ротируете по запросу в сценарии, требующем sticky-сессию (так что сайт видит прыжок IP в середине сессии), или неправильный тип IP для целевого ресурса. Защищённый сайт отбрасывает дата-центровые IP независимо от скорости ротации; ему нужны IP реальных пользователей. Подбирайте тип IP под защиту, а не скорость ротации, компромисс описан в статье дата-центровые против резидентских прокси.

200-й код, который на самом деле блокировка. Многие сайты возвращают CAPTCHA или страницу "вы человек?" с кодом 200, поэтому проверки status_code == 200 недостаточно. Изучайте тело ответа на известные маркеры блокировки (строка вызова, неожиданный редирект, подозрительно короткий ответ) перед тем, как доверять результату. Воспринимайте их как сбои и повторяйте попытку с новым IP.

Ошибки аутентификации. 407 (или зависание соединения) почти всегда означает, что учётные данные в URL прокси неверны или неправильно сформированы. Перепроверьте токен и форму user:pass@host:port. Если вы разбираетесь с кодами статуса прокси в целом, статья как разобраться с кодами ошибок статуса прокси сопоставляет распространённые коды с причинами.

Медленно или тайм-аут. Резидентские и мобильные выходы работают через потребительские соединения и по замыслу медленнее дата-центровых. Задайте разумный timeout (в примере 15с) и предусмотрите повторную попытку, а не давайте одному медленному выходу стопорить весь запуск. Если управляемый эндпоинт стабильно даёт тайм-ауты, это сигнал от провайдера, а не баг в коде.

Практики, которые действительно дают результат

Большинство списков "лучших практик", это балласт. Следующие реально меняют процент блокировок. Задавайте темп запросов вместо взрывных потоков (ротация распределяет IP, но тысяча запросов в секунду из любого пула всё равно выглядит автоматически). Ротируйте User-Agent вместе с IP, поскольку фиксированный UA через тысячи "разных" IP, очевидная улика. Подбирайте тип IP под целевой ресурс, а не рефлекторно покупайте самый дорогой. И для продакшена используйте провайдера с чёткой политикой логирования вместо скрапленных списков бесплатных прокси, которые медленные, недолговечные и представляют реальный риск безопасности, об этом рассказывается в статье безопасны ли прокси. Если ваша конечная цель шире одной лишь ротации, как скрапить сайты без блокировок помещает всё это в контекст.

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

Как использовать ротационный прокси в Python?

Укажите ваш HTTP-клиент на ротирующий эндпоинт вместо целевого ресурса. Через requests создайте словарь proxies ({"http": url, "https": url}), где URL, это хост, порт и учётные данные вашего провайдера, и передавайте его в каждый requests.get или requests.post. Выходной IP меняется на сервере, поэтому код парсинга не меняется вообще. Протестируйте, запросив эхо-сервис вроде httpbin.org/ip несколько раз и убедившись, что IP разные.

В чём разница между ротацией на запрос и sticky-сессией?

Ротация по запросу даёт свежий выходной IP при каждом запросе, что распределяет нагрузку и подходит для безгосударственных высокообъёмных чтений. Sticky-сессия удерживает один IP на протяжении последовательности запросов, что необходимо для авторизации, корзин и любых многошаговых сценариев, которые должны выглядеть как один пользователь. Используйте ротацию по запросу для независимых чтений и sticky всякий раз, когда запросы зависят друг от друга.

Почему меня всё ещё блокируют с ротируемым прокси?

Две обычные причины: ротация по запросу в сценарии, требующем sticky-сессию (так что сайт видит прыжок IP в середине сессии), и использование неправильного типа IP. Защищённый ресурс отбрасывает дата-центровые IP независимо от скорости ротации. Подбирайте тип IP под защиту, удерживайте sticky-сессию для сценариев с состоянием и проверяйте, не является ли ответ с кодом 200 на самом деле CAPTCHA-страницей.

Ротировать прокси самостоятельно или использовать управляемую точку доступа?

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

Работают ли ротационные прокси для скрапинга за авторизацией?

Да, но необходимо использовать sticky-сессию, а не ротацию по запросу. Сохраняйте один выходной IP и один cookie jar на протяжении авторизации и закрытых страниц после неё, чтобы сайт видел одного последовательного посетителя. Если вам нужен IP, остающийся фиксированным между несколькими отдельными запусками, это статический резидентский (ISP) прокси, а не ротирующий.

Как быстро можно отправлять запросы через ротационный прокси?

Быстрее, чем с одного IP, потому что ротация распределяет запросы по многим адресам, но ротация, не лицензия на взрывные потоки. Тысяча запросов в секунду из любого пула всё равно читается как автоматика. Задавайте темп запросов, устанавливайте тайм-аут и повторные попытки, ротируйте User-Agent вместе с IP. Резидентские и мобильные выходы медленнее дата-центровых по замыслу, поэтому учитывайте это в тайм-аутах.

HR

Hassan Rehan

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

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