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

Лимит TCP подключений в мобильных прокси — это реальная «планка» одновременных сессий, которую нельзя безнаказанно перепрыгнуть: при её превышении растут ошибки, ломается парсинг, дорожают лиды, а рекламные кабинеты лишний раз попадают под антифрод. Хорошая новость — лимит измерим, управляем и на 30–70% оптимизируем грамотной конфигурацией пула подключений, HTTP/2 и keep-alive.

На лимит TCP подключений в мобильных прокси влияют три слоя: сеть оператора (CGNAT), сам прокси-сервер (его софт и ОС) и то, как ваш софт генерирует трафик. Начнем с базового — Carrier-Grade NAT. Мобильный оператор часто размещает тысячи абонентов за одним внешним IP и распределяет их по пулам эпhemerных портов. Это NAT44/NAT444 с жесткими правилами: ограничение на число одновременных маппингов, скорость создания новых записей (SYN rate) и таймауты бездействия для состояний ESTABLISHED/FIN_WAIT/TIME_WAIT. Плюс, в час пик базовые станции и CGNAT-узлы включают более агрессивные idle‑таймауты, чтобы разгрузиться. Отсюда типичная картина: в 11:00 у вас стабильно 250–300 одновременных TCP-сессий на один мобильный IP, а в 20:00 — уже 120–180, и новые коннекты чаще получают RST/timeout. Второй слой — сам прокси. На стороне сервера работают лимиты ОС (ulimit -n, fs.file-max), TCP‑стек (net.ipv4.ip_local_port_range, tcp_tw_reuse, tcp_fin_timeout), таблица соединений (conntrack) и настройки ПО (Socks5/HTTP‑прокси, пул keep‑alive, очереди). Узкое место может быть и в TLS: частые полные рукопожатия съедают CPU, увеличивают латентность и провоцируют скачки ошибок при пиках. Подключение HTTP/2 даёт выигрыш — один TCP‑канал мультиплексирует десятки запросов, уменьшает число коннектов и экономит портовую ёмкость на CGNAT. Третий слой — клиент. Браузерные движки, headless‑фреймворки (Puppeteer, Playwright), библиотеки (axios, requests) по умолчанию открывают больше соединений, чем нужно, не всегда корректно переиспользуют keep‑alive и создают «шипы» новых сессий при ретраях. Если у вас 20 потоков парсинга с таймаутом 5 секунд и тремя автоматическими повторами, вы можете на ровном месте создать 200–400 новых TCP в секунду, даже не заметив. А CGNAT уже держит на вас 150–200 «висящих» подключений и режет всё, что выше порога. Важно отличать три разные метрики: одновременные соединения (concurrency), скорость установления новых соединений (CPS — connections per second) и скорость запросов (RPS/QPS). Их часто путают. Например, включение HTTP/2 уменьшает concurrency и CPS, но позволяет растить RPS. А чрезмерная ротация IP каждую минуту сбрасывает пулы keep‑alive и взрывает CPS. Есть и нюансы протоколов: HTTP/1.1 с keep‑alive держит множество коротких TCP, HTTP/2 — мало TCP, но длинные. HTTPS добавляет TLS‑нагрузку, DNS‑резолв может стать дополнительные точкой перегрузки. На радиосети влияет и качество канала: 4G/5G, загруженность соты, RTT/packet loss, политика APN. С ростом RTT таймауты CGNAT чаще срабатывают «ложно», а повторные попытки клиента создают лавину новых SYN. В сухом остатке лимит — это не одно число, а баланс трех параметров: активных TCP в моменте, новых TCP в секунду и их среднее время жизни. Управляя ими — через пул соединений, HTTP/2, разумные таймауты, плавный рост нагрузки и расписание ротации — вы превращаете хаотичный «потолок» в прогнозируемую рабочую полку.

• CGNAT накладывает границы на число маппингов и агрессивно закрывает idle‑соединения в часы пик.
• Прокси‑софт и ОС ограничены файловыми дескрипторами, conntrack и CPU на TLS‑рукопожатия.
• Клиент формирует профиль нагрузки: CPS, concurrency, keep‑alive, ретраи и ротация IP.

В 70% кейсов проблемный предел рождается комбинацией: CGNAT режет новые маппинги, а клиент тем временем штурмует сервер «штормом» коротких TCP. Выявляйте источник по симптомам: если растут SYN‑RECV и RST от провайдера — сеть ограничивает CPS; если OS упирается в ulimit -n — расширяйте дескрипторы; если CPU уходит в TLS — включайте HTTP/2 и пересобирайте пул keep‑alive. Корректный бенчмарк — это всегда связка метрик: ss/netstat для состояний TCP, системные логи прокси, метрики RPS/latency на апстриме и корреляция по времени суток.

