Sticky или rotating прокси: как выбрать модель IP для сессий?

В этом руководстве описаны три модели сессий (ротация на каждый запрос, sticky-сессия с таймером, статический IP), объяснено, что ломается при смене IP посреди сессии и как лимиты на IP влияют на выбор. В конце приведены таблица сценариев, гибридные схемы и пример на Python, который отделяет sticky-идентичности от rotating-пула. В примерах используется шлюз gw.weproxy.com.tr:8989, а учётные данные заданы плейсхолдерами USER и PASSWORD.

Чем отличаются sticky, rotating и статический IP?

Все три модели по-разному отвечают на один вопрос: увидит ли целевой сайт два последовательных запроса с одного IP? Тип прокси (residential, мобильный, datacenter, ISP) определяет, откуда берётся IP. Модель сессии определяет, как долго этот IP остаётся за вами. О выборе типа читайте в сравнении residential, мобильных, datacenter и ISP-прокси; эта статья посвящена только модели сессии.

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

В режиме rotating шлюз выбирает из пула другой выходной IP для каждого нового запроса или нового соединения. Целевой сайт может увидеть 1000 запросов с 1000 разных адресов. Это распределяет счётчики по IP, но впечатления «одного и того же пользователя» между запросами не возникает.

На практике большинство шлюзов меняет IP на уровне соединения. Для HTTPS-запроса клиент открывает туннель к прокси через CONNECT; если тот же keep-alive туннель используется повторно, следующие запросы могут уйти через тот же выход. Если нужен новый IP на каждый запрос, отправляйте каждый запрос через новое соединение.

Sticky-сессия с таймером

В sticky-сессии идентификатор сессии (session ID) привязывается к определённому выходному IP. Все запросы с этим ID выходят с одного IP, пока не истечёт время или пока выходное устройство не отключится. После истечения срока тот же ID получает из пула новый IP.

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

Статический IP

У статического прокси IP закреплён за вами на период пакета и не делится с пулом. Понятия длительности сессии здесь нет; IP остаётся тем же, пока вы его не смените или пока не закончится пакет. Эта модель нужна для аккаунтов, которые неделями должны работать с одной идентичностью, для панелей с IP whitelist и для длительной автоматизации.

Как настраивается sticky-сессия?

Большинство провайдеров включает sticky одним из двух способов. Первый — добавить session ID в имя пользователя: логин содержит выбранный вами ID сессии, а иногда параметр длительности или страны. Пока шлюз видит тот же ID, он использует тот же выход. Второй — разделение по портам: некоторые провайдеры выделяют одни диапазоны портов под sticky, другие под rotating.

В residential и мобильных пулах WeProxy sticky включается добавлением session ID к имени пользователя. Так можно удерживать один выходной IP до 24 часов в residential-пуле и до 60 минут в мобильном. Точный формат имени пользователя зависит от продукта; копируйте его из данных подключения в клиентской панели, а не подбирайте вручную.

При выборе session ID помогают три правила:

1. Одна идентичность — один ID. Каждый аккаунт или браузерный профиль должен использовать собственный session ID. Если два профиля делят один ID, сайт видит двух разных пользователей с одного IP.
2. Храните ID постоянно. Если процесс при перезапуске генерирует новый случайный ID, тот же аккаунт вернётся с новым IP. Храните ID в файле или базе данных вместе с записью профиля.
3. Меняйте ID, когда нужен новый IP. Если IP заблокирован, повтор с тем же ID вернёт тот же выход. Новый ID — новый выход.

Быстрее всего проверить настройку, дважды подряд запросив выходной IP с одним session ID. В браузере это делает инструмент My IP, в командной строке достаточно api.ipify.org. Если оба значения совпадают, сессия работает как sticky.

Что ломается, если IP меняется посреди сессии?

Веб-приложения узнают пользователя по cookies, но многие также записывают, с какого IP пришла cookie. RFC 6265 не привязывает cookies к IP; проверку IP добавляет само приложение и его слой безопасности. Поэтому один и тот же запрос после смены IP проходит на одном сайте и обрывает сессию на другом.

Типичные поломки:

