Последнее обновление: 2026-10-18
«HTTPS-прокси» не шифрует ничего из того, что SOCKS5 оставляет открытым. В обоих случаях HTTPS-сайт передаётся одним и тем же сквозным TLS-соединением, и в обоих случаях пароль от прокси уходит на шлюз открытым текстом. В октябре 2026 года мы прогнали 11 прокси от 5 провайдеров через оба протокола параллельно, по 50 прогонов каждый, на одних и тех же шлюзах с одним и тем же логином.
На каждом прокси с фиксированным IP SOCKS5 подключался медленнее ровно на два дополнительных обмена со шлюзом: 37 мс на близком шлюзе и 574 мс на далёком. После установления соединения скорость загрузки была одинаковой. Различия, которые действительно влияют на выбор, в другом: кто делает DNS-резолв, работает ли UDP, что принимает ваш браузер и что WebRTC отправляет в обход прокси.
Короткий ответ
- Для сайтов, скрейпинга и headless-браузеров выбирайте HTTP. Его поддерживает любой инструмент с логином и паролем, и он подключается быстрее.
- SOCKS5 используйте для программ, которые не являются веб-клиентами: Telegram, почтовые клиенты, SSH, лаунчеры игр, десктопные приложения.
- В SOCKS5 включайте удалённый DNS (
socks5h://в curl и Python). С обычнымsocks5://все 11 прокси оставляли DNS-запросы на резолвере нашего сервера. - Не рассчитывайте на UDP. В SOCKS5 он предусмотрен стандартом, но в нашем тесте UDP-пакет прошёл только через 1 из 11 прокси.
- Ни один из протоколов не скрывает ваш IP от WebRTC в Chromium. Это исправляется одним флагом браузера, см. ниже.
Что на самом деле означает «HTTPS-прокси»
Когда провайдер указывает «HTTP/HTTPS» рядом с «SOCKS5», HTTPS означает, что прокси умеет открывать HTTPS-сайты, а не то, что соединение до прокси шифруется. Клиент отправляет на шлюз CONNECT example.com:443 открытым текстом, шлюз открывает TCP-соединение с сайтом, а дальше просто пересылает байты. TLS-рукопожатие происходит между вашим клиентом и сайтом. Прокси видит доменное имя и объём трафика, но не страницы, пароли или куки.
SOCKS5 делает то же самое, только уровнем ниже. Клиент просит шлюз подключиться к хосту и порту, а шлюз пересылает байты. Для HTTPS-сайта результат тот же. На всех 11 прокси оба протокола давали TLS 1.3, HTTP/2 и сертификат самого сайта, а сайт получал один и тот же набор заголовков запроса.
Соединение до самого прокси в обоих случаях остаётся открытым. В HTTP-прокси логин передаётся в заголовке Proxy-Authorization: Basic, это base64, а не шифрование. В SOCKS5 он уходит как обычные байты, как определено в RFC 1929. В недоверенной сети любой, кто видит трафик, может прочитать пароль прокси.
Шифрованное соединение до прокси всё же бывает. Это адрес прокси, начинающийся с https://: сначала ваш клиент выполняет TLS-рукопожатие со шлюзом, и пароль передаётся внутри него. Мы проверили это на 14 прокси от 8 провайдеров. Три шлюза приняли такой режим на своём обычном порту, и два из них, Thordata и Proxmint, показали сертификат, который проходит проверку. Это добавляло от 40 до 130 мс до первого байта.
SOCKS5 против HTTP-прокси: реальные различия
| HTTP(S)-прокси | SOCKS5 | |
|---|---|---|
| Что передаёт | Веб-запросы и другие TCP-соединения через CONNECT, если провайдер разрешает другие порты | Любые TCP-соединения, UDP предусмотрен стандартом |
| HTTPS-сайты | Сквозной TLS через CONNECT | Сквозной TLS, результат тот же |
Обычные сайты http:// | Прокси читает запрос и может его изменить | Прокси пересылает байты без изменений |
| DNS | Всегда резолвится на стороне прокси | На стороне прокси с socks5h, вашим резолвером с socks5 |
| UDP | Нет | В нашем тесте его передал 1 из 11 прокси |
| Новое соединение с логином | Один обмен со шлюзом | Три обмена со шлюзом |
| Скорость загрузки после подключения | Одинаковая в нашем тесте | |
| Логин и пароль в Chrome и Firefox | Поддерживается | В Chrome нет, в Firefox только через расширения |
| Шифрование до прокси | Только при адресе прокси вида https:// | Нет |
Наш тест: одни и те же прокси через оба протокола
Каждый прокси получил 50 прогонов. В каждом прогоне мы открывали одно новое соединение через HTTP и одно через SOCKS5 с удалённым DNS, чередуя, что идёт первым, и измеряли время до первого байта небольшой HTTPS-страницы. Затем мы отправляли ещё 10 запросов по уже открытому соединению и три раза скачивали файл 1 МБ через каждый протокол. Успешность составила 49 или 50 из 50 на каждом прокси и в каждом протоколе.
Прокси с фиксированным IP дают самый чистый сравнительный результат, потому что выходной адрес не меняется между прогонами:
| Прокси | RTT до шлюза | Первый байт, HTTP | Первый байт, SOCKS5 | Насколько SOCKS5 медленнее | Открытое соединение, HTTP / SOCKS5 |
|---|---|---|---|---|---|
| Proxy Seller, IPv6 | 19 мс | 99 мс | 136 мс | 37 мс | 28 / 26 мс |
| SpaceProxy, общий дата-центр | 26 мс | 192 мс | 252 мс | 60 мс | 92 / 53 мс |
| Proxy Seller, ISP | 70 мс | 735 мс | 874 мс | 139 мс | 148 / 148 мс |
| Proxy Seller, выделенный дата-центр | 290 мс | 2744 мс | 3318 мс | 574 мс | 592 / 554 мс |
Дополнительное время на каждом прокси равно двум обменам со шлюзом, независимо от типа и провайдера. Это особенность самого протокола. SOCKS5 с паролем требует приветствия, затем передачи логина, затем запроса на подключение, и на каждом шаге нужно дождаться ответа. В HTTP-прокси логин и адрес назначения приходят в одном запросе.
Поэтому цена SOCKS5 зависит от того, насколько далеко вы находитесь от шлюза: рядом это мелочь, на шлюзе на другом конце света это уже полсекунды.
После открытия туннеля оба протокола просто пересылают байты. Скачивание 1 МБ шло с одинаковой скоростью в обоих вариантах: 74 Мбит/с на IPv6-прокси, 19 Мбит/с на ISP, 4,8 Мбит/с на выделенном дата-центровом прокси. Запросы по открытому соединению тоже были одинаковыми, за одним исключением: HTTP-порт SpaceProxy отвечал за 92 мс против 53 мс на его SOCKS5-порту, поэтому длинная сессия там быстрее работает через SOCKS5.
Ротационные прокси меняют выход на каждый запрос, поэтому каждый прогон попадает в другое домашнее или мобильное подключение:
| Прокси | Первый байт, HTTP | Первый байт, SOCKS5 | Прогоны, где SOCKS5 был быстрее |
|---|---|---|---|
| Evomi, ротационные резидентские | 514 мс | 608 мс | 35% |
| Evomi, ротационные мобильные | 620 мс | 769 мс | 38% |
| Evomi, ротационные дата-центровые | 815 мс | 798 мс | 49% |
| NodeMaven, ротационные резидентские | 880 мс | 970 мс | 48% |
| NodeMaven, ротационные мобильные | 1073 мс | 1255 мс | 43% |
| Proxmint, ротационные резидентские | 1274 мс | 1216 мс | 51% |
| Proxy Seller, ротационные резидентские | 686 мс | 655 мс | 50% |
Здесь разрыв между двумя выходами намного больше, чем разница между протоколами. Скорость скачивания через ротационные шлюзы колебалась от 0,5 до 58 Мбит/с, и даже две загрузки подряд через один и тот же шлюз и протокол нередко отличались в разы. На Evomi и NodeMaven HTTP всё же оказался лучше по медиане, на 90–180 мс. На Proxmint, Proxy Seller и в дата-центровом пуле Evomi протоколы были примерно равны. Один тестовый запрос ничего не говорит о ротационном прокси, сравнивайте их по десяткам запросов или не сравнивайте вовсе.
DNS: утечка, которую добавляет SOCKS5
В HTTP-прокси шлюз всегда резолвит имя сайта, потому что имя входит в запрос. SOCKS5 позволяет выбрать. При socks5:// ваша машина сначала ищет адрес и отправляет прокси только IP. При socks5h:// она отправляет имя, и резолв выполняется на стороне прокси.
Мы запрашивали уникальный тестовый домен через каждый прокси в каждом режиме и проверяли, какой резолвер задавал вопрос. При socks5:// это был резолвер нашего сервера, OVH дата-центр во Франции, на всех 11 прокси, при том что сайт видел выходной IP в другой стране.
Сайт не видит ваш резолвер, но тесты на DNS-утечки видят, и оператор резолвера видит каждый домен, который вы открываете. При socks5h:// и при HTTP запросы шли со стороны прокси: на большинстве шлюзов это были публичные резолверы Google и Cloudflare, а на части резидентских и мобильных выходов резолвер провайдера доступа в интернет.
У удалённого DNS есть один побочный эффект. Резолвер часто находился в другой стране, чем выход: ротационный резидентский выход в Колумбии резолвил через Google в США, мобильный выход в России через резолверы в Сингапуре. Крупные CDN выбирают сервер по местоположению резолвера, поэтому запрос может уйти на сервер далеко от выхода и выполняться дольше.
Как включить удалённый DNS:
- curl:
--proxy socks5h://user:pass@host:portили--socks5-hostname host:port - Python requests:
proxies={"https": "socks5h://user:pass@host:port"}, послеpip install "requests[socks]" - Proxifier и похожие инструменты: опция резолвить имена хостов через прокси
Обычные HTTP-сайты: что может изменить HTTP-прокси
По адресу http:// TLS нет, поэтому HTTP-прокси работает как настоящий посредник: читает запрос и отправляет свою копию. На NodeMaven и на резидентском шлюзе Proxy Seller в этой копии был заголовок Accept-Encoding, которого наш клиент не отправлял.
Через SOCKS5 и через туннель CONNECT тот же запрос приходил без изменений на всех прокси. Ни один из 11 прокси не передавал IP нашего сервера на сайт в X-Forwarded-For ни в одном протоколе. Старое правило «SOCKS5 более анонимный» не подтвердилось ни у одного из протестированных провайдеров.
UDP: в стандарте, но редко в реальности
В SOCKS5 есть режим UDP, UDP ASSOCIATE, и обычно именно из-за него выбирают SOCKS5 для игр, голосовых звонков и QUIC. Мы запросили его на каждом шлюзе и отправили DNS-запрос на 1.1.1.1 через ретранслятор.
- Прошло: SpaceProxy, общий дата-центр. Запрос ушёл и ответ вернулся.
- Команду принял, пакеты отбросил: Proxy Seller, ротационные резидентские. Ни ошибки, ни ответа.
- Отказал: Evomi на всех трёх шлюзах, Proxy Seller на IPv6, ISP и выделенном дата-центре (ответ «command not supported»), Proxmint («not allowed»).
- Закрыл соединение: NodeMaven на обоих шлюзах.
Если вам нужен UDP, проверьте его на самом маленьком пакете перед покупкой объёма. Шлюз может принять команду и при этом отбрасывать каждый пакет, а большинство программ тихо переключается на TCP.
Браузеры: SOCKS5 с паролем не работает
Chrome не поддерживает SOCKS5-аутентификацию, а Firefox принимает её только от расширений, но не из настроек прокси. Мы запускали Chromium и Firefox через Playwright с учётными данными, которые работали в curl, и оба отказали с сообщением «Browser does not support socks5 proxy authentication». Тот же логин через HTTP работал в обоих. Для обычного или headless-браузера остаётся два варианта: HTTP-прокси или SOCKS5 с авторизацией по вашему IP, что большинство провайдеров позволяет настроить в панели. Антидетект-браузеры и прокси-расширения передают логин SOCKS5 сами, поэтому ограничение относится к самому браузеру без надстроек.
WebRTC обходит оба протокола
WebRTC узнаёт ваш публичный адрес, отправляя UDP на STUN-сервер. Мы открыли страницу через прокси Proxy Seller, SpaceProxy и NodeMaven и собрали WebRTC candidates. Результат на всех трёх был одинаковым:
| Браузер и прокси | IP, который видит страница | Публичный IP в WebRTC |
|---|---|---|
| Chromium, HTTP-прокси | IP прокси | Реальный IP нашего сервера |
| Chromium, SOCKS5 | IP прокси | Реальный IP нашего сервера |
Chromium, любой протокол, с --force-webrtc-ip-handling-policy=disable_non_proxied_udp | IP прокси | Нет |
| Firefox (сборка Playwright), HTTP-прокси | IP прокси | Реальный IP нашего сервера |
| Firefox (сборка Playwright), SOCKS5 | IP прокси | Нет |
SpaceProxy пропускает UDP через SOCKS5, и Chromium всё равно отправлял WebRTC в обход, так что даже шлюз с UDP это не исправляет. В Chromium исправление — это указанный выше флаг или та же политика, заданная расширением WebRTC. Антидетект-браузеры подменяют WebRTC-адрес на адрес прокси. Проверьте свою конфигурацию нашим тестом утечки WebRTC после подключения прокси.
Порты: куда провайдеры ставят SOCKS5
Провайдеры не продают SOCKS5 и HTTP как отдельные продукты. Один тариф даёт оба, и меняется только порт или схема в адресе:
| Провайдер | HTTP и SOCKS5 |
|---|---|
| Evomi | Отдельные порты: резидентские 1000 и 1002, мобильные 3000 и 3002, дата-центровые 2000 и 2002 |
| NodeMaven | Отдельные порты: 8080 и 1080 |
| Proxmint | Один порт для обоих |
| Proxy Seller | Один порт для обоих, на ротационном шлюзе и на статических IP |
| SpaceProxy | Отдельные порты, SOCKS5 на следующем по номеру порту |
Шлюз с одним портом различает протоколы по первым байтам, поэтому вам достаточно поменять http:// на socks5h://. При раздельных портах клиент, направленный не туда, падает с невнятной ошибкой вроде пустого ответа, это самая частая причина жалоб «SOCKS5 не работает».
Какой протокол выбрать под задачу
| Задача | Протокол | Почему |
|---|---|---|
| Веб-скрейпинг через curl, Python, Node.js | HTTP | Быстрее подключается, не нужны дополнительные библиотеки. SOCKS5 только с удалённым DNS |
| Playwright, Puppeteer, Selenium | HTTP | Chromium и Firefox не принимают SOCKS5-логин |
| Антидетект-браузеры, мультиаккаунтинг | Любой | Браузер сам обрабатывает логин и WebRTC |
| Telegram, почтовые клиенты, SSH, десктопные приложения | SOCKS5 | Они не умеют работать через HTTP |
| Игры, голосовые и видеозвонки | SOCKS5 с работающим UDP | Сначала протестируйте UDP, его поддерживает мало шлюзов |
| Публичный Wi-Fi | Адрес прокси вида https://, если провайдер это поддерживает | Единственный вариант, который шифрует пароль прокси |
Протокол не определяет, какие сайты вас пускают. Это зависит от IP: его типа, сети и истории. Для этого выбора смотрите наш гид по выбору типа прокси и еженедельные результаты в нашем бенчмарке прокси.
Как проверить свой прокси
- Выход и протокол:
curl -x socks5h://user:pass@host:port https://www.cloudflare.com/cdn-cgi/trace, затем то же сhttp://. В обоих случаях должны быть одинаковая страна выхода иhttp=http/2. - Цена подключения: добавьте
-s -o /dev/null -w "%{time_connect} %{time_appconnect}\n"и запустите 20 раз для каждого протокола. Первое число — время обмена со шлюзом (RTT). На фиксированном IP SOCKS5 должен быть примерно на два таких значения медленнее. - DNS: откройте тест DNS-утечек через прокси с
socks5и сsocks5hи сравните резолверы. - Работает ли прокси вообще, его тип и местоположение: наш прокси-чекер.
Провайдеры в этом тесте
Все пять продают оба протокола в рамках одного тарифа.
Evomi
https://evomi.com/
$0.49/GB
Тип прокси
Мобильные прокси, Резидентские прокси, ISP-прокси, Датацентровые прокси
Пул IP-адресов
100M+ IP
Дата основания
2014
Штаб-квартира
Швейцария
Плюсы и минусы
- Бесплатный триал
- Возврат в течение 30 дн.
- До 51% дешевле за GB на больших объёмах
- 5 типов прокси в одном аккаунте
- Доступен план оплаты по факту использования без ежемесячных платежей
- При оплате картой дополнительно взимается НДС
Тип прокси
Мобильные прокси, Резидентские прокси, ISP-прокси
Пул IP-адресов
30M+ IP
Дата основания
2023
Штаб-квартира
Эстония
Плюсы и минусы
- Платный тест за $3.50
- До 48% дешевле за GB на больших объёмах
- С ежемесячными тарифами неиспользованный трафик переносится на следующий месяц
- Доступна опция оплаты по факту
- Ограниченные способы оплаты
Тип прокси
Мобильные прокси, Резидентские прокси, Датацентровые прокси
Пул IP-адресов
90M+ IP
Дата основания
2026
Штаб-квартира
Индонезия
Плюсы и минусы
Тип прокси
Мобильные прокси, Резидентские прокси, Индивидуальные IPv6 прокси, ISP-прокси, Датацентровые прокси
Пул IP-адресов
47M+ IP
Дата основания
2014
Штаб-квартира
Кипр
Плюсы и минусы
- Возврат в течение 24 ч
- До 63% дешевле за GB на больших объёмах
- 8 типов прокси в одном аккаунте
- SDK: PHP, Python, Node.js, Java, GoLang
- Круглосуточная поддержка
Тип прокси
Индивидуальные IPv6 прокси, Датацентровые прокси
Пул IP-адресов
47M+ IP
Дата основания
2019
Штаб-квартира
Кипр
Плюсы и минусы
- Возврат в течение 2 дн.
- 8 способов оплаты
- Есть IPv6-прокси
- Широкий выбор стран
- Имеются жалобы на качество поддержки клиентов.
Как мы тестировали
Тест проводился 18 октября 2026 года с нашего сервера в лондонском дата-центре, curl 8.5. Мы использовали тестовые доступы из нашего бенчмарка прокси, те 11, которые поддерживают оба протокола. Во всех сравнениях использовались один и тот же шлюз и один и тот же логин. Менялась только схема и, там где это требуется у провайдера, порт.
- Тайминги: 50 прогонов на прокси, новое соединение на каждый запрос, чередование порядка протоколов, к
https://www.cloudflare.com/cdn-cgi/trace. - Открытое соединение: три прогона по 11 запросов в одном соединении, первый запрос каждого прогона не учитывался.
- Скорость: файл 1 МБ с нашего сервера, три раза на протокол, учитывалось только время передачи.
- DNS: уникальные поддомены публичного сервиса теста DNS-утечек, по одному на режим.
- Заголовки: httpbin.org по обычному HTTP и по HTTPS.
- UDP: запрос SOCKS5
UDP ASSOCIATEи DNS-запрос на 1.1.1.1 через ретранслятор. - Браузеры: Chromium и Firefox через Playwright, WebRTC candidates от
stun.l.google.com. SOCKS5 в браузере шёл через локальный ретранслятор без пароля, потому что ни один из браузеров его не принимает.
Это был разовый тест, отдельный от еженедельного бенчмарка.
Источники
- RFC 1928: SOCKS Protocol Version 5
- RFC 1929: Username/Password Authentication for SOCKS V5
- RFC 9110: HTTP Semantics, метод CONNECT
- Everything curl: SOCKS-прокси и socks5h
- Код нашего бенчмарка прокси на GitHub
FAQ
- SOCKS5 быстрее, чем HTTPS-прокси?
- Нет. В нашем тесте 11 прокси SOCKS5 с логином открывали каждое новое соединение медленнее из-за двух дополнительных обменов со шлюзом, от 37 до 574 мс в зависимости от расстояния. После установления соединения скорость скачивания в обоих случаях была одинаковой.
- SOCKS5 шифруется?
- Нет. SOCKS5 просто пересылает байты как есть и отправляет логин открытым текстом. Доступ к HTTPS-сайту через него остаётся шифрованным, потому что TLS работает между вашим клиентом и сайтом, точно так же, как и при использовании HTTP-прокси.
- HTTPS-прокси шифрует мой трафик?
- Не соединение с прокси. «HTTPS-прокси» обычно означает HTTP-прокси, который открывает HTTPS-сайты через CONNECT, а пароль прокси передаётся в base64. Только прокси-адрес, который начинается с https://, шифрует канал до шлюза, и из 14 протестированных нами прокси это поддержали лишь 2, причём с корректным сертификатом.
- В чём разница между socks5 и socks5h?
- При socks5 имя сайта резолвит ваш компьютер и отправляет прокси только IP, поэтому ваш DNS-резолвер видит каждый домен. При socks5h имя уходит на прокси, и уже он выполняет резолвинг. При socks5 все 11 прокси в нашем тесте оставляли DNS-запросы на стороне нашего резолвера.
- SOCKS5 поддерживает UDP?
- Протокол поддерживает, но большинство шлюзов нет. Из 11 протестированных нами прокси только 1 действительно передал UDP-пакет, ещё один принял запрос и затем отбросил пакеты, а остальные отказались.
- Можно ли использовать SOCKS5-прокси с логином в Chrome?
- Нет. Chrome не поддерживает аутентификацию SOCKS5, а Firefox принимает её только через расширения. Используйте HTTP-прокси с теми же логином и паролем, SOCKS5 с авторизацией по вашему IP-адресу или антидетект-браузер.
- SOCKS5 предотвращает утечки WebRTC?
- Нет. В Chromium WebRTC показывал реальный IP нашего сервера и с HTTP-прокси, и с SOCKS5. Это отключается флагом --force-webrtc-ip-handling-policy=disable_non_proxied_udp или расширением для WebRTC.
- Что лучше для веб-скрейпинга, SOCKS5 или HTTP?
- HTTP. Он подключается быстрее, поддерживается всеми библиотеками для скрейпинга без дополнительных настроек, а на HTTPS-сайтах цель видит один и тот же запрос в обоих случаях. Если используете SOCKS5, выбирайте socks5h, чтобы DNS шёл через прокси.