Мультиплексирование HTTP/2 позволяет обслуживать десятки одновременных запросов на одном TCP‑канале, что снижает CPS в 3–6 раз в типовых сценариях. Правильный keep‑alive экономит и CGNAT‑маппинги, и CPU на TLS: держите соединение 30–90 секунд под нагрузкой, но обязательно внедрите лимит общего пула и механизмы «drain» при ротации IP, чтобы не копить зомби‑сессии. Не забывайте, что слишком длинный keep‑alive при низкой активности — тоже зло: CGNAT закроет idle‑канал, а ваш клиент узнает об этом только на следующем запросе с дополнительной задержкой.

Лимит TCP — это не абстракция сетевиков, а прямые деньги. В парсинге лимит задает потолок стабильного RPS: переступили — выросла доля 499/timeout и полезла «грязь» в датасет. В рекламе быстрые шипы новых соединений и плавающие таймауты — частые триггеры антифрода, возрастает стоимость клика и риск ограничений. В «серых» схемах масштабирования (массовые лендинги, многоаккаунт, агрессивные рассылки) маленький резерв по лимитам превращается в каскад сбоев именно на пике кампании, когда каждый час простоя — минус выручка и репутация.

• Парсинг: держите устойчивый concurrency и HTTP/2; «выдавить» максимум RPS без роста CPS.
• Реклама: сглаживайте всплески новых TCP, чтобы не давать поводов антифроду и не ловить лишние проверки.
• Масштабирование: вместо «лупить сильнее» — горизонтально распределяйте нагрузку и планируйте ротации.

Для антибот‑систем характерен поведенческий анализ: «зубчатая» нагрузка, множественные короткие TCP, отсутствие стабильного пула и синхронные ретраи выглядят подозрительно. Даже если у вас корректные заголовки и ротация устройств, сетевой профиль выдаёт механистичность. Правильная стратегия — понизить CPS на IP, увеличить reuse соединений, а ротацию адресов привязать к количеству запросов, а не к минутам. Многие команды получают +25–40% к объему чистых данных, просто стабилизируя сессии и вводя плавное масштабирование потоков (ramp‑up 1–2 минуты вместо мгновенного старта в 100% мощности).

Площадки и их антифрод‑алгоритмы любят предсказуемость. Когда вы запускаете кампанию, которая за 10 секунд создает 300 новых TCP на свежем IP, это похоже на бота. Решение — прогрев: начинайте с низкого CPS, держите активные keep‑alive, включайте HTTP/2, давайте системе «узнать» ваш паттерн. Время от времени перераспределяйте потоки между несколькими мобильными IP, чтобы не упираться в локальный лимит CGNAT на одной соте. На практике это снижает CPA и уменьшает объем «ручных проверок» рекламных кабинетов.

Серые подходы часто упираются в инфраструктуру раньше, чем в креатив. Лимит TCP — один из первых «стеклянных потолков». Здесь важны три принципа: распределённость (несколько узлов прокси и APN/сот), предсказуемость (никаких взрывных CPS) и устойчивость к отказам (graceful shutdown keep‑alive при ротации, резервный пул). Уменьшая частоту ротации IP и поднимая долю HTTP/2, вы экономите лимиты CGNAT и получаете ровную траекторию, что отражается в метриках: меньше 5xx/timeout, стабильнее CTR и меньше просадок по дневному бюджету.

Правильная настройка начинается с измерений. Ваша цель — найти безопасную полку по трем осям: максимальные одновременные TCP, безопасный CPS и рабочий idle‑таймаут. Проведите тесты по времени суток (утро/день/пик/ночь) и по сотам, если есть выбор. Снимайте метрики на всех уровнях: ss/netstat/conntrack на прокси, логируйте CPS и RPS на клиенте, фиксируйте долю ошибок/латентность на апстриме. Параллельно проверьте системные лимиты (ulimit -n не ниже 65536, расширенный ip_local_port_range), включите HTTP/2 и настройте пул keep‑alive. Важный этап — контроль ретраев: агрессивные повторы маскируют истинную картину и создают иллюзии «нормальной» пропускной способности, а на деле давят CGNAT. После базовой профилировки введите ограничения на клиентах: максимум активных потоков на IP, потолок CPS, плавное нарастание нагрузки и «дренаж» соединений перед ротацией IP. Повторите замер спустя 24 часа и сравните стабильность: если дисперсия ошибок в пике упала на 30–50%, вы на верном пути.

• Пример 1: измеряем CPS/Concurrency на одном мобильном IP в разное время суток.
• Пример 2: включаем HTTP/2 и сокращаем CPS без потери RPS.
• Пример 3: настраиваем пул keep‑alive и «мягкую» ротацию IP.

