Что такое лимит TCP подключений в мобильных прокси?

Вы запускаете кампанию в рекламном кабинете, подключаете антидетект‑браузер, настраиваете парсер для витрин маркетплейса — и внезапно сталкиваетесь с “затыками”: страницы грузятся рывками, часть запросов возвращает 429 или 403, а прокси то и дело “роняет” сессии. Виноват ли провайдер? Не всегда. Часто корень проблемы — в лимите TCP‑подключений на мобильных прокси. Это тот самый невидимый потолок, который определяет, сколько одновременных сетевых сессий может держать ваш поток задач. Переиграете его — получите обрывы, банальные RST/Timeout и ухудшение доставляемости. Уложитесь — резко вырастут стабильность, скорость и результативность рекламных и парсинговых сценариев.

TCP — это фундаментальный протокол, на котором держится большинство ваших HTTP/HTTPS запросов, WebSocket‑соединений и других “каналов” приложений. Когда вы открываете вкладку в браузере или ваш парсер делает запрос, клиент устанавливает TCP‑соединение с удалённым сервером через мобильный прокси: происходит трёхстороннее рукопожатие (SYN → SYN/ACK → ACK), резервируется пара портов (локальный и удалённый), и начинается передача данных. Мобильные прокси работают через CGNAT операторов связи (4G/5G/LTE), где десятки и сотни клиентов делят один публичный IP и пул эфемерных портов. Чтобы система не “задохнулась”, провайдер ограничивает число одновременных TCP‑сессий на пользователя, на IP или на сам модем. Это и есть лимит TCP‑подключений.

Почему лимит важен? Каждый отдельный поток вашего приложения — будь то загрузка картинок, запросов к API, открытый WebSocket или TLS‑рукопожатие — занимает отдельное TCP‑соединение. Если ваш парсер делает 10 одновременных запросов и у вас открыто 5 вкладок в антидетект‑браузере (каждая подгружает ресурсы асинхронно), вы легко достигаете 30–60 активных коннектов. Добавьте keep‑alive (соединения остаются висячими для ускорения повторных запросов), спорадические ретраи с экспоненциальной задержкой, — и внезапно вы упрётесь в лимит. Дальше начинается деградация: новые запросы встают в очередь, часть соединений падает в TIME_WAIT, прокси отвечает с задержками или сбрасывает лишние коннекты, а система мониторинга видит рост RTO и рост отказов.

Важно различать TCP‑соединение и HTTP‑запрос. HTTP/1.1 в большинстве случаев использует keep‑alive и может отправлять несколько последовательных запросов в рамках одного TCP. HTTP/2 умеет мультиплексировать несколько одновременных потоков в один TCP‑канал, что мощно экономит лимит. Но мобильные прокси, их программные стеки и целевые сайты не всегда гарантированно поддерживают HTTP/2/HTTP/3, и часть трафика всё равно “раскладывается” в отдельные TCP‑сессии. Поэтому оптимизация параллельности и контроль лимитов остаются ключом к предсказуемости.

Как провайдеры считают лимит? Обычно берут “одновременные активные TCP‑сессии” на одного клиента или на один выделенный канал (порт). Порог может быть динамическим: например, 50 коннектов на порт, 100 на IP‑адрес или комбинированная модель с антифлуд‑фильтрами. Если вы используете ротацию IP, sticky‑сессии (закрепление на одном IP на X минут) и несколько одновременных потоков, лимит может сработать неожиданно: часть соединений уйдёт в RST от прокси или получит долгий SYN‑timeout. Мобильная сеть добавляет латентность и джиттер, поэтому запас по лимиту нужен больше, чем в дата‑центровых прокси.
Теперь о практической формуле. Параллельность примерно равна RPS × среднее время обработки запроса (с учётом сетевой задержки и серверного времени). Если вы целитесь в 5 запросов в секунду, а среднее время ответа 1,2 секунды, базовая параллельность — около 6 соединений. Умножьте на коэффициент накладных расходов (keep‑alive, ретраи, доп. ресурсы: картинки, шрифты, аналитические пиксели) — обычно x2‑x3 — и вы получите реалистичную потребность в лимите. Для headless‑браузера с несколькими вкладками и тяжёлыми страницами это легко вырастает до 40–80 TCP‑сессий. Поэтому корректный выбор тарифа и грамотная настройка пула подключений — не опция, а необходимость.

• Лимит TCP‑подключений — это максимум одновременных активных TCP‑сессий, которые ваш трафик может держать через мобильный прокси.
• HTTP/2 и keep‑alive помогают экономить лимит, но мобильная среда и особенности сайтов не всегда позволяют “свести всё” в один поток.
• Рассчитывайте параллельность по формуле RPS × T ответа × запас, и держите safety‑margin 20–40% на пиковые всплески.

