Содержание статьи

Вы наверняка сталкивались с этим: скрипт работает, авторизуется на сайте, кладёт товар в корзину, а потом происходит смена IP, и внезапно сервер отвечает так, будто вы здесь впервые. Пользователь разлогинен, корзина пуста, токен недействителен. Раздражает? Ещё как. Но у этой проблемы есть чёткое инженерное решение, и в этом гайде мы разберём его от начала до конца.

Введение: почему после смены IP разлогинивает и корзина пустеет

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

Что получит читатель в итоге

К концу этого руководства вы будете уметь следующее. Во-первых, понимать, что реально привязано к IP на стороне сервера, а что является мифом. Во-вторых, выстраивать строгое правило соответствия: одна логическая сессия равна одному набору cookies равна одному IP. В-третьих, писать рабочий код на Python и на Node.js, который изолирует состояние между разными прокси и не путает данные. В-четвёртых, сохранять состояние между запусками программы и понимать, когда его проще выбросить.

Для кого этот гайд

Гайд рассчитан на средний уровень. Вы уже пишете код на Python или JavaScript, понимаете, что такое HTTP-запрос, представляете, зачем нужны прокси. Мы не будем обсуждать, какой тип ротации выбрать - для этого есть отдельные материалы. Здесь мы исходим из того, что ротация IP уже происходит по вашим правилам, и решаем ровно одну задачу: как не терять состояние при этой ротации.

Что нужно знать заранее

Полезно понимать базовые вещи. Что такое cookie - это маленький кусочек данных, который сервер просит браузер или клиент запомнить и присылать обратно с каждым запросом. Что такое сессия - это способ сервера узнавать вас между запросами. Что такое токен - строка, подтверждающая вашу личность или право на действие. Если эти термины пока размытые, не волнуйтесь: в разделе базовых понятий мы разберём каждый простым языком.

Сколько времени потребуется

На чтение и понимание теории уйдёт около сорока минут. На разбор и запуск кода на вашем языке - ещё час-полтора. Полное усвоение с экспериментами на реальных задачах - два-три часа. Не торопитесь. Лучше медленно понять принцип, чем быстро скопировать код, который потом сломается непонятным образом.

Предварительная подготовка: инструменты и окружение

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

Необходимые инструменты

  • Python версии 3.10 или новее - если вы работаете на Python. В 2026 году актуальны версии 3.12 и 3.13, но всё описанное работает начиная с 3.10.
  • Node.js версии 20 LTS или новее - если вы работаете на JavaScript. Подойдёт и версия 22 LTS.
  • Прокси с ротацией IP - у вас уже должен быть доступ к пулу адресов. Формат подключения обычно такой: протокол, хост, порт, логин и пароль.
  • Редактор кода - подойдёт любой, например бесплатный редактор с подсветкой синтаксиса.
  • Терминал или командная строка - для установки библиотек и запуска скриптов.

Системные требования

Требования скромные. Любой современный компьютер справится. Оперативной памяти достаточно четырёх гигабайт, но если планируете много параллельных сессий, лучше восемь и больше. Важнее стабильное интернет-соединение, потому что при потере связи cookies могут не сохраниться корректно.

Что нужно установить

Для Python установите две библиотеки. Откройте терминал и выполните команду установки пакета requests и пакета для работы с прокси. Пишется это так: сначала команда установки менеджера пакетов, затем название requests. Для сериализации состояния пригодится стандартный модуль, устанавливать отдельно его не нужно.

Для Node.js установите три пакета: axios для запросов, tough-cookie для управления хранилищем cookies и https-proxy-agent для подключения через прокси. Все три ставятся одной командой установки пакетов в вашем проекте.

Совет: Создайте отдельную виртуальную папку для проекта. В Python это виртуальное окружение, в Node.js - отдельная директория с файлом описания зависимостей. Так вы не смешаете библиотеки разных проектов и избежите конфликтов версий.

Создание резервных копий

Если вы уже сохраняете cookies в файлы или базу данных, сделайте копию перед экспериментами. Мы будем менять логику сериализации, и есть риск повредить существующие данные. Просто скопируйте папку с сохранёнными состояниями в место с пометкой backup.