Берем один IP мобильного прокси и запускаем серию тестов: 10, 20, 40, 60 одновременных потоков на HTTP/1.1 и замеряем устойчивый уровень без роста 5xx/timeout. Утром (8–10) получаем полку в 220–260 одновременных TCP при CPS около 15. Днем (12–15) — 180–200 TCP, CPS 12–14. Вечерний пик (19–22) — 120–160 TCP и CPS не выше 8–10. Ночью (2–5) — до 300–350 TCP и CPS 18–22. Вывод: планируйте ресурсоемкие сценарии на «зеленые окна», а критичные кампании раскладывайте по нескольким IP/сотам, чтобы сгладить ограничение пиков.

Переключаем клиентов на HTTP/2. На тех же нагрузках видим снижение числа TCP в 4–5 раз: вместо 200 активных — 40–50 долгоживущих каналов. CPS падает с 14 до 3–4, RPS растет на 20–35% за счет уменьшения накладных расходов TLS. Доля timeout на пике уменьшается с 6,8% до 2,1%, а вариативность латентности падает на 30–40%. Это иллюстрирует главную мысль: чтобы «поднять потолок», не обязательно увеличивать мощность — достаточно разумно перераспределить её.

Настраиваем keep‑alive на 60–90 секунд при активной нагрузке, ограничиваем общий пул до 60–80 TCP на IP, а перед ротацией IP (раз в N запросов, а не минут) делаем «drain»: перестаем пускать новые запросы в старые каналы и даем им корректно завершиться. Результат: падение TIME_WAIT на 45–60%, снижение RST от CGNAT в пиках на 30–35%, рост стабильности RPS без увеличения CPS. Дополнительно переносим часть запросов на соседний IP — получаем почти линейный масштаб без лавинообразных сбоев.

Лимит TCP подключений в мобильных прокси задается тремя силами: CGNAT оператора, ресурсами и настройками вашего прокси и профилем нагрузки на клиенте. Это не одно число, а баланс: одновременные TCP, скорость создания новых соединений и их время жизни. Практика показывает, что грамотная конфигурация — HTTP/2, ограниченный и «умный» keep‑alive, контроль CPS и плавный рост нагрузки — дает 30–70% прироста стабильности при тех же ресурсах и снижает таймауты/ошибки в 2–4 раза. Для бизнеса это означает более чистые данные в парсинге, заметное снижение антифрод‑сигналов в рекламе и предсказуемую работу «серых» масштабирований без каскадных падений. Короткий чек‑лист: измерьте суточный профиль (concurrency, CPS, timeout); поднимите ulimit/conntrack и включите HTTP/2; введите global connection pool и CPS‑лимитер на клиентах; сделайте ramp‑up и «drain» перед ротацией IP; распределите нагрузку по разным IP/сотам; повторите замер через 24–48 часов и закрепите настройки, которые дали минимум ошибок при целевом RPS. Если держать CPS на IP ≤ 8–12 в часы пик и активные TCP в диапазоне 120–180 (для 4G), а ночью поднимать до 250–350, вы почти всегда останетесь ниже порогов CGNAT и избежите «штормов соединений». В итоге вы выигрываете в ROI: меньше холостых запросов, ниже стоимость валидного трафика, выше пропускная способность без покупки лишних ресурсов.

Вопрос 1: Сколько одновременных TCP‑подключений безопасно держать на одном мобильном IP?
Ответ: В среднем для 4G это 120–180 в вечерний пик и 220–300 днем/ночью. Но ключ — не предел concurrency, а CPS: держите новые соединения на уровне 8–12/с в пике и используйте HTTP/2, чтобы не раздувать количество TCP.

Вопрос 2: Помогает ли увеличение ротации IP обойти лимиты?
Ответ: Частая ротация обычно ухудшает ситуацию: вы теряете keep‑alive и взрываете CPS. Эффективнее ограничить пул и ротацию привязать к числу запросов/сессий, делая «drain» перед сменой IP.

Вопрос 3: Что включить первым делом — HTTP/2 или тюнинг ОС?
Ответ: Начните с HTTP/2 и пула keep‑alive — это дает быстрый мультипликативный эффект. Затем поднимите ulimit -n, настроите ip_local_port_range и conntrack, чтобы инфраструктура не стала новым узким местом.

Вопрос 4: Как понять, что упираюсь в CGNAT, а не в прокси?
Ответ: Признаки CGNAT — рост SYN‑RECV, RST/timeout именно в часы пик, чувствительность к времени суток. Если же видите “too many open files”, высокий CPU на TLS и переполненный conntrack — проблема ближе к вашему серверу.

Вопрос 5: Имеет ли смысл переход на несколько IP вместо одного «мощного»?
Ответ: Да. Горизонтальное распределение по 3–5 IP с лимитом CPS и плавным ramp‑up почти всегда устойчивее и предсказуемее, чем попытка «пробить потолок» на одном IP. Это снижает риски антифрода и делает масштабирование линейным.