• Слетает сессия логина. Если cookie сессии сопоставляется с IP или ASN, запрос с нового IP считается вне сессии. Пользователя отправляют на страницу входа или просят дополнительную проверку.
• Ломаются корзина и checkout. Корзина на стороне сервера привязана к сессии. Если на этапе оплаты меняются IP и страна, антифрод может остановить операцию или сбросить корзину.
• Отклоняется CSRF-токен. Форма несёт токен, созданный вместе со страницей, и этот токен привязан к cookie сессии. Если сессия обновилась из-за смены IP, старый токен становится недействительным и форма возвращает 403. Механизм описан в статье MDN о CSRF.
• Cookies антибот-защиты пропадают зря. Некоторые системы защиты выдают проверочную cookie при первом визите и оценивают её вместе с IP. В режиме rotating каждый запрос приходит с нового IP, и проверка каждый раз начинается заново.
• Накапливаются сигналы риска. Если один аккаунт за несколько минут появляется из разных городов или стран, системы безопасности могут пометить это как «необычный вход».

Общее у этих проблем — состояние. Для запросов без состояния, таких как списки товаров, результаты поиска или публичные страницы цен, смена IP ничего не ломает. Сценарий с состоянием должен целиком проходить с одного IP.

Как лимиты на IP влияют на выбор ротации?

Лимиты частоты обычно считаются по IP. Сервер подсчитывает запросы с одного адреса за период и при превышении порога возвращает 429 Too Many Requests. RFC 6585 определяет этот код; время ожидания сервер обычно сообщает в заголовке Retry-After.

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

Лимиты привязаны не только к IP. Некоторые сайты ограничивают запросы по аккаунту, cookie сессии, API-ключу или отпечатку устройства. В этом случае ротация IP счётчик не сбрасывает: запросы залогиненного аккаунта пишутся в счётчик аккаунта, с какого бы IP они ни приходили.

В пакетах WeProxy нет ограничений на число потоков и одновременных сессий. Поэтому если вы получаете 429, лимит ставит целевой сайт. Диагностика и стратегия backoff описаны в руководстве по кодам ошибок прокси. Обходить лимит за счёт расширения пула — не решение, если это нарушает условия использования целевого сайта.

Когда использовать sticky, а когда rotating?

Задайте два вопроса: передаёт ли сценарий состояние и как долго должна жить одна идентичность? Таблица ниже сопоставляет типичные сценарии с этими вопросами.

У верификации рекламы две разные задачи. Чтобы увидеть, как объявление показывается в разных регионах, подходит rotating. Чтобы пройти цепочку редиректов клика от начала до конца, на всей цепочке нужен один IP; здесь используется короткая sticky-сессия. Подробнее о SEO, scraping и рекламе — в статье о сценариях использования и на странице web scraping.

При проверке SERP ротация должна менять IP, но не страну. Зафиксируйте таргетинг страны и меняйте IP; случайная страна портит данные о позициях. Варианты таргетинга описаны в руководстве по таргетингу на страну, город и ASN.

Как совмещать sticky и rotating?

Большинство реальных сценариев используют обе модели. Часть без состояния выходит из rotating-пула, часть с состоянием — через sticky-сессию или статический IP. Такое разделение и распределяет счётчик, и сохраняет сессию.

Распространённые гибридные схемы:

• Обход через rotating, детали через sticky. Категории и списки сканируются через rotating. Детальные страницы, требующие логина или многошаговой формы, открываются в sticky-сессии.
• Sticky на аккаунт, разные IP у разных аккаунтов. Каждый аккаунт держится на одном IP со своим session ID. Аккаунты выходят с разных IP, поэтому на одном IP не видно нескольких аккаунтов.
• Статическая основная идентичность, rotating для вспомогательных запросов. Панель аккаунта управляется со статического IP. Публичные данные для той же задачи (например, прайс-лист конкурента) собираются отдельным rotating-потоком.
• Короткие sticky-блоки. На сайтах, где сессия не нужна, но несколько запросов подряд с одного IP выглядят естественнее, используют sticky-блоки по несколько минут; после окончания блока работа продолжается с новым ID.

Самая частая ошибка гибридной схемы — общая банка cookies для обоих потоков. Если cookies из rotating-потока смешиваются с cookies sticky-сессии, сайт видит одну сессию с разных IP. Каждый поток должен использовать свою HTTP-сессию и своё хранилище cookies.

Как реализовать sticky-идентичности и rotating-пул на Python?

Пример ниже держит две модели раздельно. У каждой sticky-идентичности свой session ID и свой объект requests.Session; cookies и соединения остаются внутри этой идентичности. Rotating-запросы отправляются без объекта сессии, каждый раз через новое соединение.

import uuid
import requests

GATEWAY = "gw.weproxy.com.tr:8989"
PASSWORD = "PASSWORD"
ROTATING_USER = "USER"
# Укажите формат sticky-логина из панели; {sid} — место для ID сессии
STICKY_USER_TEMPLATE = "USER_STICKY_FORMAT_{sid}"


