Как работают мобильные прокси: ротация IP и сессии

Как работают мобильные прокси: ротация IP и сессии

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

01Адрес сменился, а сайт вас помнит#

Типичная картинка. Вы подключили браузер через мобильные прокси, открыли страницу «какой у меня IP», записали адрес.

Нажали ссылку смены IP, обновили страницу, и адрес стал другим, иногда даже с другим городом в геобазе. Переходите в личный кабинет интернет-магазина, а там вы всё ещё авторизованы, корзина на месте, рекомендации те же.

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

Чтобы перестать путаться, полезно разобрать, из чего собран мобильный выход и что именно меняет ротация.

02Из чего собран мобильный выход#

Мобильный прокси передаёт запросы через выход в сотовой сети. В типичном варианте клиент подключается к шлюзу, а дальше трафик идёт через модем с SIM-картой или другое устройство с мобильным подключением. Конкретная реализация у разных сервисов различается. Клиент (браузер, скрипт, приложение) соединяется со шлюзом по HTTP(S) или SOCKS5, шлюз переправляет трафик в модем, модем отдаёт его оператору, а оператор выпускает пакеты в интернет уже со своим адресом.

Отсюда первое разграничение, которое часто теряется.

Слово «мобильный» описывает выходную сеть, то есть откуда сайт видит ваше соединение. Слова HTTP и SOCKS5 описывают протокол, по которому вы разговариваете со шлюзом. Это независимые вещи. Один и тот же мобильный выход может быть доступен по HTTP и SOCKS5; адрес, порт и способ авторизации нужно брать из настроек конкретного подключения. Протокол подключения ничего не говорит о типе выхода, а тип выхода не определяет протокол. Различие важно и практически. SOCKS5 работает на уровне TCP-соединений и может проксировать не только веб, а HTTP-прокси понимает структуру запросов, умеет CONNECT для HTTPS, но в чистом виде ориентирован на веб-трафик.

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

03Почему IP может быть общим#

Адрес, который видит сайт, не обязательно закреплён только за вашим устройством.

Чтобы распределять публичные IPv4-адреса между абонентами, оператор может использовать CGN (carrier-grade NAT), то есть операторскую трансляцию адресов. Тогда внутренний адрес абонента и публичный адрес, видимый сайту, различаются; один публичный адрес может обслуживать несколько абонентов. Для этого внутреннего слоя в RFC 6598 выделен отдельный блок 100.64.0.0/10, который не маршрутизируется в интернете, поэтому сайты его не видят. Здесь нужны две оговорки. Во-первых, схему NAT каждый оператор строит по-своему, и размер пулов, привязка абонентов к адресам и время жизни трансляций различаются, так что единой схемы для всех мобильных операторов не существует. Во-вторых, из факта общего адреса не следует ни уникальность, ни анонимность.

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

Из этого же следует, что геобаза и ASN остаются косвенными признаками. Они показывают, какому оператору и примерно какому региону принадлежит диапазон, но не доказывают, что модем стоит в конкретном городе, и ничего не говорят о качестве адреса. Репутацию конкретного IP проверяют отдельно, например по чёрным спискам DNSBL.

04Три разных «сессии»#

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

1. Сессия мобильного канала, или выходной IP. Это промежуток времени, в течение которого модем держит один и тот же публичный адрес. Он заканчивается по вашей команде (ротация), по таймеру шлюза или без вашего участия, когда оператор пересобрал трансляцию, модем переподключился к сети; сам по себе переход между базовыми станциями не обязательно меняет публичный IP. С этим уровнем связано понятие sticky session: шлюз старается сохранять выбранный выход для запросов с одним идентификатором сессии в течение согласованного окна. Это не то же самое, что сеанс мобильного подключения или авторизация на сайте. Важно понимать, чьё это обещание. Sticky остаётся условием конкретного сервиса, который просто не инициирует смену сам. Оператор никаких гарантий на этот счёт не даёт, и принудительная смена адреса со стороны сети остаётся возможной в любой момент. Сколько адрес продержится без команды, зависит от конкретной сети и конкретного дня, константы здесь нет.

2. Сессия соединения, то есть TCP и HTTP. По RFC 9293 TCP-соединение определяется парой сокетов, адресом и портом на каждой стороне. Если уже открытое соединение теряет прежний адрес или NAT-сопоставление, оно может оборваться либо зависнуть до таймаута. Но шлюз способен применить ротацию только к новым соединениям, сохранив старый маршрут для уже открытых: поведение нужно проверять отдельно.

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

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