Проверка: После установки убедитесь, что всё работает. Запустите короткую проверку версии Python или Node.js в терминале. Вы должны увидеть номер версии без ошибок. Затем попробуйте импортировать установленные библиотеки в интерактивном режиме - если импорт проходит молча, всё готово.

Базовые понятия: что привязано к IP, а что миф

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

Cookie-сессия

Cookie-сессия - это когда сервер выдаёт вам идентификатор сессии в виде cookie, а сам хранит состояние у себя. Например, cookie с именем sessionid и длинной случайной строкой внутри. Сервер по этой строке находит вашу запись в своей памяти. Привязан ли этот механизм к IP? Сам по себе - нет. Cookie работает независимо от адреса. Но многие сервисы добавляют дополнительную проверку: они запоминают, с какого IP была создана сессия, и если запрос с тем же cookie приходит с другого адреса, считают это подозрительным. Вот тут и происходит разлогин.

CSRF-токен

CSRF-токен - это защита от подделки запросов. Сервер выдаёт токен, вы должны прислать его обратно при отправке формы или важного действия. К IP этот токен не привязан почти никогда. Он связан с сессией, а не с адресом. Проблема с ним возникает по другой причине: если вы потеряли cookie сессии, то и CSRF-токен становится недействительным, потому что сервер не может сопоставить его с вашей сессией. То есть проблема здесь вторичная - следствие потери cookies.

JWT

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

Серверная сессия

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

Корзина

Корзина - частный случай серверной сессии либо cookie. В простых магазинах корзина хранится в cookie прямо у клиента. В сложных - на сервере, привязанная к сессии. Если корзина пустеет после смены IP, значит, она была привязана к серверной сессии, которая проверяет адрес. Решение то же самое: не менять IP в рамках одной логической сессии либо аккуратно сохранять весь набор cookies.

Итог: где IP правда участвует

Соберём картину. Сам HTTP-механизм cookies, CSRF, JWT к IP не привязан. Привязка возникает как дополнительная проверка на стороне сервиса, и вы не можете ей управлять. Единственное, чем вы управляете, - это соответствием между сессией, набором cookies и IP на вашей стороне. Отсюда вытекает главное правило гайда.

Проверка: Проверьте своё понимание. Если после смены IP сессия слетает, но при возврате на старый IP всё восстанавливается, значит, сервер жёстко проверяет адрес. Если не восстанавливается даже на старом IP - вы просто потеряли cookies в коде. Это два разных диагноза с разными лечениями.

Шаг 1: Формулируем правило соответствия

Цель этапа: закрепить главный принцип и понять, как выразить его в структуре кода.

Правило звучит просто: одна логическая сессия равна одному набору cookies равна одному IP. Разберём, что это значит на практике.

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

Как выразить это в коде? Очень наглядно: создаём объект-контейнер, который содержит внутри себя и хранилище cookies, и настройку прокси. Пока живёт этот объект, живёт логическая сессия. Когда пора менять IP, мы либо создаём новый контейнер, либо, если сервис терпим к смене адреса, аккуратно переносим cookies в новый контейнер с новым IP.

⚠️ Внимание: Самая частая архитектурная ошибка - хранить один общий набор cookies и подставлять к нему разные прокси. Это гарантированно ломает всё. Разные логические сессии начинают затирать cookies друг друга, и сервер получает противоречивые данные. Никогда так не делайте.

Совет: Думайте о логической сессии как о человеке. У одного человека одни документы (cookies) и один дом (IP). Нельзя, чтобы двое людей пользовались одними документами, и нельзя, чтобы один человек жил одновременно в двух домах. Эта аналогия убережёт вас от большинства ошибок.

Проверка: Нарисуйте на бумаге свою будущую структуру. У вас должно получиться несколько независимых блоков, каждый со своим хранилищем cookies и своим прокси. Между блоками нет общих данных. Если так - вы поняли правило.

Шаг 2: Практика на Python - Session на каждый прокси

Цель этапа: написать рабочий код, где каждая логическая сессия имеет свой объект requests.Session, свой CookieJar и свой прокси, изолированные друг от друга.

