Сколько потоков тянет мобильный прокси?

Если вы в digital‑маркетинге, арбитраже, SMM или занимаетесь парсингом, вопрос «сколько потоков тянет мобильный прокси» возникает неизбежно. Именно от количества стабильно работающих параллельных подключений зависит окупаемость кампаний, скорость проверки креативов, точность парсинга и масштабирование мультилендинга. Проблема в том, что «магических» цифр нет: один и тот же модем у одного оператора держит 40 сессий без потерь, у другого начинает сыпаться уже на 12. Влияют диапазоны частот и загрузка соты, CG-NAT на стороне оператора, бюджет RAN, политика FUP (fair usage policy), тип протокола (HTTP/SOCKS5), даже настройки keep‑alive в вашем ПО.

Меня зовут Стеценко Денис. За десять лет в инфраструктуре мобильных прокси я протестировал сотни связок «оператор — модем — прошивка — прокси‑софт». В этой статье я разложу по полочкам, что именно ограничивает количество потоков, как корректно измерять «потоковую емкость», на каких цифрах реально планировать бюджеты и как масштабироваться так, чтобы не платить за воздух и не убивать конверсию из‑за таймаутов.

На потоковую емкость мобильного прокси влияет совокупность факторов уровня сети, оборудования и софта. Начнем с радиосети. В 4G скорость и задержка зависят от доступной ширины канала (часто 10–20 МГц), модуляции (до 64/256QAM), MIMO, а главное — от загрузки соты в моменте. В будни в деловых районах вы получите иную картину, чем ночью в спальном квартале. 5G добавляет более низкую задержку, выше пиковую пропускную способность и более гибкое планирование ресурсов — за счет этого в среднем потоков держится больше при тех же сценариях.

Второй слой — адресация и CG‑NAT. Большинство операторов сажают клиентов за Carrier‑Grade NAT, где один публичный IPv4 делят сотни абонентов. У CG‑NAT есть таблицы состояний и лимиты на количество одновременных маппингов: при агрессивной многопоточности ваши портовые маппинги будут выселяться раньше, что проявляется в виде RST и таймаутов. Чем «агрессивнее» ваш софт открывает и закрывает TCP‑сессии, тем быстрее отработают защитные механизмы.

Третий слой — сам прокси‑движок (HTTP/HTTPS CONNECT, SOCKS5), его реализация keep‑alive, пул соединений, таймауты, лимиты на одновременные запросы в одном процессе. Неправильный тайминг на уровне приложений может съедать до 30% потоков, которые в той же сетевой среде были бы стабильными.

Четвертый фактор — физика модема и антенны. Продуваемость канала сильно зависит от качества сигнала: RSRP/RSRQ/SINR. В «чистой» точке с SINR 15–25 dB один модем в 4G стабильно держит 20–40 легких потоков; при SINR ниже 5 dB те же потоки превращаются в очереди перезапросов. В 5G Sub‑6 при отличном SINR я видел стабильные 60–120 потоков на один eSIM, но только при грамотно настроенном прокси и адекватной нагрузке.
Пятый слой — политика оператора: FUP, разовые ограничения на bursts, поведение при превышении определенного числа новых TCP‑сессий в секунду, глубина DPI и наличие rate‑limit. Эти вещи редко документируются, но отлично выявляются нагрузочными тестами: вырастает 95‑й перцентиль задержки, начинаются «ступени» в RPS.

Наконец, ваш шаблон трафика. Поток потоку рознь: «легкий» поток (короткие HTTPS‑запросы, 30–100 КБ полезных данных) и «тяжелый» поток (рендеринг headless‑браузером, запросы к статике, загрузка по 1–3 МБ) — два разных мира. Мобильный прокси может держать сотню легких потоков, но упрется в 15–25 тяжелых.

• Сеть и радиопараметры: 4G/5G, загрузка соты, SINR, частотные диапазоны, MIMO.
• Адресация и NAT: CG‑NAT лимиты, таблицы состояний, маппинг портов, TTL соединений.
• ПО и профиль трафика: протокол (HTTP/SOCKS5), keep‑alive, размер полезных данных, частота новых соединений.

