Как считаются TCP соединения в безлимитном прокси

В нашем тарифе с безлимитным трафиком действительно нет ограничений на объём данных.

👉 Вы можете передавать сколько угодно мегабайт и гигабайт.

Но есть другое ограничение — количество одновременных TCP соединений.

Это ограничение часто вызывает вопросы, потому что оно менее очевидно, чем трафик или скорость.

Проще говоря:

👉 трафик — это “сколько данных вы передали”
👉 соединения — это “сколько одновременно открытых каналов связи у вас есть”

И именно второе мы ограничиваем.

Что именно мы ограничиваем

Мы считаем только одновременные (concurrent) TCP соединения.

👉 Важно:

не трафик (он безлимитный)
не скорость
не количество запросов

А именно количество активных соединений в один момент времени.

Важно понимать

TCP соединение — это не запрос.

Один клиент может:

открыть одно соединение и сделать 100 запросов
или открыть 100 соединений и сделать те же 100 запросов

👉 для лимита это будет совершенно разная нагрузка

Как считается лимит

Каждое открытое TCP соединение = 1 соединение в лимите.

учёт ведётся по Login ID
считаются все протоколы вместе:
- HTTP(S)
- SOCKS5
разницы между ними нет — всё суммируется

👉 Если у вас:

30 соединений через HTTP
20 через SOCKS5

Итого = 50 активных соединений

Не важно, каким способом они были созданы — считается общая нагрузка.

Что происходит при превышении лимита

Если лимит достигнут:

👉 все новые соединения получают отказ (connection refused / reset)

При этом:

уже установленные соединения продолжают работать
новые — не принимаются, пока не освободятся старые

Визуально: как работает ограничение

  flowchart LR
    A[Ваше приложение] --> B[Соединение 1]
    A --> C[Соединение 2]
    A --> D[Соединение 3]
    A --> E[Соединение 4]
    A --> F[Соединение 5]

    B --> P[Прокси]
    C --> P
    D --> P
    E --> P
    F --> P

    P --> OK[Все работают]

    A --> G[Попытка открыть ещё одно]
    G --> X[❌ Отказ<br/>connection refused]

Что такое TCP соединение (простыми словами)

TCP соединение — это “отдельный канал связи” между вашим приложением и прокси.

Каждый раз, когда:

браузер открывает сайт
скрипт делает запрос
бот обращается к API

— создаётся TCP соединение (или используется уже открытое).

Важный момент: keep-alive

Если используется keep-alive:

👉 несколько запросов идут через одно соединение

Это:

экономит лимит
снижает нагрузку

Если включён keep-alive, несколько HTTP-запросов могут переиспользовать одно и то же TCP-соединение вместо того, чтобы открывать новое для каждого запроса — в зависимости от поведения клиента/сервера и времени жизни соединения.

Визуально: как работает keep-alive

  flowchart LR
    A[Ваше приложение] -->|1 соединение| P[Прокси]

    P --> R1[Запрос 1]
    P --> R2[Запрос 2]
    P --> R3[Запрос 3]
    P --> R4[Запрос 4]

    R1 --> S[Сайт]
    R2 --> S
    R3 --> S
    R4 --> S

HTTP/1 — каждое подключение часто создаёт новое TCP соединение

В HTTP/1 (особенно без оптимизаций) чаще всего работает простая модель:

👉 один запрос = одно TCP соединение

Это значит, что ваше приложение:

открывает соединение
делает запрос
закрывает его
и повторяет это снова и снова

Почему это важно

Если у вас высокая активность:

👉 количество соединений растёт очень быстро

И вы можете:

неожиданно упереться в лимит
получить ошибки подключения
столкнуться с нестабильной работой

Визуально: как работает HTTP/1

  flowchart LR
    A[Ваше приложение]

    A -->|Запрос 1| C1[Отдельное соединение]
    A -->|Запрос 2| C2[Отдельное соединение]
    A -->|Запрос 3| C3[Отдельное соединение]
    A -->|Запрос 4| C4[Отдельное соединение]

    C1 --> P[Прокси]
    C2 --> P
    C3 --> P
    C4 --> P

HTTP/2 — более эффективная модель

HTTP/2 может сильно снизить количество соединений.

👉 Как это работает:

один TCP канал
внутри — много параллельных запросов (stream’ов)

👉 Для нас важно:

мы считаем только TCP соединение
HTTP/2 внутри — это просто поток данных
мы не ограничиваем количество stream’ов

HTTP/2 внутри — это просто способ передавать запросы эффективнее.

Визуально: как работает HTTP/2

  flowchart LR
    A[Ваше приложение] -->|1 соединение| P[Прокси]

    P --> R1[Запрос 1]
    P --> R2[Запрос 2]
    P --> R3[Запрос 3]
    P --> R4[Запрос 4]
    P --> R5[Запрос 5]
    P --> R6[Запрос 6]

    R1 --> S[Сайт]
    R2 --> S
    R3 --> S
    R4 --> S
    R5 --> S
    R6 --> S

Что это значит на практике

HTTP/1.1 → много TCP соединений
HTTP/2 → меньше TCP соединений

👉 Поэтому с HTTP/2:

лимит соединений расходуется медленнее
но нагрузка может быть такой же или выше

Типичные сценарии

1. Браузер

Обычный браузер:

открывает 5–20 соединений на один сайт
при нескольких вкладках — больше

👉 С HTTP/2 соединений будет меньше

2. Парсинг / скрейпинг

Частая ошибка:

каждый запрос = новое соединение
нет keep-alive
нет пула соединений

👉 Результат:

лимит быстро заканчивается
появляются ошибки подключения

3. Боты / софт

Многие инструменты:

открывают десятки потоков
не переиспользуют соединения
забывают закрывать соединения после работы. всегда закрывайте соединения!

👉 Это самый частый источник превышений

Частые ошибки пользователей

❌ “У меня мало трафика — почему лимит?”
→ считается не трафик, а соединения

❌ “Я сделал всего 100 запросов”
→ возможно, это 100 отдельных TCP соединений

❌ “Иногда работает, иногда нет”
→ вы упираетесь в лимит соединений

Как использовать лимит эффективно

👉 Рекомендуем:

использовать keep-alive
включать connection pooling
ограничивать количество потоков в софте
по возможности использовать HTTP/2
закрывать соединения, если больше не нужны

Коротко

считаются только одновременные TCP соединения
учёт по Login ID
HTTP и SOCKS5 суммируются
при превышении → connection refused / reset
HTTP/2 помогает экономить соединения

Если остаются вопросы — можно написать в поддержку, разберём конкретный кейс и подскажем оптимальные настройки.

Готовы протестировать с реальными IP?

Зарегистрируйтесь сейчас, чтобы получить мгновенный доступ к нашим прокси-пулам.

Начать сейчас Посмотреть тарифы

Как считаются TCP соединения в безлимитном прокси