В библиотеке requests есть объект Session. Он сам по себе является контейнером: внутри держит хранилище cookies и умеет применять настройки ко всем запросам. Это идеальная основа для нашей логической сессии.

Базовая структура

  1. Создайте функцию, которая принимает данные одного прокси и возвращает готовый объект Session.
  2. Внутри функции создайте новый объект Session.
  3. Задайте объекту настройку proxies - словарь с адресом прокси для протоколов http и https.
  4. Верните объект. Теперь у вас есть изолированный контейнер.

Код выглядит так. Строчно: импортируем requests. Определяем функцию make_session, принимающую строку proxy_url. Внутри пишем s равно requests точка Session скобки. Затем s точка proxies равно словарю, где ключ http указывает на proxy_url и ключ https указывает на proxy_url. В конце return s. Всё, функция готова.

Почему это изолирует состояние

Каждый вызов make_session создаёт совершенно новый объект. У нового объекта своё собственное внутреннее хранилище cookies, называемое cookiejar. Cookies, полученные одной сессией, физически не могут попасть в другую сессию, потому что это разные объекты в памяти. Именно этого мы и добивались.

Использование сессии

  1. Получите объект сессии вызовом функции с нужным прокси.
  2. Выполняйте запросы через методы этого объекта: s точка get или s точка post.
  3. Cookies, которые сервер пришлёт в заголовке Set-Cookie, автоматически сохранятся внутри объекта.
  4. При следующих запросах через тот же объект эти cookies отправятся обратно автоматически.

Совет: Не создавайте новый Session на каждый отдельный запрос внутри одной логической сессии. Тогда cookies не будут накапливаться. Создавайте объект один раз на всю логическую сессию и используйте его для всех запросов этой сессии.

Изоляция между потоками

Если вы работаете в несколько потоков, каждый поток должен иметь свой собственный объект Session. Объект Session не является потокобезопасным. Это значит, что если два потока одновременно пишут cookies в один объект, данные могут повредиться.

  1. Используйте механизм локальных данных потока. В Python это объект threading.local.
  2. При старте каждого потока создавайте для него отдельную сессию и сохраняйте её в локальное хранилище потока.
  3. Внутри потока обращайтесь только к своей сессии, не трогая чужие.

Практически это выглядит так: создаём глобальный объект local равно threading точка local скобки. В начале работы потока проверяем, есть ли у local атрибут session. Если нет - создаём его вызовом make_session с прокси, назначенным этому потоку. Далее в потоке используем local точка session для всех запросов.

⚠️ Внимание: Никогда не передавайте один объект Session между потоками как общий ресурс. Даже если кажется, что запросы идут по очереди, планировщик может переключить потоки в самый неподходящий момент, и вы получите смешанные cookies. Каждому потоку - свой объект.

Ротация внутри логики

Когда ротация IP произошла и вам нужен новый адрес, поступайте так. Завершите текущую логическую сессию: если сервер жёстко привязывает к IP, просто создайте новый объект Session с новым прокси и начните с чистого листа - заново авторизуйтесь. Если сервер терпим к смене адреса, вы можете перенести cookies, о чём поговорим в шаге про хранение состояния.

Проверка: Запустите две сессии с разными прокси, авторизуйтесь в каждой на тестовом сервисе, который показывает ваш IP и cookies. Убедитесь, что каждая сессия видит свой IP и свой набор cookies. Если данные не смешиваются - изоляция работает правильно.

Шаг 3: То же самое на Node.js

Цель этапа: собрать эквивалентную конструкцию на JavaScript с использованием axios, tough-cookie и агента прокси.

В экосистеме Node.js нет готового объекта уровня Session, поэтому мы соберём его из трёх частей. Хранилище cookies возьмём из tough-cookie. Подключение через прокси обеспечит агент. Запросы будет делать axios.

Собираем контейнер

  1. Импортируйте класс CookieJar из библиотеки tough-cookie.
  2. Импортируйте функцию создания агента прокси из библиотеки https-proxy-agent.
  3. Импортируйте axios.
  4. Создайте функцию makeClient, которая принимает адрес прокси и возвращает настроенный объект.

