Русский
English
Прокси с ротацией на каждый запрос — это схема, при которой каждое обращение к сайту уходит с нового IP-адреса. Её ищут под парсинг, мониторинг цен и массовые проверки выдачи, где сотни запросов с одного адреса быстро упираются в капчу и ограничения. В 2026 году у мобильных прокси такая ротация привязана не к самому запросу, а к соединению, и от того, как программа открывает соединения, зависит, получит ли каждый запрос свой адрес.
Запрос, соединение и сессия: в чём разница
Три слова часто путают, хотя ротация работает только с одним из них:
- запрос — одно обращение к сайту: загрузка страницы, картинки, вызов API;
- соединение — подключение программы к прокси, по которому может пройти и один запрос, и несколько десятков подряд;
- сессия — серия запросов, которую сайт связывает между собой через cookies или токен авторизации.
Прокси видит соединения, а не запросы. Когда программа открывает сайт по HTTPS, прокси строит туннель до сайта и передаёт зашифрованные данные, не заглядывая внутрь, — сколько запросов прошло по туннелю, он не знает. Поэтому «новый IP на каждый запрос» на практике означает «новый IP на каждое новое соединение».
Современные программы стараются соединения беречь. Режим keep-alive оставляет подключение открытым после ответа, чтобы отправить по нему следующий запрос, а HTTP/2 вообще пропускает десятки запросов через одно соединение одновременно. Отсюда частая жалоба: ротация вроде бы включена, а запросы подряд приходят с одного адреса.
Как получить новый IP на каждый запрос
Для этого нужны две вещи: прокси, который выдаёт адрес на соединение, и программа, которая открывает соединение под каждый запрос.
У LTESpace адрес на соединение выдаёт тариф «Мультипорт»: вход один, а каждое новое подключение выходит через другой IP из мобильного пула оператора. Пока соединение открыто, адрес не меняется; закрыли и открыли заново — получили следующий.
Со стороны программы есть несколько способов не переиспользовать соединения:
- отключить keep-alive или повторное использование соединений в настройках парсера;
- отправлять заголовок
Connection: close, после которого соединение закрывается сразу после ответа; - в своём коде создавать новый HTTP-клиент на каждый запрос вместо общего клиента или сессии;
- для HTTP/2 ограничить программу одним запросом на соединение или перейти на HTTP/1.1.
Проверить схему проще всего утилитой curl: каждый её запуск открывает новое соединение. Если вывести внешний адрес три раза подряд, на мультипорте получатся три разных IP:
for i in 1 2 3; do curl -s -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://api.ipify.org; echo; doneЛогин, пароль, хост и порт берутся из панели управления после покупки.
Почему в браузере так не получится
Браузер — худший клиент для ротации на каждый запрос. Одну страницу он загружает через несколько соединений параллельно, и её текст, картинки и скрипты пришли бы с разных адресов. Сайт увидел бы одного посетителя, который за секунду побывал в разных точках сети. А после входа в аккаунт каждый следующий клик шёл бы с нового IP, и авторизация слетала бы постоянно.
Поэтому мультипорт не предназначен для работы в браузере. Для браузерных профилей и антидетекта нужен стабильный адрес на всю сессию: приватный канал со сменой IP по ссылке или API либо общий канал с ротацией по таймеру.
Когда ротация на каждый запрос полезна
- сбор данных, где каждая страница независима: карточки товаров, объявления, листинги каталога, см. прокси для парсинга;
- мониторинг цен и наличия у многих продавцов по расписанию;
- массовые проверки выдачи и рекламы, где каждый запрос — отдельная проверка;
- опрос открытых API, которые ограничивают число обращений с одного адреса;
- параллельная работа в десятки потоков, где нагрузку нужно размазать по пулу, а не сосредоточить на одном IP.
Когда она мешает
Смена адреса на каждом запросе ломает всё, что сайт связывает в сессию:
- вход в аккаунт и любые действия после него;
- корзина, оформление заказа, многошаговые формы;
- постраничный просмотр, где следующая страница зависит от cookies предыдущей;
- капча: решили её на одном адресе, а следующий запрос пришёл уже с другого;
- сайты, которые привязывают токен сессии к IP и сбрасывают его при смене адреса.
Признаки неверного выбора — повторные запросы на вход, сброшенные корзины, капча по кругу. Если они появились, адрес нужно держать дольше, а не менять чаще.
Что выбрать вместо ротации на каждый запрос
Если задаче нужен один адрес на серию запросов, есть три способа:
- держать соединение открытым — на мультипорте адрес закреплён за соединением, и серия запросов по одному keep-alive-соединению идёт с одного IP;
- ротация по таймеру — общий канал меняет адрес раз в 2 или 5 минут, общий без ожидания и мультирегион — раз в 2 минуты;
- смена по ссылке или API — на приватном канале адрес меняется только тогда, когда это нужно вам или вашему скрипту; таймер можно выставить от 1 до 60 минут или не включать вовсе.
Как подобрать интервал под задачу, подробно разобрано в руководстве мобильные прокси с ротацией. Для ботов и скриптов, которые сами решают, когда менять адрес, полезно руководство мобильные прокси для ботов.
Ротация на каждый запрос у серверных и мобильных прокси
Серверные IPv4-прокси тоже предлагают смену адреса на каждое соединение, и стоит она дешевле. Разница в том, откуда берутся адреса: у серверных — из подсетей дата-центра, которые площадки легко распознают и закрывают целыми диапазонами, у мобильных — из пула оператора, где за тем же адресом сидят обычные абоненты. Подробное сравнение — в статье IPv4-прокси с ротацией или мобильные.
Потоки и лимиты в мультипорте
Число потоков в мультипорте выбирают при покупке, до 50 параллельных соединений. Если программа откроет больше соединений, чем куплено потоков, лишние получат отказ, поэтому число потоков в парсере стоит выставить не выше купленного. Цена считается за поток: 670 ₽ в месяц или 134 ₽ за сутки, трафик не ограничен. Подключение — по HTTP или SOCKS5, разница между ними описана в руководстве HTTP, HTTPS и SOCKS-прокси.
Выбрать число потоков и посмотреть итоговую цену можно в тарифах LTESpace.
Итоги
Прокси с ротацией на каждый запрос у мобильных прокси работают через соединения: новый IP получает каждое новое подключение, а не каждое обращение внутри него. Чтобы адрес менялся на каждом запросе, программа должна открывать под него отдельное соединение — без keep-alive и общего клиента. Такая схема хороша для парсинга и проверок, где каждая страница независима, и вредна везде, где есть вход в аккаунт, корзина или капча: там нужен стабильный адрес на сессию.