def proxy_url(user):
    return f"http://{user}:{PASSWORD}@{GATEWAY}"


class StickyIdentity:
    def __init__(self, name, sid=None):
        self.name = name
        self.sid = sid or uuid.uuid4().hex[:12]  # храните постоянно
        url = proxy_url(STICKY_USER_TEMPLATE.format(sid=self.sid))
        self.session = requests.Session()
        self.session.trust_env = False
        self.session.proxies = {"http": url, "https": url}

    def get(self, url, **kwargs):
        return self.session.get(url, timeout=(10, 30), **kwargs)

    def post(self, url, **kwargs):
        return self.session.post(url, timeout=(10, 30), **kwargs)


def rotating_get(url):
    # Без объекта сессии и keep-alive: каждый вызов — новое соединение
    proxy = proxy_url(ROTATING_USER)
    return requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers={"Connection": "close"},
        timeout=(10, 30),
    )


identities = {name: StickyIdentity(name) for name in ("profile-a", "profile-b")}

for name, identity in identities.items():
    first = identity.get("https://api.ipify.org").text
    second = identity.get("https://api.ipify.org").text
    print(name, first, second, "тот же IP" if first == second else "IP сменился")

for _ in range(3):
    print("rotating:", rotating_get("https://api.ipify.org").text)

Замените строку STICKY_USER_TEMPLATE форматом из вашей панели. В rotating-продукте запросы без параметра сессии получают выход из пула; поведение вашего пакета по умолчанию проверьте в панели. trust_env = False не даёт переменной окружения HTTP_PROXY перезаписать прокси из кода.

В этой структуре один аккаунт — один объект StickyIdentity. Запросы логина, корзины и форм всегда идут через методы get и post этого объекта; CSRF-токен и cookie сессии остаются в одном хранилище. Если IP заблокирован, создайте новый объект с новым sid и залогиньтесь заново. Больше примеров подключения — на странице интеграции с Python. Как повторное использование соединений влияет на ротацию и как то же сделать в httpx и aiohttp, разобрано в руководстве по proxy в Python.

Какой продукт WeProxy подходит для какой модели сессий?

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

Rotating Residential IPv4 даёт обе модели в одном пакете: rotating без session ID, sticky с ним. Он подходит командам, которые хотят разделить массовый scraping и шаги с логином в рамках одного пакета. Статический Residential IPv4 предназначен для аккаунтов, идентичность которых должна жить днями, и для панелей с whitelist. Sticky IPv6 даёт сессии с выбираемой длительностью для целей с поддержкой IPv6, с выходами в Нидерландах, США, Великобритании, Германии и Канаде. До покупки проверьте, принимает ли цель IPv6, тестом из руководства IPv4 vs IPv6.

Аутентификация по логину/паролю и по IP whitelist работает через HTTP и SOCKS5 во всех пакетах. Ограничений на потоки и одновременные сессии нет; лимит задают правила самого целевого сайта.

Типичные ошибки и чек-лист

Большинство ошибок с моделью сессий укладывается в несколько повторяющихся шаблонов:

• Сценарий с логином на rotating. Обход списков может оставаться rotating, но каждый шаг после логина должен быть sticky.
• Считать sticky постоянным. Длительность sticky — верхняя граница. Для идентичности на несколько дней выбирайте статический IP.
• Высокая параллельность на одном sticky IP. Все запросы попадают в один счётчик. Разделите работу между несколькими session ID или снизьте скорость.
• Ждать ротации при keep-alive. Если тот же туннель используется повторно, IP может не смениться. Для rotating-запросов открывайте новое соединение.
• Оставлять страну случайной. В задачах SERP и цен страна должна быть фиксированной, меняться должен только IP.

Короткий чек-лист перед стартом:

1. Передаёт ли сценарий состояние? Если да — sticky или статический IP, если нет — rotating.
2. Как долго должна жить идентичность? Минуты и часы — sticky, дни — статический IP.
3. У каждого аккаунта или профиля свой session ID и своё хранилище cookies?
4. Два последовательных запроса с одним ID возвращают один IP? Проверьте через инструмент My IP.
5. Скорость ниже лимитов цели на IP и на аккаунт? Соблюдается ли Retry-After?
6. Соответствует ли автоматизация условиям целевого сайта и правилам допустимого использования WeProxy?

Sticky даёт непрерывность, rotating — распределение. Сначала проверьте, передаёт ли сценарий состояние, затем — как долго должна жить идентичность. Эти два ответа определяют модель; тип прокси и страна идут после.