Внутри функции создайте новый экземпляр хранилища: const jar равно new CookieJar скобки. Создайте агента прокси, передав ему адрес: const agent равно new HttpsProxyAgent с адресом прокси. Создайте экземпляр axios с настройками через метод axios точка create, передав в него httpsAgent равный agent и httpAgent равный agent.

Подключаем автоматическую работу с cookies

Голый axios не умеет сам класть cookies из ответа в хранилище и доставать их для запроса. Есть два пути.

  1. Первый путь: использовать готовую обёртку, которая связывает axios и tough-cookie, устанавливается отдельным пакетом. Она автоматически читает и пишет cookies через переданное хранилище jar.
  2. Второй путь: сделать это вручную через перехватчики запросов и ответов. Перед запросом достаём строку cookies из хранилища для нужного адреса и кладём в заголовок Cookie. После ответа берём заголовок Set-Cookie и записываем каждую cookie в хранилище.

Совет: Для начала используйте готовую обёртку - меньше шансов ошибиться. Ручной вариант оставьте на случай, когда вам нужно тонко контролировать процесс, например логировать каждую cookie.

Изоляция между параллельными задачами

В Node.js модель другая - здесь не потоки, а асинхронные задачи в одном потоке событий. Но принцип тот же: у каждой логической сессии свой отдельный объект client со своим jar и своим агентом.

  1. Для каждой параллельной задачи вызывайте makeClient отдельно.
  2. Храните клиентов в массиве или карте, где ключ - идентификатор задачи.
  3. Никогда не используйте один jar для нескольких клиентов одновременно.

⚠️ Внимание: В асинхронном коде легко случайно расшарить один client между несколькими цепочками промисов. Тогда cookies начнут перемешиваться между логическими сессиями. Всегда проверяйте, что каждая цепочка использует свой клиент, созданный отдельным вызовом makeClient.

Ротация на Node.js

Логика идентична Python. Когда нужен новый IP и сервис привязывает сессию к адресу - создайте новый client с новым прокси и новым пустым jar, авторизуйтесь заново. Когда сервис терпим - перенесите содержимое старого jar в новый client с новым агентом.

Проверка: Создайте два клиента с разными прокси. Сделайте запросы к тестовому сервису, отражающему IP и cookies. Убедитесь, что первый клиент видит один IP и свои cookies, второй - другой IP и свои. Пересечений быть не должно.

Шаг 4: Хранение состояния между запусками

Цель этапа: научиться сохранять cookies на диск и восстанавливать их при следующем запуске программы, учитывая срок жизни.

Часто скрипт нужно остановить и запустить позже, не теряя авторизацию. Для этого cookies нужно сериализовать - превратить в текст и сохранить в файл или базу.

Сериализация в Python

Объект CookieJar из requests можно сохранить несколькими способами. Самый переносимый - собрать cookies в простой словарь и записать в формат JSON.

  1. Пройдите по всем cookies объекта сессии через s точка cookies.
  2. Для каждой cookie соберите её имя, значение, домен, путь и срок годности.
  3. Сложите это в список словарей.
  4. Запишите список в файл в формате JSON.

При восстановлении делайте обратное: прочитайте файл, пройдите по списку и добавьте каждую cookie в новый объект сессии методом установки cookie с указанием домена и пути.

Совет: Храните вместе с cookies идентификатор прокси или хотя бы пометку, к какой логической сессии они относятся. Так вы не восстановите чужие cookies с неправильным IP и не нарушите правило соответствия.

Сериализация в Node.js

Библиотека tough-cookie имеет встроенный метод сериализации. У объекта jar есть асинхронный метод, который превращает всё хранилище в JSON-объект. Обратный метод восстанавливает jar из этого объекта.

  1. Вызовите метод сериализации хранилища и получите объект.
  2. Превратите объект в строку и сохраните в файл.
  3. При запуске прочитайте файл, разберите строку обратно в объект.
  4. Восстановите jar методом десериализации, передав объект.

Это удобнее, чем в Python, потому что tough-cookie сам хранит все нужные поля, включая срок годности и флаги безопасности.

Срок жизни cookies

