Sticky session: когда IP нельзя менять
Ротация IP — стандартный инструмент обхода rate limit при парсинге. Но есть задачи, где смена адреса на каждом запросе только вредит: авторизованные сессии, многошаговые формы, антифрод-системы с привязкой к IP. В таких случаях нужна sticky session — закрепление одного выходного адреса на определённый период или до завершения цепочки действий.
Что такое sticky session
Sticky session (липкая сессия) означает, что прокси-провайдер или ваш клиент удерживает один и тот же IP для группы запросов. На практике это реализуется двумя способами: статический приватный IPv4, который не меняется весь срок аренды, или сессионный sticky у резидентных и ротирующих провайдеров — IP фиксируется на 5–30 минут по session-id в URL или заголовке.
На тарифах NEONPROXY приватный IPv4 по умолчанию работает как «вечный sticky»: вы получаете выделенный адрес, и все запросы через него идут с одного IP. Для парсинга с ротацией используйте пул адресов, но каждый воркер закрепляет свой IP на время обработки задачи — подробнее в материале про ротацию прокси.
Когда sticky обязателен
Авторизация и cookies. После логина сервер часто привязывает сессию к IP. Если следующий запрос придёт с другого адреса, вас разлогинит или отправят на повторную верификацию. Это типично для личных кабинетов маркетплейсов, CRM и банковских порталов.
Многошаговые сценарии. Оформление заказа, прохождение CAPTCHA, загрузка файлов через несколько эндпоинтов — каждый шаг должен идти с одного IP. Смена адреса между POST-запросами ломает CSRF-токены и server-side state.
SMM и мультиаккаунтинг. Соцсети отслеживают резкие смены геолокации и IP внутри одной сессии. Для Instagram, Facebook и TikTok рекомендуется один IP на аккаунт на весь период работы — см. также прокси для Instagram.
WebSocket и long polling. Долгоживущие соединения требуют стабильного маршрута. Ротация IP обрывает канал и заставляет клиента переподключаться с потерей контекста.
Когда sticky не нужен
Массовый сбор публичных данных с однотипных страниц — каталоги, прайсы, SEO-выдача — выигрывает от ротации: блокировка одного IP не останавливает весь пайплайн. Здесь лучше пул из десятков IPv6 или shared-адресов с round-robin между воркерами.
Тестовые запросы к API без состояния (stateless REST) тоже не требуют sticky: каждый GET независим, и rate limit снимается сменой IP.
Как настроить sticky в коде
В Python с библиотекой requests создайте один Session-объект и один прокси на воркер:
session = requests.Session()session.proxies = {"https": "http://user:pass@ip:port"}
Все вызовы через session.get() и session.post() сохраняют cookies и идут через один адрес. Для параллельных задач запускайте отдельный session на каждый поток — не делите один session между потоками без блокировок.
В Node.js используйте агент с keepAlive и фиксированным proxy URL на экземпляр axios или undici. В Scrapy — middleware с привязкой proxy к spider или request meta.
Перед продакшеном проверьте, что IP действительно не меняется: два последовательных запроса к «Мой IP» через ваш прокси должны вернуть одинаковый адрес.
Типичные ошибки
Использование ротирующего прокси там, где нужен sticky — классическая причина «вылетов» из аккаунта. Смешение sticky и rotating на одном профиле браузера: утром один IP, вечером другой. Игнорирование TTL сессии у резидентных прокси: sticky истекает через 10 минут, а скрипт продолжает слать запросы и получает 403.
Shared-прокси для задач с sticky — рискованно: сосед по IP может спровоцировать бан всей подсети, и ваш «фиксированный» адрес перестанет работать без предупреждения.
Выбор типа прокси под sticky
Приватный IPv4 — оптимален для SMM, рекламных кабинетов и длительных автоматизаций. IPv6 — для stateless-парсинга, где sticky не критичен, но нужен объём. SOCKS5 удобен для браузеров и приложений, которые не поддерживают HTTP-прокси — сравнение протоколов в статье SOCKS5 vs HTTPS.
Если задача сочетает sticky для авторизации и ротацию для массовых GET — разделите на два пула: «session pool» из 1–5 приватных IPv4 и «crawl pool» из IPv6. Так вы не жертвуете ни стабильностью аккаунтов, ни скоростью сбора данных.
Чеклист перед запуском
Определите, есть ли server-side session (cookies, JWT с привязкой к IP). Закрепите один прокси на один логический актор (аккаунт, воркер, браузерный профиль). Проверьте IP через чекер: latency, гео, анонимность. Заложите мониторинг: если IP «умер», воркер должен остановиться, а не молча переключиться на другой.
NEONPROXY выдаёт приватные IPv4 с фиксированным адресом на весь срок аренды — идеальная база для sticky session без дополнительных параметров в URL.