Теперь исходная ситуация объясняется без магии, ведь ротация затронула уровень 1, возможно, оборвала что-то на уровне 2, а уровень 3 остался нетронутым, потому что cookie лежит в браузере и отправляется как прежде.

Концептуальная схема, не результат измерений

05Что происходит при ротации#

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

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

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

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

Интервал таймера остаётся вашим параметром, а не свойством сети.

Отдельно про DNS и IPv6. Если клиент резолвит имена локально, а через прокси отправляет только TCP, сайт видит мобильный адрес, но DNS-запросы уходят с вашего домашнего адреса, и с IPv6 похожая история, потому что часть клиентов и систем предпочитает IPv6-маршрут мимо прокси, если он доступен.

Обе утечки не зависят от ротации и проверяются отдельно.

06Где мобильная сеть полезна, а где важнее стабильность#

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

Проверка собственного сайта глазами мобильного абонента. С такого выхода удобно проверять региональное отображение, геотаргетинг и поведение CDN на собственных площадках. При этом мобильный IP сам по себе не превращает настольный браузер в телефон: адаптивную вёрстку, User-Agent и поведение устройства тестируют отдельно.

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

Отладка логики авторизации на своей стороне. Полезно увидеть, что ваш сайт делает при смене IP внутри сессии, то есть ничего, предупреждение или запрос повторного входа. Это тест собственной серверной логики, а не чужой.

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

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

07Что меняется и что не меняется при ротации#

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

08Чек-лист перед арендой#

Перед тем как арендовать мобильные прокси, проверять их лучше на реальном клиенте и на собственном сайте или тестовом стенде, куда вы имеете право подключаться. Коротко по пунктам.

1. Тип выходной сети. Убедитесь, что адрес действительно принадлежит мобильному оператору, а не датацентру с мобильной вывеской. Запрос к странице определения IP и просмотр ASN дают минимальную проверку, но помните, что это косвенный признак.
2. Режим ротации. По таймеру, по ссылке или API, можно ли отключить таймер совсем. Проверьте, что команда действительно меняет адрес, и сколько секунд это занимает именно у вас.
3. Сохранение адреса в пределах операции. Выполните длинную операцию, например загрузку файла или серию запросов, и посмотрите, доживает ли адрес до её конца без команды. Повторите несколько раз, потому что единичный результат ничего не доказывает.
4. Завершение старых соединений. Откройте долгое соединение, смените IP и зафиксируйте, что произошло, будь то обрыв сразу, зависание до таймаута или продолжение со старого адреса. Любой вариант допустим, но его надо знать заранее.
5. Задержки и обрывы. Первичную доступность и тип анонимности покажет проверка прокси, но время ответа и долю неудачных запросов измеряйте на своём трафике в то время суток, когда планируете работать. Чужие цифры здесь не помогут.
6. DNS и IPv6 в реальном клиенте. Проверьте, через что уходят DNS-запросы и не обходит ли прокси IPv6-маршрут. Делайте это тем браузером или библиотекой, которые будете использовать, а не отдельной утилитой.
7. Лимиты, трафик и протоколы. Ограничения по трафику, числу одновременных соединений, частоте смен, поддержка HTTP и SOCKS5, UDP при необходимости.
8. Правила использования. Что разрешено условиями сервиса и законодательством вашей юрисдикции, какие действия приведут к блокировке аккаунта у провайдера. Тестирование чужих ресурсов без разрешения в этот список не входит.

Пройти этот чек-лист можно на любом сервисе из каталога мобильных прокси. Например, у mobileproxy.space есть все три режима из статьи: смена IP по ссылке или API, автоматическая ротация раз в N минут и режим без ротации, а порт отдаётся по HTTP и SOCKS5:

mobileproxy.space — мобильные и резидентские прокси4.8115

Мобильные прокси с реальными SIM по странам и операторам, резидентский трафик пакетами GB, серверные и backconnect-прокси. Оплата картами, СБП и криптовалютой.

176 странПромокод

5,90 $

day

На сайт

09Что стоит проверить в первую очередь#

Ротация IP меняет точку выхода в интернет, и только её.

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

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

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

10Частые вопросы#