Закреплённые сессии (Sticky Sessions)
Закреплённая сессия указывает прокси-сервису сохранять один выходной IP для связанных запросов. Программа может открывать страницы, отправлять данные и получать результат через этот адрес, пока закрепление действует и выход доступен. После завершения задачи программа может начать отдельную сессию для следующей задачи.
Обычно это один из режимов доступа к ротационному пулу. Общий выбор между постоянными и меняющимися адресами разобран в статье Статические прокси и прокси с ротацией. Здесь речь о том, как удержать адрес на время одной задачи, сколько действует закрепление и что может его прервать.
Как сервис сохраняет выбранный IP
Сервису нужно распознавать соединения одной задачи. Часто для этого используется идентификатор сессии в настройках прокси. При первом подключении сервис выбирает выход и связывает его с идентификатором. Пока сессия действует, следующие соединения с теми же параметрами используют назначенный выход.
Например, тест в браузере использует имя сессии task1. Для первого соединения выбран условный выходной IP 198.51.100.27. Открытие следующей страницы и отправка формы через то же действующее закрепление проходят с этим адресом. Имя обозначает назначение: оно не содержит сам IP и не резервирует его навсегда.
Идентификатор могут добавлять в имя пользователя прокси, передавать через API или задавать выбором настроенного порта. Некоторые сервисы также предоставляют сессию по умолчанию без отдельного имени. Это разные способы управления закреплением, поэтому единого формата логина или номера порта для sticky-доступа нет.
Одна закреплённая сессия может охватывать несколько сетевых соединений. Это отличается от повторного использования одного открытого соединения: запросы внутри одного обычного TCP-соединения и так сохраняют его выходной IP. Чтобы понять, удерживается ли адрес между соединениями, важно наблюдать, что происходит при открытии нового соединения с прежними параметрами сессии.
Когда нескольким запросам нужен один IP
Наглядный пример — многошаговый тест в браузере. Он может включать вход в аккаунт, открытие настроек, отправку изменения и проверку результата. Одинаковый выходной IP убирает лишнее изменение в ходе теста, особенно если сайт учитывает адрес при проверке пользовательской сессии.
При тестировании покупки или бронирования может быть важно сохранить одинаковую региональную версию сервиса. Программа выполняет поиск, выбирает вариант и проверяет следующий этап через один выход. Это помогает сохранить сетевое местоположение между шагами, хотя сайт также может учитывать настройки аккаунта, адрес доставки или cookies.
Ещё один случай — последовательность вызовов API, где принимающий сервис ожидает связанные действия с одного исходящего адреса. Закрепление должно охватывать всю последовательность, включая паузы и повторные попытки. Для независимых запросов публичных страниц один IP, напротив, нужен не всегда. Удержание адреса полезно там, где задача зависит от его постоянства; само по себе оно не улучшает репутацию IP и не гарантирует, что сайт примет запрос.
Сессия прокси не сохраняет вход на сайт
Прокси-сервис управляет выходным адресом. Сайт управляет собственной сессией: входом в аккаунт, корзиной или продвижением по форме. Браузер либо HTTP-клиент обычно передаёт сведения об этом состоянии с помощью cookies или токенов авторизации. В обоих случаях используется слово «сессия», но сохраняются разные данные.
Поэтому срок авторизации может закончиться, даже если выходной IP не изменился. Удаление cookies тоже может лишить сайт возможности узнать пользователя, не затрагивая закрепление прокси. Возможно и обратное: сайт принимает действующую авторизацию после смены IP. Это зависит от его собственных правил.
Объект сессии в HTTP-библиотеке часто хранит cookies и повторно использует соединения. Его создание не включает sticky-режим у прокси-сервиса автоматически. Для выполнения всей последовательности программа должна сохранять и состояние работы с сайтом, и нужное назначение прокси. Если разные задачи не должны разделять cookies, им по-прежнему нужны отдельные профили браузера или изолированное состояние клиентов.
Что на самом деле означает срок сессии
Под сроком сессии могут подразумеваться два разных таймера. Фиксированный срок ограничивает длительность закрепления от момента его начала. Таймер бездействия ограничивает паузу после последнего учитываемого запроса. Новые запросы могут перезапускать таймер бездействия, не продлевая отдельный фиксированный срок.
| Ограничение | Откуда идёт отсчёт | Что меняет новый запрос |
|---|---|---|
| Фиксированный срок | От создания назначения или его первого использования — по правилам сервиса | Не меняет исходное время окончания |
| Таймер бездействия | От последнего запроса или другого действия, которое сервис считает активностью | Запускает отсчёт бездействия заново, если учитывается как активность |
Возьмём для примера две сессии с ограничением десять минут. Обе начались в 14:00 и получили ещё один запрос в 14:08. При фиксированном сроке граница остаётся прежней — 14:10. При таймере бездействия этот запрос сдвигает границу до 14:18. Одна и та же заявленная длительность может означать совершенно разное поведение во время работы.
Сервис может применять оба ограничения одновременно. Тогда закрепление заканчивается при достижении любого из них. Настройка по умолчанию также может отличаться от максимальной доступной длительности. Непрерывные запросы помогают избежать завершения из-за бездействия, но не отменяют отдельный предельный срок.
После истечения срока прежний выход больше не закреплён за сессией. Следующее соединение может получить другой адрес даже с тем же именем. Уже открытому соединению сервис может дать завершиться либо закрыть его. Таймер не переносит незаконченный обмен по TCP на другой IP.
Выбирать длительность стоит с учётом всей задачи, медленных ответов и ожидаемых пауз. Если начать новую работу под конец старого закрепления, времени останется меньше, чем можно предположить по настройке сессии. Запросы только ради поддержания активности тоже остаются настоящим трафиком и могут расходовать пакет запросов или объём передачи данных.
Как разделять параллельные задачи
Когда независимым задачам нужен стабильный адрес для каждой, назначайте им отдельные идентификаторы сессий и сохраняйте эти идентификаторы между шагами. Процесс, открывающий следующую страницу, должен использовать сессию своей задачи, а не создавать новое имя для каждого запроса. Повторная попытка в рамках этой задачи также не должна незаметно переходить на другие настройки прокси.
Допустим, одновременно выполняются два теста в браузере. Первый использует task1, второй — task2, а cookies у них хранятся отдельно. Одинаковое имя сессии при совпадении остальных параметров попросило бы сервис использовать одно назначение для обоих тестов. Открытие новой обычной вкладки само по себе не создаёт ни отдельных настроек прокси, ни отдельного хранилища cookies.
Разные идентификаторы запрашивают отдельные назначения, но не во всех сервисах гарантируют разные выходные IP. Обещание выдать неповторяющиеся адреса — отдельное свойство продукта. Sticky-доступ также не делает выход эксклюзивным для вашего аккаунта: если адрес принадлежит общему пулу, им могут пользоваться и другие клиенты.
Если сервис это поддерживает, одну сессию можно использовать в нескольких соединениях одновременно. У них общий выход, и на них действуют лимиты соединений и использования аккаунта. Дополнительные имена сессий не повышают эти лимиты. Перед полным запуском учитывайте и число параллельных задач, и число соединений внутри каждой.
Почему адрес может измениться раньше ожидаемого
Действующий таймер не может сохранить работоспособность недоступного выхода. Резидентское устройство может отключиться, мобильное подключение — получить другой публичный IP, а сервер — стать недоступным. Запрошенная длительность описывает правила отсчёта времени; сама по себе она не гарантирует доступность исходного выхода на весь срок.
При потере выхода возможны два варианта. Сервис может подобрать замену, чтобы следующие запросы продолжились, или вернуть ошибку, сохранив требование использовать исходный выход. Некоторые продукты позволяют выбирать это поведение. Автоматическая замена помогает установить следующее соединение; ошибка даёт программе возможность остановиться перед продолжением с другого адреса.
Неизменное имя ещё не означает, что остальные параметры сессии сохранились. Переход на другой шлюз или изменение фильтра страны может создать другое назначение. Область действия зависит от сервиса: сессия может относиться к конкретному аккаунту, продукту или входному серверу, а не существовать повсюду под одним именем.
Если адрес сменился посреди задачи, дальнейшее решение зависит от того, что уже успело выполниться. Шаг, который только читает данные, может допускать безопасный повтор. Действие, отправившее заказ или изменившее данные, требует другого подхода: потерянный ответ не доказывает, что действие не состоялось. Перед перезапуском или продолжением через новый выход нужно выяснить, какие шаги завершились.
Когда временного закрепления достаточно
Закреплённая сессия подходит задаче с понятным началом и концом, которой нужен один IP лишь на время запуска. Проверьте три вещи: выдерживает ли закрепление ожидаемые паузы, хватает ли его на всю задачу и что произойдёт при потере выхода. Включите в тест новое соединение после обычной паузы: работа внутри одного открытого соединения ещё не показывает, сохранится ли адрес при следующем подключении.
Если адрес должен оставаться в списке разрешённых IP на сервере или снова быть доступен завтра, нужен сервис с постоянным назначением для этой цели. Повторное использование имени sticky-сессии после её завершения не позволяет надёжно вернуть прежний адрес. Временное удержание и постоянный назначенный IP решают разные задачи сохранения адреса.