Прокси обычно покупают по модели широкого пула с оплатой за гигабайт, и эта модель ломается, как только трафик становится большим, а одновременных регионов нужно мало. Разбираю механику смены гео на безлимитном мобильном порту, вывожу формулу точки безубыточности и показываю четыре задачи, где переключение гео на одном порту дешевле резидентных и мобильных прокси с оплатой по трафику. Цифр по ценам и объёмам в статье нет сознательно, вместо них переменные, которые вы подставите из своих логов.
Зачем считать гео отдельно от трафика
Привычная модель покупки прокси устроена просто. Вы платите за ширину пула, то есть за десятки стран и сотни городов в одном аккаунте, и за каждый гигабайт, который через этот пул прошёл. Провайдеру это удобно, потому что он продаёт доступ к чужим устройствам и его расходы растут вместе с объёмом. Вам это удобно ровно до тех пор, пока трафика мало. Потом счёт начинает расти быстрее, чем польза от задачи. И в этот момент выясняется, что широкий пул использовался лишь частично.
Почти никто не считает, сколько гигабайт у него уходит за цикл задачи. Люди считают запросы, аккаунты и страницы. Потом приходит счёт за трафик, и оказывается, что карточка маркетплейса с подгружаемыми блоками весит совсем не столько, сколько ответ JSON из API. В этой статье я разбираю задачи, в которых регионов нужно много, а одновременных регионов мало. Для них безлимитный мобильный порт с переключением гео получается дешевле моделей с оплатой за гигабайт. Покажу на формуле, где именно проходит граница.
Сразу об ограничениях текста. У меня нет замеров трафика по сценариям и нет сводки цен конкурентов на сегодняшнюю дату. Поэтому я не буду называть цифры ни по стоимости, ни по объёмам. Вместо этого будет формула с переменными, которые вы подставите сами из своих логов и из актуальных прайсов. Из фактов о нашей инфраструктуре здесь только механика смены IP на порту (по таймеру или по ссылке через API, по данным на 22.09.2026). Всё остальное описывает, как такие системы устроены в принципе. Отчётом об эксперименте это не является.
Чем смена гео отличается от смены IP
Начну с терминов, потому что их постоянно путают. Смена IP на порту это переключение адреса внутри одного оператора и одного региона. Модем сбрасывает сессию, оператор выдаёт новый адрес из того же пула, а город и ASN остаются прежними. У нас это делается двумя способами, по таймеру или дёрганьем ссылки через API. Это тот единственный факт из данных, который я могу подтвердить. Всё остальное в разделе описывает механику.
Смена гео устроена иначе. Порт остаётся тем же (тот же хост, тот же логин и пароль в конфиге вашего воркера), но за ним оказывается оборудование в другом городе, и вместе с городом меняются оператор или его региональный пул, геолокация адреса в базах и, если сменился оператор, ASN.
Для клиентского кода не меняется ничего, для целевого сайта меняется то, что он определяет по адресу.
Теперь о том, что при смене гео не меняется. Один порт в каждый момент времени смотрит в один регион. Если нужно одновременно сидеть в двадцати городах, нужно двадцать портов, и тут никакой магии. Не меняется и всё, что живёт на стороне устройства: GPS и геолокация самого устройства, язык системы, профиль и история, физический тип подключения. Прокси меняет только выходной адрес. Что меняется, кроме адреса. Задержка до целевого сайта, потому что другая точка выхода. Поведение DNS, если резолвите через прокси. Языковые заголовки задаёт клиент: сама смена прокси их не меняет. Сервер при этом может выбрать другой язык ответа по IP.
Честно скажу, чего я не знаю точно. Я не замерял, сколько секунд проходит от команды на смену гео до первого ответа из нового региона, распределения по этому параметру у меня нет. Не буду утверждать и про число доступных регионов на одном порту, эта цифра зависит от тарифа, а в данных для статьи её нет. Для расчётов ниже это несущественно. Там всё упирается в трафик и в число одновременно занятых портов. Если эти цифры нужны вам под конкретную задачу, запросите их у провайдера перед покупкой.
Три способа платить и одна формула
Рынок предлагает три модели оплаты, и сравнивать их имеет смысл только на одной и той же задаче.
• Резидентные прокси с оплатой за гигабайт. Широкая география, адреса домашних провайдеров, счёт растёт с объёмом.
• Мобильные прокси с оплатой за гигабайт. Адреса сотовых операторов, география уже зависит от провайдера, цена гигабайта, как правило, выше резидентных.
• Безлимитный мобильный порт с переключением гео. Фиксированная месячная цена за порт, трафик не считается, в один момент времени один регион.
Введём переменные, с которыми будем работать до конца статьи. T это трафик за один цикл задачи в гигабайтах, N это число циклов в месяц, V = T × N это месячный объём в гигабайтах, P_gb это цена гигабайта в выбранной модели (P_res для резидентных, P_mob для мобильных по трафику), C_port это месячная стоимость одного безлимитного порта, G это число регионов, которые нужно обойти за цикл, а K это число портов, занятых одновременно. K растёт в двух случаях: когда в разных регионах нужно быть в один момент времени или когда одну задачу распараллеливают на несколько воркеров ради скорости. Последовательный обход регионов на K не влияет.
C_cycle (за ГБ) = T × P_gbC_month (за ГБ) = V × P_gb = T × N × P_gbC_month (порты) = C_port × KПорог по объёму V* = C_port × K / P_gb (в месяц)Точка безубыточности по трафику считается в одну строку. Если V × P_gb больше, чем C_port × K, порт выгоднее. Переставляем и получаем пороговый месячный объём V* = C_port × K / P_gb. Ниже порога платите за гигабайты. Выше порога берёте порты. Сравнивайте именно месячный V, а не трафик за один цикл T. Числа подставьте свои, я их не называю сознательно, потому что в моих данных их нет, а брать с потолка не хочу.
Обратите внимание, что G в стоимость порта не входит вообще.
Это и есть главная мысль статьи. У моделей с оплатой за гигабайт число регионов бесплатно, а трафик дорог, и каждый добавленный в цикл регион добавляет трафик в V. У безлимитного порта с переключением гео трафик бесплатен, а дорого число одновременно занятых портов. Задача с большим G, маленьким K и большим V попадает в зону выгоды порта. Задача с большим K или маленьким V туда не попадает. Четыре сценария ниже подобраны ровно по этому признаку.
Одно уточнение про скрытые переменные: если у провайдера есть лимит на число переключений гео в месяц или доплата за каждое переключение, к стоимости порта добавляется слагаемое G × N × P_switch, а произведение G × N надо сравнить с лимитом. Доступность регионов и условия переключения зависят от тарифа. В данных для статьи этих параметров нет, поэтому я оставляю их переменными, и это надо проверить в своём тарифе до того, как закладывать расчёт в бюджет.
Сценарий 1. Региональный мониторинг цен
Маркетплейс или сеть ритейла показывает разные цены и остатки в зависимости от региона, а вам нужен ежедневный срез по десяткам городов. Классическая задача аналитиков e-commerce и ценовых агрегаторов.
Профиль нагрузки такой. Страницы тяжёлые, потому что даже с отрезанными картинками карточка тянет кучу скриптов, а список выдачи ещё и подгружает блоки по скроллу. Городов много, G измеряется десятками. Одновременно в них быть не нужно, цикл проходится последовательно за ночь. Поэтому K здесь это не число регионов, а число параллельных воркеров, которые вы готовы оплатить ради скорости, обычно это единицы. N равен числу дней в месяце.
В коде это один воркер на порт, цикл по списку регионов, перед каждым регионом команда на переключение гео, ожидание подтверждения региона, прогон списка товаров и запись в базу. Скелет ниже на Python. Эндпоинт переключения и формат ответа сервиса проверки гео в нём условные, потому что у каждого провайдера они свои, считайте это псевдокодом с рабочей логикой ожидания.
import time, requests, ipaddressPROXY = {'https': PROXY_URL} # один порт, конфиг не меняетсяdef switch_geo(region): r = requests.get(SWITCH_URL, params={'region': region}, timeout=15) # эндпоинт условный r.raise_for_status() if r.json().get('status') != 'ok': # формат ответа условный raise RuntimeError(f'переключение на {region} отклонено: {r.text}')def current_geo(): # сервис отдаёт внешний IP и регион по геобазе, формат условный r = requests.get(GEO_CHECK_URL, proxies=PROXY, timeout=10) r.raise_for_status() data = r.json() return str(ipaddress.ip_address(data['ip'])), data['region']def wait_geo(old_ip, region, tries=30, pause=2): for _ in range(tries): try: ip, seen = current_geo() except (requests.RequestException, ValueError, KeyError): time.sleep(pause) # ошибка или пустой ответ не считаются новым IP continue if ip != old_ip and seen == region: return ip time.sleep(pause) raise RuntimeError(f'за {tries} попыток порт не подтвердил регион {region}')for region in REGIONS: old_ip, _ = current_geo() switch_geo(region) wait_geo(old_ip, region) for sku in SKUS: page = requests.get(product_url(sku), proxies=PROXY, headers=HEADERS, timeout=30) save(region, sku, page.text)Две оговорки к этому скелету. Другой IP сам по себе не значит, что порт переехал в нужный регион, поэтому условие успеха здесь двойное: адрес сменился и геобаза видит ожидаемый регион. При этом геобазы ошибаются, особенно на уровне города и для мобильных пулов, поэтому сравнивайте регион на том уровне, который ваша база отдаёт стабильно, и держите список допустимых значений вместо одного точного совпадения. Тридцать попыток по две секунды это заглушка, времени переключения я не замерял.
Почему здесь выигрывает порт. T за цикл большой из-за тяжёлых страниц. N большой из-за ежедневности. K маленький из-за последовательного обхода. Все три множителя работают на безлимит. С резидентными за гигабайт вы платите за каждый скрипт и каждую картинку, которую забыли отрезать на уровне заголовков, с мобильными по трафику то же самое, но цена гигабайта у них, как правило, выше. Какой именно множитель получается на конкретном маркетплейсе, я не проверял, это зависит от сайта и от того, насколько агрессивно вы режете ресурсы.
Главный риск в другом: если все города нужны за десять минут вместо ночи, K резко растёт и расчёт рушится.
Сценарий 2. Локальная выдача и реклама по регионам
Нужно увидеть, что показывают поиск, карты и доски объявлений пользователю из конкретного города. Это нужно SEO-командам, рекламщикам, которые проверяют геотаргетинг, и антифроду, который ищет региональный скам в объявлениях.
Профиль нагрузки другой. Запросов много, но каждый лёгкий. Выдача поисковика это в основном HTML и немного скриптов. Карты тяжелее из-за тайлов. Объявления где-то посередине. T за цикл меньше, чем в первом сценарии, но регионов столько же или больше, а одновременность снова не нужна.
Про качество данных скажу осторожно. Локальная выдача поисковиков и карт в заметной степени строится по адресу запроса, но как именно площадки взвешивают мобильные, домашние и датацентровые адреса, в моих данных нет, и универсального вывода я делать не буду. Мобильные за гигабайт и безлимитный мобильный порт отдают адреса одного и того же типа, поэтому по этому признаку между ними разницы нет, а экономически сравнение снова сводится к V против C_port × K. На цену влияет только объём.
Нюанс для расчёта в том, что V здесь бывает скромным. Если месячный объём не дотягивает до V*, честный ответ один. Берите по трафику. Для небольших задач по SERP это обычная ситуация, и я бы не стал покупать порт ради пары тысяч лёгких запросов в день. Проверьте свой T по логам и умножьте на N, прежде чем верить мне на слово. Граница проходит по объёму, а не по типу задачи.
Сценарий 3. Аккаунты с региональной привязкой
Пул аккаунтов в сервисах, где регион имеет значение. Доставка, такси, классифайды и локальные сообщества, где каждый аккаунт должен выглядеть жителем своего города, а сессии длинные.
Профиль нагрузки. Трафик на один аккаунт-день большой, потому что ленты с медиа, карты и автоплей видео съедают гигабайты незаметно. Городов умеренное количество. Одновременность здесь коварна. Аккаунты из разных городов не должны ходить с одного адреса в одну минуту, но держать их активными параллельно не обязательно. Расписание решает эту проблему.
Если двадцать аккаунтов из десяти городов живут по очереди, K равен числу одновременно активных сессий, то есть числу занятых в один момент портов, и число городов на K не влияет.
Экономика выглядит так. При оплате за гигабайт медиатрафик делает каждый аккаунт-день заметной строкой в счёте, и стоимость растёт линейно с числом аккаунтов. У порта стоимость зафиксирована на K портов. Число аккаунтов ограничено только расписанием, лимитом переключений в тарифе и здравым смыслом. Здравый смысл тут не абстракция. Антифрод площадки видит, что с одного адреса сменяется много профилей, и смена IP по таймеру между сессиями это минимум, который вообще требуется. Какую глубину истории адреса хранят конкретные площадки, я не знаю и гадать не буду.
Отдельная ловушка. Смена гео между сессиями разных аккаунтов может сменить вместе с адресом и оператора. Если аккаунт вчера сидел у одного оператора в своём городе, а сегодня у другого, площадка может это заметить. Логичное решение держать привязку аккаунта к региону и оператору в базе и переключаться строго по ней. Это лишняя сложность, которой у моделей с широким пулом нет, там вы просто запрашиваете нужный город у провайдера. Платите за это трафиком.
Сценарий 4. Тестирование приложений и ASO по регионам
Нужно проверить, как приложение ведёт себя в разных регионах. Сторы показывают разные карточки и позиции. Пуши приходят по разным правилам. Платёжные методы и региональные настройки сервера зависят от адреса. QA делает всё это руками на тестовых устройствах, а потом хочет автоматизировать. Важная оговорка: функции, которые включаются по GPS или по геолокации устройства, сменой гео на порту не проверяются, прокси меняет только адрес, а координаты устройства и эмулятора придётся задавать отдельно.
Профиль нагрузки самый тяжёлый из четырёх. Установка и обновление приложения это сотни мегабайт, прогон сценария с медиа добавляет ещё. Регионы обходятся последовательно, потому что стенд один или их несколько. K маленький. T огромный. По формуле это самый очевидный случай для безлимита.
Дополнительный аргумент здесь снова лежит за пределами цены, но он уже. Серверная сторона приложения и сторы видят запросы с адреса сотового оператора, то есть с того типа адреса, с которого ходит основная масса реальных пользователей. При этом SDK внутри приложения определяют тип подключения (Wi‑Fi или сотовая сеть) локально на устройстве, а не по выходному адресу, поэтому мобильный IP не меняет то, что видит эмулятор или стенд, и не гарантирует все сигналы SDK. Что именно воспроизводится через прокси, а что нет, проверяйте на своём стенде.
Скелет прогона такой же, как в первом сценарии, только вместо списка товаров список тест-кейсов, а переключение гео происходит между прогонами. Единственное, что я добавил бы обязательно, это явное подтверждение нового региона перед стартом, потому что если прогон начнётся до того, как порт реально переехал, вы получите результаты из старого региона и будете долго думать, почему пуши не пришли. Ниже вариант на bash, эндпоинты условные, сервис проверки отдаёт JSON с полями ip и region.
old_ip=$(curl -s --max-time 10 -x "$PROXY" "$GEOCHECK" | jq -r '.ip // empty')[ -n "$old_ip" ] || { echo "не удалось получить текущий IP"; exit 1; }code=$(curl -s --max-time 15 -o /dev/null -w '%{http_code}' "$SWITCH_URL?region=$REGION")[ "$code" = "200" ] || { echo "переключение отклонено, код $code"; exit 1; }ok=0for i in $(seq 1 30); do resp=$(curl -s --max-time 10 -x "$PROXY" "$GEOCHECK") || resp="" ip=$(echo "$resp" | jq -r '.ip // empty' 2>/dev/null) seen=$(echo "$resp" | jq -r '.region // empty' 2>/dev/null) # пустой ответ или ошибка сети не считаются новым IP if [ -n "$ip" ] && [ "$ip" != "$old_ip" ] && [ "$seen" = "$REGION" ]; then ok=1; break; fi sleep 2done[ "$ok" = 1 ] || { echo "регион $REGION не подтверждён за 30 попыток"; exit 1; }./run_suite.sh "$REGION"Тридцать итераций в цикле это заглушка, времени переключения я не замерял, подберите число под свой тариф. Оговорка про геобазу из первого сценария действует и здесь: сравнивайте регион на том уровне, который база отдаёт стабильно.
Где безлимит проигрывает
Я обещал честность, поэтому вот случаи, когда порт с переключением гео брать невыгодно или бессмысленно.
• Малый трафик. Если месячный объём V ниже V*, фиксированная цена порта просто не отбивается, и оплата за гигабайт честнее.
• Десятки регионов одновременно. Каждый одновременный регион это отдельный порт, K растёт, и экономия исчезает.
• Зарубежные страны. Переключение гео у мобильного порта ограничено сетью провайдера и тарифом, резидентные пулы здесь, как правило, шире.
• Лимиты на переключения или плата за них. Если в тарифе они есть, слагаемое G × N × P_switch может съесть выгоду, а G × N может упереться в лимит, проверяйте.
• Масса параллельных адресов. Один порт в момент времени отдаёт один IP, для распараллеливания по адресам нужен пул.
• Привязка к конкретному домашнему провайдеру. Если площадка требует адрес именно домашнего ISP, мобильный оператор не подойдёт по определению.
• Проверки на стороне устройства. GPS, язык, профиль, тип подключения и сигналы SDK адресом не меняются, это не задача прокси ни в одной из трёх моделей.
Сведу это в таблицу по одинаковым критериям для всех трёх моделей. Оценки качественные, потому что числовых замеров по чужим тарифам у меня нет.
Критерий
Резидентные за ГБ
Мобильные за ГБ
Безлимитный порт с гео
Месячный объём V ниже V*
выгодно
выгодно
невыгодно
Месячный объём V выше V*
дорого
дорого
выгодно
Много гео одновременно
один аккаунт
один аккаунт
K портов, дорого
Много гео последовательно
платите за объём, V растёт с G
платите за объём, V растёт с G
G не в цене, но G × N сверить с лимитом переключений
Зарубежные страны
широко
зависит от провайдера
ограничено сетью провайдера и тарифом
Лимит или плата за переключения
проверить условия провайдера
проверить условия провайдера
зависит от тарифа, добавляет G × N × P_switch
Масса параллельных IP
да
да
один IP на порт
Сводная таблица и правило выбора
Теперь четыре сценария в одной таблице по единым критериям.
Сценарий
T за цикл
G
K
N
G × N против лимита переключений
Вывод по формуле
1. Мониторинг цен
большой
десятки
единицы воркеров
ежедневно
сотни и больше в месяц, сверить с тарифом
порт
2. SERP, карты, объявления
малый или средний
десятки
единицы воркеров
ежедневно или чаще
считать по расписанию, сверить с тарифом
считать V*, при малом V платить за ГБ
3. Аккаунты с гео
большой на аккаунт
единицы или десятки
число активных сессий
непрерывно
по числу смен сессий, сверить с тарифом
порт при длинных сессиях с медиа
4. Тесты приложений
очень большой
единицы или десятки
один или несколько стендов
по релизам
считать и сверять с тарифом
порт
Правило выбора в одну строку. Из недельных логов выделите трафик одного полного цикла T, затем умножьте его на число циклов в месяц N и получите V, разделите на K и сравните с C_port / P_gb; если V / K выше порога, порт дешевле. Число регионов в цикле на цену порта не влияет, а в моделях за гигабайт каждый добавленный регион добавляет трафик в V, поэтому при прочих равных рост G увеличивает только сторону за гигабайт, но не сторону порта, пока G × N укладывается в лимит переключений.
Что я сделал бы перед покупкой. Включил учёт трафика на прокси, если провайдер отдаёт его в кабинете, или считал бы на своей стороне. Погонял задачу неделю на модели за гигабайт и разделил недельный объём на фактическое число завершённых циклов, чтобы получить T. Посчитал K честно, с поправкой на то, что ночной последовательный обход и дневной параллельный дают разные K. Уточнил список доступных регионов и лимит на переключения в тарифе. И только потом сравнил.
Остался вопрос, ответа на который у меня нет, и его стоило бы измерить отдельно.
Насколько антифрод площадок реагирует на то, что один воркер в течение суток появляется из разных регионов через один порт, по сравнению с тем же обходом через широкий пул. Интуитивно разницы быть не должно. Адрес меняется в обоих случаях; смена оператора не обязательна. Но интуиция в антифроде стоит мало, а замеров у меня нет. Если у кого-то есть такие данные, расскажите в комментариях. Я дополню текст.
Автор: инженер MobileProxy.Space
Источник: habr.com