Частая ошибка — считать HTTP‑запрос равным одному TCP‑соединению. На деле один TCP‑канал может обслуживать серию HTTP‑запросов (keep‑alive), а в случае HTTP/2 — параллельные потоки внутри одного TCP. Обратная ошибка — игнорировать “невидимые” соединения: загрузку ассетов, WebSocket‑подписки, аналитические скрипты. В headless‑сценариях браузер сам открывает дополнительные коннекты для preconnect, DNS‑prefetch и доставки картинок. В результате фактическая параллельность выше, чем подсчитывается “по верхам”. Решение: включайте логирование на уровне сетевых подключений, используйте connection pooling в клиентах, настраивайте максимальную параллельность (конфиги антидетект‑браузера, парсера) и старайтесь по возможности принудительно включать HTTP/2 на клиентской стороне.

У разных провайдеров трактовки отличаются. Где‑то считают только ESTABLISHED соединения; где‑то — суммарно ESTABLISHED + время в ожидании (SYN_SENT, FIN_WAIT, TIME_WAIT) сверх определённого порога; иногда лимит накладывают на совокупность TCP + WebSocket. Многие мобильные прокси считают “активными” коннекты, по которым была активность за последние N секунд (например, 30–60 секунд). Это означает, что интенсивные всплески создают “хвост” висячих сессий и съедают лимит чуть дольше, чем кажется. Практически это проявляется в том, что после шквала запросов система продолжает “тупить” ещё полминуты. Вывод: планируйте пики, используйте бёрст‑контроль на клиенте, делайте backoff с джиттером, и не забывайте про закрытие неиспользуемых соединений.

Превышение лимита TCP‑подключений — это не только про “медленно”. Это про деньги: потерянные показы, неотправленные события конверсий, сломанные флоу онбординга в лендингах, искажение аналитики и лишнее потребление капчи. В парсинге — это дырки в выгрузках, пропущенные карточки товаров и “грязные” данные. В арбитраже и перформанс‑маркетинге — лишние санкции от антифрод‑систем из‑за всплесков соединений, характерных для автоматизации без учёта лимитов.

• Скачки 429/403 из‑за шипов параллельности и keep‑alive “хвостов”.
• Обрывы WebSocket и нестабильный real‑time в дашбордах и рекламных менеджерах.
• Переобучение антифрод‑сигналов: неестественные паттерны TCP‑активности, метрики jitter/latency.

Команда запускает массовый сплит‑тест креативов: 12 аккаунтов, 4 вкладки на аккаунт, синхронная заливка. На один мобильный IP настроен лимит 50 TCP. Из‑за параллельных загрузок ассетов, предпросмотров и метрик аналитики фактическая параллельность выросла до 90+. Признаки: падение скорости загрузки менеджера, зависания форм, 403 на части POST. Решение: ограничили количество одновременно активных вкладок до 2 на аккаунт, включили HTTP/2 в браузере, снизили RPS фона до 1,5, включили бёрст‑лимит в прокси‑клиенте. Итог: стабильная работа при фактическом пике 35–40 TCP.

Парсер на 5 потоков, каждый открывает страницу с 60–80 ресурсами. На тарифе прокси лимит — 30 TCP на порт. В момент разворота потоков сошлись: асинхронная подгрузка, ретраи и таймауты создавали лавину коннектов. Результат — 20% страниц пустые, 429 от целевого сайта, рост времени на выгрузку в 2,3 раза. Решение: переключили часть запросов на HTTP‑client без рендеринга, включили блокировку тяжёлых ресурсов, добавили задержку 150–250 мс между стартами потоков и расширили лимит до 80 TCP. Выигрыш — минус 38% общего времени, ноль пустых результатов.

Команда маркетинга держит открытыми дашборды, стримит события и параллельно обновляет креативы. WebSocket‑каналы становятся жертвами: периодические обрывы, reconnection‑петли. Причина — лимит TCP и агрессивный keep‑alive на клиенте. Ввели правило: real‑time — на отдельном прокси‑канале с лимитом 20–30 TCP, а заливка — на другом, с плавной шедулинг‑системой. Плюс heartbeat каждые 30 секунд, отключение лишних подписок. Итог — стабильный real‑time, без обрывов и потерь эвентов.

Выбор — это комбинация: ваши паттерны трафика × лимиты провайдера × настройки клиента. Сначала опишите сценарии: сколько одновременно вкладок, какие типы контента (видео/изображения), есть ли WebSocket, каков RPS парсера, какие ретраи и таймауты. Потом рассчитайте консервативную параллельность и добавьте 30–50% запаса. И только после этого подбирайте тариф с подходящим лимитом TCP, количеством каналов и правилами ротации IP. Не забудьте про sticky‑сессии: они полезны для стабильности кабинетов, но удерживают активные коннекты дольше, чем вы думаете.