Стабильность потоков упирается не столько в «мегабиты», сколько в задержку и джиттер. Для 4G типичные метрики: RTT 35–80 мс, джиттер 10–30 мс; для 5G Sub‑6: RTT 12–35 мс, джиттер 3–12 мс. HTTP/2 и правильно настроенный keep‑alive позволяют мультиплексировать запросы и экономить на сокращении «handshake‑штрафа». Если каждый поток у вас открывает новое соединение — вы теряете 15–30% производительности и 10–20% устойчивости. Правило практики: минимизируйте количество «холодных» соединений и держите пул «теплых» на стороне прокси и клиента.

CG‑NAT — не враг, но и не бесплатный обед. Большая часть операторов ограничивает скорость создания новых маппингов и общий объем состояний на абонента. Если ваш софт в секунду генерирует десятки новых TCP‑сессий, таблица NAT на вашей стороне будет «шатающейся». Признаки: неожиданные RST, разный TTL на ответах, «ступеньки» на графике латентности после 25–35 потоков в 4G. В 5G пороги выше, но принципы те же. Из практики: переход с «по одному запросу на соединение» к модельке «10–30 запросов на одно persistent‑соединение» увеличивал стабильную емкость потоков с 18 до 34 на том же модеме.

Правильно посчитать «сколько тянет» — значит отделить маркетинговые обещания от реальной емкости. В тесте учитывайте три вещи: профиль нагрузки (вес запроса и ответов), протокол, допустимый уровень ошибок/таймаутов. Параллельно снимайте телеметрию: RTT, потери, 95/99 перцентили, долю 5xx и timeouts. Сессии должны быть «теплыми», иначе вы тестируете не прокси, а количество рукопожатий.

• Сформулируйте профиль: lightweight (до 100 КБ/запрос) или heavy (до 3 МБ/запрос), средний RPS на поток.
• Сделайте ступенчатую нагрузку: +5 потоков каждые 2–3 минуты до деградации, затем спуск.
• Фиксируйте метрики: 95‑й перцентиль, ошибки подключения, среднюю длительность запроса, джиттер.

Стартуйте с 5 потоков, 2 минуты прогрев, затем плюс 5 потоков каждые 120–180 секунд. На каждом плато держите одинаковый шаблон: 80% коротких запросов, 20% длинных, если это соответствует вашей реальной работе. Нагрузчик — wrk/hey для HTTP, а для SOCKS5 — собственные скрипты на curl/pycurl или k6 с прокси‑настройками. Важный момент: используйте persistent‑соединения и ограничьте создание новых TCP‑сессий до 3–5 в секунду на поток, чтобы не «подрывать» NAT.

Ваши рабочие потоки — это уровень, на котором 95‑й перцентиль не растет более чем на 20% относительно базы, а доля ошибок (timeouts/RST/5xx) не превышает 1–2% от общего числа запросов. Если при добавлении очередной пятерки потоков 95‑й перцентиль «скачет» с 500 мс до 900 мс, а timeouts растут до 4%, вы уже выше плато. Фиксируйте «полку» в цифрах и используйте ее для планирования мощности.

Практическая модель для оценки максимума потоков на один мобильный прокси выглядит так: N = min(Nlat, Nbw, Nnat, Ncpu), где Nlat — число потоков по ограничению задержки (95‑й перцентиль), Nbw — по пропускной способности канала, Nnat — по стабильности NAT‑состояний (ошибки/сбросы), Ncpu — по нагрузке на ваш прокси‑движок/сервер. Дополнительно добавляйте коэффициент запаса 0,7–0,85, чтобы учесть суточные колебания сети и перегрузки сот.

Разные задачи потребляют потоки по‑разному. Для рекламы критична стабильность «липких» сессий (sticky‑IP) и предсказуемая задержка; для парсинга — RPS и аккуратная работа с robots/crawl‑delay; для мультилендинга — равномерность распределения трафика, корректная отработка пиковой нагрузки и корректные метрики аналитики. Ниже — конкретные выборки по потокам и настройкам, которые работают в поле.

• Реклама: 4G — 15–25 потоков на модем, 5G — 40–80, sticky 10–30 минут, keep‑alive 120–300 с.
• Парсинг: 4G — 20–35 легких потоков, с плавной скоростью новых TCP; соблюдайте лимиты сайтов.
• Мультилендинг: 4G — 20–30, 5G — 60–100, ставьте балансер и кэш статики.