У каждой cookie есть срок годности. Бывают сессионные cookies - они живут до закрытия браузера и не имеют явной даты. Бывают постоянные - с конкретной датой истечения. Сохранять на диск имеет смысл только постоянные cookies с ещё не истёкшим сроком. Сессионные cookies после перезапуска обычно уже недействительны на сервере.

  1. Перед сохранением проверьте дату истечения каждой cookie.
  2. Отбросьте те, что уже истекли.
  3. При восстановлении снова проверьте сроки и не загружайте протухшие.

Когда состояние проще выбросить

Не всегда стоит цепляться за сохранённые cookies. Иногда чистый старт быстрее и надёжнее.

  • Если прошло много времени с последнего запуска - сессия на сервере наверняка истекла, восстанавливать нечего.
  • Если сервер вернул ошибку авторизации при первом же запросе с восстановленными cookies - выбросьте их и авторизуйтесь заново.
  • Если вы не уверены в целостности файла состояния - лучше начать с чистого листа, чем отлаживать странное поведение.

⚠️ Внимание: Файлы с cookies и токенами содержат данные доступа. Храните их в защищённом месте, не выкладывайте в общий репозиторий, не отправляйте по незащищённым каналам. Утечка такого файла равна утечке доступа к аккаунту.

Проверка: Сохраните состояние, полностью закройте программу, запустите заново, восстановите состояние и сделайте запрос, требующий авторизации. Если сервер отвечает как авторизованному пользователю - сохранение работает. Если разлогинивает - проверьте сроки годности и правильность восстановления домена и пути.

Шаг 5: Разбор частых ошибок в архитектуре

Цель этапа: разобрать три главные ошибки подробно, чтобы вы узнали их в своём коде и не допустили.

Ошибка первая: общий CookieJar на все прокси

Это корень зла. Разработчик создаёт одно хранилище cookies и подставляет к нему разные прокси, думая сэкономить. Что происходит: cookies от сессии на первом IP попадают в запрос на втором IP. Сервер видит cookie, созданную под другим адресом, и либо сбрасывает сессию, либо считает поведение подозрительным.

Решение простое: каждому прокси - своё хранилище cookies. Никаких исключений. Мы уже заложили это в шагах с кодом: отдельный Session или отдельный client с отдельным jar на каждую логическую сессию.

Ошибка вторая: гонка при параллельных запросах

Гонка - это когда две операции обращаются к одним данным одновременно и мешают друг другу. Если два потока пишут в один CookieJar, одна запись может затереть другую. Результат: часть cookies теряется случайным образом, и баг воспроизводится через раз, что мучительно отлаживать.

  1. Дайте каждому потоку свою сессию через локальные данные потока, как мы описали.
  2. В асинхронном коде не расшаривайте один клиент между независимыми цепочками задач.
  3. Если по какой-то причине объект всё же общий, используйте блокировку, чтобы в один момент с ним работал только один поток.

Совет: Лучший способ избежать гонки - вообще не иметь общих изменяемых данных. Изоляция по логическим сессиям решает проблему в корне: если данные не общие, гонки быть не может.

Ошибка третья: потеря Set-Cookie при редиректах

Когда сервер отвечает перенаправлением, он часто в этом же ответе устанавливает важные cookies через заголовок Set-Cookie. Некоторые настройки клиента при автоматическом переходе по редиректу теряют эти cookies - они не попадают в хранилище.

  1. Убедитесь, что ваш клиент сохраняет cookies на каждом шаге цепочки редиректов, а не только на финальном ответе.
  2. В requests это работает по умолчанию при использовании объекта Session - cookies собираются по пути. Проверьте, что вы не отключили следование редиректам без нужды.
  3. В axios при ручной работе с cookies обрабатывайте Set-Cookie на каждом промежуточном ответе. Если используете обёртку, проверьте, что она перехватывает редиректы.

⚠️ Внимание: Если авторизация проходит, но следующий запрос разлогинивает, частая причина именно в потерянной при редиректе cookie. Включите логирование всех Set-Cookie заголовков и посмотрите, все ли ожидаемые cookies дошли до хранилища.

Проверка: Найдите на целевом сервисе действие, которое вызывает редирект, например вход через форму. Проследите цепочку и сравните cookies после каждого шага. Все выданные cookies должны оказаться в вашем хранилище. Если какая-то пропала - вы нашли утечку.