• Для управления рекламными аккаунтами: 20–40 TCP на канал при 2–3 активных вкладках, HTTP/2 по возможности.
• Для headless‑парсинга: 60–120 TCP на канал при 5–10 потоках, с бёрст‑ограничениями.
• Для real‑time дашбордов и API: отдельный канал 20–30 TCP, приоритет стабильности.

Соберите метрики: среднее время ответа (p50/p95), долю тяжёлых ассетов, наличие WebSocket, частоту ретраев. Рассчитайте базовую параллельность: P = RPS × T. Умножьте на 2–3 для учёта всплесков, keep‑alive, TIME_WAIT. Разбейте трафик на профили: “кабинеты” (интерактив + ассеты), “парсер” (пакетная загрузка), “API” (стабильные короткие запросы). Под каждый профиль подберите отдельный канал или хотя бы разные временные окна активности.

Включите HTTP/2 там, где возможно, — это экономит TCP. Ограничьте максимальную параллельность на уровне клиента (например, 4–6 одновременных загрузок на домен для браузера и 5–10 соединений в пуле для HTTP‑клиента). Настройте таймауты: connect/read/write 10–30 секунд, keep‑alive 60–120 секунд. Реализуйте бёрст‑контроль и backoff с джиттером. В headless отключайте лишние ресурсы: видео, трекинговые пиксели, тяжёлые шрифты. На стороне ОС проверьте ulimit на открытые файлы/сокеты, иначе упрётесь в локальный предел раньше прокси.

Смотрите не только на “скорость” и “гео”, но и на чётко прописанный лимит TCP, политику антифлуда, поддержку HTTP/2, sticky‑сессий и расписание ротации IP. Для кабинетов чаще подходят тарифы с умеренной ротацией и стабильным лимитом 30–60 TCP. Для парсинга — высокие лимиты 80–150 TCP и возможность распределять нагрузку по нескольким каналам. Ротацию IP провайдер делает либо по времени, либо по API: учитывайте, что смена IP на активном трафике может обрывать соединения. Оптимальна “мягкая” ротация вне пиков.

Если суммировать: лимит TCP‑подключений — это управляемый ресурс, который определяет потолок вашей параллельности. Слишком маленький лимит — получите очереди, обрывы и антифрод‑триггеры; слишком большой без настроек — зря переплачиваете, а эффективность не растёт. Практические ориентиры: для рекламных задач держите 30–60 TCP на канал при 2–3 рабочих вкладках и включённом HTTP/2; для парсинга — 80–150 TCP при 5–10 потоках и бёрст‑контроле; для real‑time — 20–30 TCP на выделенном канале. Планируйте запас 20–40% к средней потребности, распределяйте нагрузку по времени и профилям трафика, включайте пул соединений и экономьте TCP за счёт протокольных оптимизаций. По нашим наблюдениям, корректная настройка клиента в среднем снижает фактическое потребление TCP на 30–45%, а грамотный выбор тарифа и разделение каналов уменьшает количество ошибок 429/403 в пике в 2–3 раза. Это прямые деньги: меньше сбоев, выше скорость принятия решений и чище данные для оптимизации.

Вопрос: Как быстро понять, что упираюсь именно в лимит TCP, а не в “плохой” IP?
Ответ: Смотрите на корреляцию со всплесками параллельности: в пике — 429/403, обрывы WebSocket, рост времени установления соединения, вне пиков — всё стабильно. Логи соединений и метрики ESTABLISHED/TIME_WAIT покажут близость к лимиту.

Вопрос: Поможет ли просто купить тариф с большим лимитом?
Ответ: Частично. Без оптимизации клиента вы выльете нагрузку в тот же хаос. Сначала ограничьте параллельность, включите HTTP/2, настройте пул и таймауты. Потом масштабируйте лимит.

Вопрос: Нужна ли ротация IP при большом лимите TCP?
Ответ: Для парсинга — часто да, но ротация должна быть управляемой и вне пиков. Для кабинетов — умеренная ротация или sticky‑сессии предпочтительнее, чтобы не терять стабильность.

Вопрос: Как учитывать WebSocket в лимите?
Ответ: WebSocket — это долгоживущий TCP‑канал. Считайте каждый активный WS как отдельную сессию и выделяйте для real‑time отдельный канал с запасом 20–30 TCP.

Вопрос: Какую формулу использовать для оценки нужного лимита?
Ответ: База — RPS × среднее время ответа × коэффициент запаса (2–3). Для браузерных сценариев добавляйте мультипликатор на ассеты и фоновые запросы.