TCP-прокси SOCKSFIVE, UDP, QUIC и HTTP/3: что важно знать
SOCKSFIVE сейчас предоставляет TCP-прокси: HTTP(S), SOCKS4 и SOCKS5. UDP-трафик не проксируется как отдельная функция. Эта статья объясняет, почему клиенты всё равно спрашивают про UDP, QUIC и HTTP/3, и как понять, относится ли это к вашей задаче.
Короткий ответ
Для обычных HTTP(S)-запросов, API, браузерных страниц и большинства задач с SOCKS5/HTTP-прокси TCP обычно достаточно. Если программа требует именно UDP-транспорт, WebRTC-туннелирование, игровые/voice/video-сценарии или полный QUIC/HTTP/3 через прокси, SOCKSFIVE как TCP-прокси может не покрыть этот слой.
Что поддерживает SOCKSFIVE
| Функция | Статус | Что это значит |
|---|---|---|
| HTTP(S)-прокси | Поддерживается | Подходит для обычного веб-трафика, API-запросов и многих браузерных сценариев. |
| SOCKS5 / SOCKS4 | Поддерживается | Используется в программах, браузерах и софте, где нужен SOCKS-протокол поверх TCP. |
| Sticky sessions и ротация | Поддерживается | Можно удерживать один IP на сессию или менять IP в зависимости от сценария. |
| UDP-прокси | Не предоставляется сейчас | Если клиентская программа требует именно UDP-прокси, это ограничение нужно учитывать заранее. |
Почему вообще говорят про UDP
TCP и UDP — это транспортные протоколы. TCP устанавливает соединение и контролирует доставку данных. UDP легче и часто используется там, где важна задержка или real-time обмен: WebRTC, voice/video, некоторые streaming-сценарии, игры, а также QUIC, на котором работает HTTP/3. Но UDP не делает трафик “более доверенным” сам по себе.
Ошибка начинается, когда UDP называют “трастовым протоколом”. Платформы оценивают не только транспорт, а общий контекст: IP, ASN, аккаунт, cookies, fingerprint, источник трафика, частоту действий и качество сессии.
Симптомы, причины и проверка
| Симптом | Возможная причина | Что проверить |
|---|---|---|
| Сайт открывается через прокси, но WebRTC-функция не работает | Часть сценария использует UDP или прямое peer-to-peer соединение | Нужен ли именно WebRTC-трафик, или достаточно обычной HTTP(S)-работы сайта. |
| Программа прямо требует UDP-прокси | Сценарий завязан на UDP-транспорт | Документацию программы: поддерживает ли она TCP-only SOCKS5/HTTP(S). |
| HTTP/3 ведёт себя иначе, чем HTTP/2 | HTTP/3 работает поверх QUIC/UDP | Можно ли использовать обычный HTTP(S)-режим без обязательного QUIC. |
| Клиент говорит “UDP трастовее TCP” | Это рыночное упрощение, а не техническая гарантия | Реальную задачу: нужен ли UDP технически, или проблема в аккаунте, IP, fingerprint или поведении. |
Когда SOCKSFIVE подходит
- Работа с HTTP(S)-сайтами и API через TCP-прокси.
- Сценарии, где софт поддерживает HTTP(S), SOCKS4 или SOCKS5.
- Задачи, где важны страна, тип прокси, blacklist filter, sticky session или ротация IP.
- Диагностика веб-сценариев, где результат зависит от IP, сессии, аккаунта, cookies и fingerprint, а не от UDP-транспорта.
Когда стоит искать другое решение
- Программа требует именно UDP-прокси и не умеет работать через TCP-only SOCKS5/HTTP(S).
- Нужен полный проксированный WebRTC/voice/video/game-трафик.
- Сценарий зависит от QUIC/HTTP/3 именно через прокси, а не просто от обычной загрузки сайта.
- Требуется универсальный туннель всего сетевого трафика приложения, а не прокси для поддерживаемых TCP-протоколов.
Практический пример
Клиент пишет: “Нужны UDP-прокси, потому что TCP меньше доверяют”. Корректный ответ: SOCKSFIVE предоставляет TCP-прокси HTTP(S), SOCKS4 и SOCKS5. Если ваша программа технически требует UDP, текущий сервис не закроет эту часть. Если задача — обычный сайт, API, браузерный HTTP(S)-трафик или SOCKS5 поверх TCP, UDP может быть вообще не нужен; тогда важнее проверить страну, тип прокси, sticky-сессию, авторизацию, аккаунт и fingerprint.