Шаг 6: Собираем всё вместе в рабочий процесс

Цель этапа: объединить изученное в единый предсказуемый рабочий процесс от старта до ротации.

Теперь у вас есть все детали. Соберём их в цепочку действий, которую можно повторять.

  1. Возьмите прокси из вашего пула и создайте под него изолированную логическую сессию - Session в Python или client в Node.js.
  2. Если есть сохранённое состояние для этой логической сессии и оно не протухло - восстановите cookies. Иначе авторизуйтесь заново.
  3. Выполняйте нужные запросы через объект этой сессии. Cookies накапливаются автоматически.
  4. Периодически сохраняйте состояние на диск, чтобы не потерять прогресс при сбое.
  5. Когда наступает время ротации IP, завершите логическую сессию корректно.
  6. Если сервис жёстко привязан к IP - начните новую логическую сессию с чистого листа на новом адресе.
  7. Если сервис терпим - создайте новый контейнер с новым прокси и перенесите в него cookies из старого.

Совет: Ведите журнал событий: когда создана сессия, с каким IP, когда произошла ротация, был ли разлогин. Такой журнал за пять минут покажет закономерность, которую иначе искали бы часами.

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

Проверка результата: финальный чек-лист

Пройдитесь по этому списку. Если все пункты выполнены, ваша система работает правильно.

  • У каждой логической сессии есть отдельный объект-контейнер со своим хранилищем cookies.
  • К каждому контейнеру привязан ровно один прокси на всё время жизни сессии.
  • Нет ни одного места, где cookies одной сессии могут попасть в другую.
  • В многопоточном коде каждый поток использует свою сессию через локальные данные потока.
  • В асинхронном коде каждая независимая цепочка имеет свой клиент.
  • Cookies корректно собираются на всех шагах редиректов.
  • Состояние сохраняется и восстанавливается между запусками, с учётом сроков годности.
  • При смене IP логическая сессия либо начинается заново, либо cookies переносятся осознанно.
  • Файлы с cookies и токенами хранятся защищённо.

Как протестировать

  1. Найдите тестовый сервис, который показывает ваш текущий IP и присланные cookies.
  2. Создайте две сессии с разными прокси и убедитесь в полной изоляции данных.
  3. Авторизуйтесь, сохраните состояние, перезапустите программу, восстановите - проверьте, что авторизация жива.
  4. Смоделируйте ротацию и проследите, как ведёт себя сессия.

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

Типичные ошибки и решения

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

Проблема: cookies разных сессий перемешиваются. Причина: общий CookieJar на несколько прокси. Решение: дать каждой логической сессии отдельное хранилище, никогда не расшаривать.

Проблема: баг проявляется через раз при параллельной работе. Причина: гонка при записи в общий объект из нескольких потоков. Решение: изолировать сессии по потокам через локальные данные потока или использовать блокировку.

Проблема: авторизация проходит, но сразу же слетает. Причина: потеря cookie при редиректе. Решение: проверить сбор cookies на всех шагах цепочки перенаправлений и включить логирование Set-Cookie.

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

Проблема: CSRF-токен постоянно недействителен. Причина: потеряна cookie сессии, к которой привязан токен. Решение: сначала восстановить целостность сессионных cookies, токен подтянется автоматически.

Проблема: JWT перестаёт работать после ротации. Причина: конкретный сервис привязал токен к IP на своей стороне. Решение: не менять IP в течение жизни токена либо получать новый токен на новом адресе.

Дополнительные возможности и оптимизация

Когда базовая схема работает, можно усилить её.

Пул готовых сессий

Вместо того чтобы создавать сессию каждый раз, держите пул заранее подготовленных и авторизованных логических сессий, каждая со своим прокси. Берите свободную сессию, используйте, возвращайте в пул. Это ускоряет работу, потому что авторизация не повторяется без нужды.

Автоматическая проверка живости

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

Совет: Проверку живости делайте не перед каждым запросом, а по расписанию или после долгих пауз. Слишком частые проверки создают лишнюю нагрузку и не приносят пользы.

