Команда Proxyca · 28.11.2025 · Обновлено 31.10.2026
Ротируемый прокси автоматически меняет ваш выходной IP — при каждом запросе или через заданный интервал. Sticky-сессия стремится сохранять один и тот же IP на протяжении нескольких запросов, например чтобы cookie оставались привязанными к одному адресу. Ни то, ни другое поведение не определено в HTTP или SOCKS5, поэтому работа ротации и сессий зависит от вашего провайдера и должна быть подтверждена у него.
В этом руководстве объясняется разница, перечисляются распространённые подходы к ротации, отделяются факты о протоколах от функций провайдеров и приводится контрольный список вопросов, которые стоит задать перед покупкой. Оно не обещает, что ротация предотвращает блокировки, капчи или баны.
Выходной IP — это адрес, который видит целевой ресурс при соединении через прокси. Шлюз может выбирать адрес из пула, но адрес шлюза, который вы вводите в приложении, и выходной IP — не обязательно одно и то же. При проверке конфигурации записывайте оба.
«Ротация» — это описание продукта, а не полная конфигурация. Уточните, когда происходит выбор: при открытии соединения, при выполнении запроса или через определённый интервал. Не делайте выводов об ответе только по имени хоста или порту.
Эти две идеи тянут в противоположных направлениях:
Смена IP сама по себе не удаляет cookie браузера. Однако сервис может отреагировать на смену сетевого адреса во время авторизованного сеанса. Поддерживайте согласованность состояния браузера и конфигурации прокси при тестировании собственного аккаунта или приложения.
Выбирайте стабильную сессию, когда важна непрерывность, и уточните, что произойдёт, если её выходной узел станет недоступен. Для независимых проверок локации могут подойти отдельные запросы, но правила доступа и лимиты запросов целевого ресурса всё равно действуют.
Если вы всё ещё выбираете между типами прокси, Датацентр-прокси и резидентские прокси: в чём разница? описывает это сравнение отдельно.
Это шаблоны конфигурации, о которых стоит спрашивать, а не список функций, входящих в каждый тариф.
| Подход | Общая идея | Что спросить у провайдера |
|---|---|---|
| Единый адрес подключения | Один адрес, который возвращает новый IP при каждом запросе | Это значение по умолчанию, и можно ли его изменить? |
| Разделите порты | Разные порты для геозон или сессий | За что отвечает каждый порт? |
| Ручная смена | Смена IP через панель или бота | Доступно ли это для вашего тарифа? |
| Обработка сбоев | Сообщение о недоступном выходе или неудачном запросе | Какая ошибка возвращается и сохраняется ли исходная сессия? |
| Задержка или ограничение запросов | Ротация по истечении времени или по количеству запросов на один IP | Что из этого существует и как это настраивается? |
Чтобы узнать, какое поведение относится к конкретному продукту, изучите документацию провайдера или обратитесь в поддержку.
Это помогает отделить поведение протокола от поведения провайдера.
HTTP. RFC 9110 описывает HTTP как протокол без сохранения состояния: смысл каждого запроса можно понять изолированно. Многие реализации опираются на это, чтобы повторно использовать проксированные соединения или распределять запросы между серверами. Повторное использование соединения с прокси — это поведение клиента и прокси, а не то, что предписывает протокол.
Туннели CONNECT. В том же RFC туннель описан как «слепая» передача между двумя соединениями, которая не изменяет сообщения. Если посредник обнаруживает, что одна из сторон закрыла своё соединение, он закрывает оба. Любой ответ не из диапазона 2xx на запрос CONNECT означает, что туннель не был создан. Аутентификацию на прокси можно использовать для подтверждения полномочий на создание туннеля.
SOCKS5. RFC 1928 говорится, что после успешного TCP-соединения с SOCKS-сервером клиент согласовывает метод аутентификации, проходит аутентификацию и затем отправляет запрос на ретрансляцию. Сервер либо устанавливает соединение, либо отклоняет его. Имя пользователя/пароль — один из определённых методов, и RFC 1929 отмечает, что при этом субсогласовании пароль передаётся открытым текстом, поэтому оно не рекомендуется там, где перехват трафика практичен.
Ни один из этих документов не определяет ротацию IP или sticky-сессии. Оба механизма — это поведение шлюза на стороне провайдера. Поэтому один и тот же протокол может вести себя по-разному у разных провайдеров, и не стоит считать, что функция, доступная по одному протоколу, доступна и по другому. Подробнее о самих протоколах см. SOCKS4 и SOCKS5: сравнение аутентификации, DNS и UDP.
На уровне протокола с уверенностью можно сказать только одно: туннель или соединение завершается, когда закрывается его соединение. Закрыть его может ваш клиент, прокси или целевой сервер.
Сохраняет ли провайдер ваш выходной IP после закрытия соединения — это отдельный вопрос, и ответ содержится в правилах шлюза провайдера. Возможные причины сброса включают таймер, количество запросов, ответ с ошибкой или ручную смену. Какие из них применяются, если применяются вообще, нужно уточнять у провайдера, а не предполагать. Если ваш рабочий процесс зависит от того, что один IP остаётся неизменным, спросите об этом до того, как выстраивать на этом работу.
Резидентский трафик и IP-адреса датацентров имеют разные единицы покупки. Резидентский трафик начинается от 8 $ за 1 ГБ; 5 $ за ГБ применяется к пакету на 250 ГБ стоимостью 1 250 $. IP-адрес датацентр-прокси стоит 2,50 $ за 30 дней. Эти цены не устанавливают интервал ротации и не гарантируют закрепленные сессии (sticky-сессии).
Выберите продукт и локацию в Telegram, затем проверьте выданные параметры подключения. Прежде чем строить рабочий процесс, уточните в поддержке, какие возможности управления сессиями есть у именно этого продукта. Одно лишь название протокола не говорит о том, останется ли выходной адрес неизменным.
Каким бы провайдером вы ни пользовались, получите письменные или документированные ответы на эти вопросы:
Когда у вас будут ответы, проверьте работу в собственном клиенте. Как проверить прокси: воспроизводимые тесты подключения, авторизации, IP, DNS и протоколов описывает повторяемые проверки, с помощью которых можно выяснить, какой IP-адрес реально используют ваши запросы.
Нет. Ротация автоматически меняет выходной IP, а sticky-сессия старается сохранять один IP при нескольких запросах. Некоторые провайдеры предлагают оба режима, но это нужно подтвердить для конкретного продукта.
Нет. RFC 9110 и RFC 1928/1929 не определяют ротацию IP или sticky-сессии. Это особенности шлюза на стороне провайдера, а их поддержка зависит от настройки провайдера и используемого вами протокола.
Ненадёжно, и это руководство не даёт такого обещания. Сайты могут реагировать на множество факторов помимо IP-адреса. Если вы получаете ошибки или капчи, сначала проверьте частоту своих запросов и правила сайта.
На уровне протокола туннель завершается, когда закрывается его соединение. Что провайдер делает с вашим выходным IP после этого — вопрос к провайдеру.
Прежде чем выбирать тариф, возьмите приведённый выше чек-лист к своему провайдеру и получите чёткие ответы о сессиях, сбросах и ротации по умолчанию. Открыть Proxyca в Telegram
Статическая адрес подключения и политика ротации выходного адреса описывают разные части подключения. Имя хоста может оставаться прежним, а сервис при этом меняет выходной адрес за ним. И наоборот, клиент может держать сессию открытой, не получая постоянного права на конкретный выходной IP. Уточняйте правила выделения и сессий для конкретного продукта, а не делайте выводы по строке адреса подключения.
| Вопрос | Статическое выделение | Ротационное выделение |
|---|---|---|
| Что нужно подтвердить? | Какой IP назначен и на какой срок | Что вызывает смену и как выбирается сессия |
| Что должен записывать клиент? | Выданная адрес подключения и наблюдаемый выходной адрес | Конечная точка, настройка сессии и наблюдаемый выходной узел для соответствующего запроса |
| Определяет ли метка оплату? | Нет: проверьте единицу покупки и срок продукта | Нет: проверьте объём трафика или другую указанную единицу |
| Гарантирует ли это доступ к целевому ресурсу? | Нет | Нет |
Для разрешённой задачи, которая зависит от стабильного подключения, сначала выясните, что продукт гарантирует в отношении назначения адреса. Для задачи, требующей отдельных наблюдений за подключением, фиксируйте, когда было сделано каждое наблюдение. Не предполагайте, что одно и то же имя пользователя создаёт одну и ту же сессию в каждом клиенте или продукте. Держите синтаксис сессий провайдера отдельно от настройки протокола HTTP или SOCKS.
Запишите время, метку адреса подключения без секретных данных, настроенный параметр сессии и наблюдаемый выходной IP для небольшого разрешённого запроса. Повторяйте только по необходимости для вашей задачи. Наблюдение относится к этому запросу и не доказывает постоянного закрепления или универсального интервала смены. Наш Проверка прокси помогает подготовить команду локального подключения; the руководство по проверке описывает последовательность диагностики.
Сравнить актуальные тарифы и единицы покупки, затем откройте бота, выберите тариф, выберите доступную страну и используйте выданные настройки. Ротация не даёт права игнорировать правила доступа или лимиты запросов целевого ресурса.