В рекламных кампаниях «дерганые» потоки бьют по конверсиям. Используйте sticky‑сессии 10–30 минут, чтобы не плодить лишние handshake и не раздражать сервер частой сменой IP в одном потоке. Рекомендуемые настройки: HTTP/2, keep‑alive 180–240 с, лимит новых TCP до 2–3/с на модем, пулы соединений на клиенте и прокси. На 4G модеме при SINR 15–20 dB стабильно живут 18–24 потока для легких операций; 5G держит 50–80 без пульсаций в 95‑м перцентиле.

Для парсинга выигрывают те, кто идет «умно, а не грубо». Профиль «много маленьких запросов» дает отличную масштабируемость: держите 25–35 потоков на 4G и 70–110 на 5G, но обязательно соблюдайте задержки между запросами к одному хосту и задействуйте кэширование. Поддержка HTTP/2 или pipelining существенно снижает накладные расходы. С точки зрения контроля: мониторьте 95/99 перцентиль, долю 429/5xx и автоматически снижайте потоки при росте ошибок, чтобы не ломать полезную нагрузку.

Мультилендингу критичны пиковые всплески. Решение — фронтовой балансер, кэш статики (изображения, JS, CSS) и грамотная топология: модемы на разных сотах/операторах, внешние MIMO‑антенны, распределение географии. В 4G в городе с приличным SINR вы получите 20–30 потоков на модем без деградации UX; 5G позволит держать 60–100. Следите за FUP: после определенного объема трафика ряд операторов режет скорость до 1–3 Мбит/с — емкость потоков падает в 2–3 раза, это нужно учитывать в бюджетах и планировать смену SIM/тарифов.

Итог простой: «сколько потоков тянет мобильный прокси» — это функция среды и ваших настроек. Реальные опорные цифры для одного модема при грамотной конфигурации: 4G — 15–40 легких потоков, 5G — 60–120. Для тяжелых сценариев делите эти значения на 2–3. Секрет в деталях: держите persistent‑соединения, снижайте частоту создания новых TCP, следите за SINR (внешние MIMO‑антенны часто дают +30–50% емкости), выбирайте оператора с адекватным CG‑NAT и без жестких FUP‑срезов на ваш объем трафика.

Как планировать масштаб: допустим, вам нужно одновременно 300 легких потоков. В 4G это 10–15 модемов в хорошей радиосреде (по 20–30 потоков), в 5G — 4–6 модемов (по 60–80). Добавьте запас 20–30% на суточные пики, а также резерв на FUP. С точки зрения экономики: правильный софт (HTTP/2, keep‑alive, connection‑pool) и антенна часто дешевле, чем покупка лишних модемов. Контролируйте «полку»: 95‑й перцентиль не должен расти более чем на 20% при добавлении очередной пятерки потоков, а доля таймаутов — превышать 1–2%. Здесь заканчиваются гадания и начинаются точные цифры, которые помогают зарабатывать.

В: Почему у меня на одном и том же модеме в разное время суток разное число стабильных потоков?
О: Из‑за колебаний загрузки соты и радиопараметров. В часы пик растут RTT и джиттер, CG‑NAT быстрее «сбрасывает» маппинги. Планируйте емкость с запасом 20–30% и проверяйте «полку» утром, днем и вечером.

В: Что выбрать: HTTP/2 через CONNECT или SOCKS5?
О: Для типичных веб‑запросов HTTP/2 выигрывает за счет мультиплексирования и keep‑alive. SOCKS5 универсальнее при смешанном трафике, но часто дает −10–15% к емкости потоков.

В: Как влияет смена IP (rotation) на число потоков?
О: Частая ротация создает много «холодных» соединений и снижает стабильность. Используйте sticky‑сессии 10–30 минут и плановую ротацию между тестовыми окнами.

В: Можно ли увеличить число потоков без покупки дополнительных модемов?
О: Да: внешние MIMO‑антенны, вынос точки приема, оптимизация keep‑alive и connection‑pool, снижение частоты создания новых TCP‑сессий, переход на HTTP/2. Это дает +15–50% к емкости.

В: Какие метрики считать главными при тесте?
О: 95/99 перцентили задержки, доля ошибок (timeouts/RST/5xx), стабильный RPS на поток, динамика при добавлении +5 потоков. Именно они показывают вашу «рабочую полку».