Централизованное хранилище состояний

Для крупных проектов вместо файлов используйте базу данных как хранилище cookies. Ключ - идентификатор логической сессии, значение - сериализованное состояние. Это удобнее масштабировать и безопаснее хранить.

Метрики и наблюдаемость

Считайте, сколько раз происходит разлогин, сколько сессий пришлось пересоздать, как часто восстановление проходит успешно. Эти цифры показывают здоровье вашей системы и подсказывают, где что-то настроено неоптимально.

FAQ: частые вопросы

Обязательно ли создавать новый объект сессии при каждой смене IP? Если сервис жёстко проверяет адрес - да, потому что старая сессия на новом IP всё равно не примется. Если сервис терпим - можно перенести cookies в новый контейнер с новым прокси и продолжить.

Можно ли использовать один прокси для нескольких логических сессий? С точки зрения кода можно, но каждая логическая сессия всё равно должна иметь своё отдельное хранилище cookies. Общими могут быть только настройки подключения, но не состояние.

Почему нельзя просто хранить все cookies в одном месте и фильтровать по домену? Потому что проблема не в домене, а в привязке к конкретной логической сессии и IP. Cookies одной сессии на одном домене не должны попадать в другую сессию на том же домене.

Как понять, привязывает ли сервис сессию к IP? Проведите эксперимент: авторизуйтесь на одном IP, смените адрес и сделайте запрос. Если разлогинило - вероятно, привязка есть. Верните старый IP: если восстановилось, значит, сервер помнит первый адрес.

Что делать с сессионными cookies при сохранении на диск? Их обычно не имеет смысла сохранять, потому что сервер считает их недействительными после разрыва соединения. Сохраняйте постоянные cookies с действующим сроком.

Как быть, если библиотека сама не сохраняет cookies при редиректе? Обрабатывайте заголовок Set-Cookie вручную на каждом промежуточном ответе цепочки перенаправлений и складывайте cookies в своё хранилище.

Нужна ли блокировка, если у каждого потока своя сессия? Нет. Если данные не общие, гонки быть не может, и блокировка не нужна. Блокировка требуется только при вынужденном совместном доступе к одному объекту.

Как долго можно хранить восстанавливаемое состояние? Ровно до тех пор, пока сервер считает сессию живой. Точный срок зависит от сервиса. Практичнее проверять живость запросом, чем гадать по времени.

Что важнее - сохранить cookies или сохранить токен? Зависит от механизма авторизации сервиса. Иногда достаточно токена, иногда нужен полный набор cookies. Безопаснее сохранять всё состояние целиком, тогда вы не упустите нужное.

Можно ли переносить cookies между Python и Node.js? Да, если сохранять их в общем нейтральном формате вроде JSON с полями имени, значения, домена, пути и срока. Тогда любая из систем сможет их прочитать.

Заключение

Давайте подведём итог тому, что вы прошли. Вы разобрались, что после смены IP разлогинивает не из-за самого факта смены, а из-за серверных проверок и ошибок в вашей архитектуре. Вы узнали, что cookies, CSRF, JWT сами по себе к адресу не привязаны, а привязку добавляет конкретный сервис. Вы усвоили главное правило: одна логическая сессия равна одному набору cookies равна одному IP.

Затем вы написали рабочий код. На Python - через отдельный объект Session с собственным CookieJar на каждый прокси и изоляцию по потокам. На Node.js - через связку axios, tough-cookie и агента прокси с отдельным клиентом на каждую логическую сессию. Вы научились сохранять состояние между запусками, учитывать сроки годности cookies и понимать, когда состояние проще выбросить.

Вы разобрали три коварные ошибки: общий CookieJar, гонку при параллельной работе и потерю Set-Cookie при редиректах. И теперь у вас есть чек-лист перед продом, который не даст выпустить сырое решение.

Что делать дальше

Начните с малого. Возьмите один реальный сценарий, реализуйте для него изолированную логическую сессию и убедитесь, что состояние не теряется. Потом добавьте сохранение на диск. Потом масштабируйте на несколько сессий. Двигайтесь по одному шагу, проверяя результат на каждом.

Куда развиваться

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