Смена IP и веб-сессия: что меняется, а что остаётся

HTTP сам по себе не хранит состояние, но cookies позволяют серверу связать последовательные запросы. Их область и срок определяются отдельными атрибутами.

Составьте четыре теста: тот же IP и те же cookies, новый IP и те же cookies, тот же IP и чистый контекст, новый IP и чистый контекст. Сравнивайте не только вход, но и корзину, CSRF-защиту и серверный идентификатор сессии. Такая матрица показывает, какой именно сигнал влияет на поведение приложения.

Меняется исходящий сетевой адрес нового соединения. Уже открытое соединение может завершиться, поэтому приложение должно корректно восстановиться и подтвердить новый адрес.

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

Сначала измерьте адрес до ротации, выполните разрешённую смену, дождитесь подтверждения и повторите проверку в том же контексте. Отдельно повторите сценарий в чистом контексте.

Postcheck выполняйте через новый TCP-сеанс и минимум две разрешённые контрольные цели. Подтвердите, что адрес действительно изменился, прежний адрес больше не используется текущим соединением, а реквизиты доступа остались согласованными. Если ответ неоднозначен, сохраняйте статус «проверяется», а не объявляйте успех.

Не запускайте платную или изменяющую состояние операцию повторно только из-за сетевого таймаута. Сначала проверьте фактический результат на стороне сервиса.

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