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

От чего зависит предел параллельности

Первый фактор — пропускная способность канала на стороне провайдера. Датацентровый и ISP-адрес обычно сидят на широком выделенном канале и держат десятки одновременных соединений без деградации. Резидентный и мобильный трафик идёт через реального абонента или сотовую сеть — там канал у́же, и линейный рост потоков быстрее упирается в задержку и потери пакетов. Разница между этими каналами разобрана подробнее в статье мобильные против резидентных прокси.

Второй фактор — лимиты самого провайдера. Часть тарифов продаёт порт с формальным ограничением по числу параллельных соединений: превышение либо режется, либо новые подключения просто не устанавливаются. Ограничение прописано в условиях тарифа и не связано с качеством канала — оно искусственное и снимается переходом на более широкий план или добавлением портов.

Третий и часто решающий фактор — сама целевая площадка. У неё есть собственный лимит запросов с одного IP в единицу времени, обычно ниже, чем способен пропустить канал. Даже безлимитный по потокам порт упирается в этот потолок: площадка отдаёт капчу, временный бан IP или пустые ответы задолго до того, как исчерпан канал прокси.

Признаки перегруза

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

Третий признак — заметный рост доли капч и временных блокировок именно с этого IP при неизменном сценарии запросов. Если раньше на тысячу запросов капча появлялась эпизодически, а после увеличения числа потоков стала выпадать на каждый десятый — это не совпадение, а сигнал, что параллельность превысила и лимит площадки, и разумный предел для одного адреса.

Почему больше потоков не значит быстрее

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

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

Как распределить нагрузку между портами

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

Практический подход — начинать с консервативного числа потоков на адрес, постепенно поднимать его и фиксировать момент роста таймаутов или доли капч, а затем держаться заметно ниже этой границы. Для резидентных и мобильных каналов с посессионной выдачей адреса ротация IP между запросами сама по себе снижает нагрузку на отдельно взятый адрес, потому что площадка видит разные IP вместо одного перегруженного — как настроить такую ротацию через API, разобрано в отдельной статье про ротацию IP.

Связь потоков с расходом трафика

Число потоков напрямую умножает расход трафика, а не только скорость. Резидентные и мобильные каналы тарифицируются по гигабайтам, поэтому агрессивный параллелизм без отключения лишней медиа-загрузки — картинок, шрифтов, автовоспроизведения — сжигает бюджет трафика кратно быстрее, чем растёт полезный результат. Ориентир: тысяча проверок карточек товара с изображениями — примерно 3–5 ГБ, тысяча текстовых страниц — около 1 ГБ; при масштабировании потоков цифры умножаются линейно, и бюджет стоит закладывать заранее, а не досчитывать по факту исчерпания баланса.

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

Есть ли универсальное число потоков «на один порт»?

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

Что произойдёт, если превысить лимит провайдера по параллельным соединениям?

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

Помогает ли ротация IP держать больше потоков одновременно?

Да, косвенно: если каждый новый запрос или сессия получает новый адрес, лимит целевой площадки считается заново для каждого IP, а не накапливается на одном. Это не отменяет ограничения канала и тарифа, но снимает часть нагрузки, связанную именно с лимитами площадки на конкретный адрес.

Актуальные тарифы по числу потоков и типам каналов — в разделе прокси. Там же можно докупить порты для распределения нагрузки, не разгоняя один адрес выше безопасного предела.