HTTP, HTTPS и SOCKS5-прокси: в чём разница

Названия HTTP, HTTPS и SOCKS5 часто ставят в один ряд, хотя они описывают разные части соединения. Ни один вариант не является автоматически самым быстрым, безопасным или подходящим для любой программы: сначала нужно понять, какой трафик передаёт клиент и какие режимы он действительно поддерживает.

Что именно называют протоколом прокси

В настройках программ «протоколом прокси» обычно называют способ, которым клиент обращается к прокси-серверу. HTTP-прокси работает на прикладном уровне с HTTP-запросами: клиент отправляет ему запрос к веб-ресурсу, а прокси устанавливает соединение с целевым сервером и возвращает ответ.

SOCKS5 работает ниже прикладной семантики HTTP. Он получает команды на установление соединения и передаёт поток данных, не разбирая его как HTTP-запрос. Поэтому SOCKS5 подходит не только для веб-клиентов, если приложение умеет работать с SOCKS.

Термин «HTTPS-прокси» неоднозначен. Так могут называть HTTP-прокси, через который методом CONNECT открывают HTTPS-сайты, либо прокси, где соединение клиент → прокси само защищено TLS. Эти варианты нельзя считать одним и тем же режимом.

Сравнение HTTP, HTTPS и SOCKS5

Таблица разделяет свойства целевого HTTPS-соединения и канала до прокси. Конкретная реализация клиента или сервиса может вводить дополнительные ограничения.

Как работает HTTP-прокси

При обычном HTTP-запросе клиент сообщает прокси метод, адрес ресурса, заголовки и тело запроса. Прокси может просто переслать запрос, а при соответствующей реализации — применить правила доступа, изменить заголовки или использовать кэш. Наличие этих функций зависит от конкретного ПО: сам термин HTTP proxy их не гарантирует.

Ошибочно считать, что каждый HTTP-запрос обязательно создаёт новую TCP-сессию. HTTP/1.1 поддерживает persistent connections, поэтому несколько запросов могут последовательно использовать одно соединение. HTTP/2 поддерживает multiplexing: несколько потоков могут одновременно передаваться по одному HTTP/2-соединению, если эта версия согласована на соответствующем участке. Клиент, прокси и целевой сервер могут использовать разные версии HTTP на разных участках пути.

Обычный HTTP не шифрует содержимое. Для защищённого веб-доступа используется TLS целевого сайта, обычно внутри туннеля CONNECT.

HTTPS-сайты, CONNECT и защищённый канал

Чтобы открыть HTTPS-сайт через HTTP-прокси, клиент обычно отправляет запрос CONNECT example.com:443. Прокси устанавливает TCP-соединение с указанным адресом и после успешного ответа передаёт байты в обе стороны. Затем клиент выполняет TLS-рукопожатие с целевым сайтом внутри туннеля.

HTTPS целевого сайта означает TLS между клиентом и сайтом через туннель. При обычном CONNECT прокси не завершает этот TLS-сеанс и не получает открытое содержимое HTTPS-запросов. При этом прокси видит служебные данные соединения, включая адрес назначения; отдельные системы TLS-инспекции работают иначе и требуют специальной настройки доверия.

Если сервис называет подключение «HTTPS proxy», нужно уточнить, что именно защищено. Использование CONNECT для HTTPS-сайтов само по себе не доказывает наличие TLS на участке клиент → прокси до создания туннеля. Этот участок шифруется только тогда, когда и сервис, и клиент явно поддерживают TLS-соединение с прокси.

Для современных защищённых соединений используется термин TLS, а не устаревшее SSL. HSTS — это политика браузера, которая требует обращаться к определённому сайту по HTTPS. Она не является альтернативой SOCKS5 и не относится к выбору прокси-протокола.

Как работает SOCKS5

Клиент SOCKS5 сначала согласует с прокси способ авторизации, затем передаёт команду и адрес назначения. Команда CONNECT создаёт TCP-соединение, после чего прокси передаёт поток приложения без интерпретации HTTP-методов и заголовков.

Стандарт SOCKS5 также предусматривает UDP ASSOCIATE для передачи UDP-датаграмм через связанный UDP-relay. Это возможность протокола, а не обещание работы в любой конфигурации: UDP должен поддерживаться приложением, сетевой библиотекой и самим прокси-сервисом.

SOCKS5 сам по себе не шифрует трафик, не защищает от атак и не гарантирует анонимность. Содержимое защищается только протоколом приложения или дополнительным защищённым каналом. Способы авторизации SOCKS5 тоже различаются, а поддержка логина и пароля в браузере может зависеть от браузера, операционной системы и расширения.

DNS через прокси: локальное и удалённое разрешение

До подключения доменное имя нужно преобразовать в IP-адрес. При локальном разрешении это делает устройство пользователя через настроенный DNS-resolver, а прокси получает уже готовый IP. При удалённом разрешении клиент передаёт прокси имя хоста, и адрес определяет сторона прокси.

В SOCKS-клиентах эти режимы нередко обозначаются по-разному. Например, в cURL схема socks5:// обычно означает локальное разрешение, а socks5h:// — передачу имени прокси. В других программах используются параметры remote DNS или proxy DNS, поэтому поведение нужно проверять по документации конкретного клиента.

HTTP-прокси также может выполнять DNS-разрешение, если получает имя хоста в HTTP-запросе или CONNECT. Если приложение заранее подставляет IP-адрес, DNS уже был выполнен локально. Следовательно, фраза «DNS всегда идёт через SOCKS5» технически неверна.

Какой протокол выбрать для своей задачи

Выбор начинается не с общего рейтинга протоколов, а с документации программы и требуемого типа трафика.

HTTP/CONNECT

• браузеры и HTTP-клиенты;
• веб-запросы и HTTP API;
• инструменты, в которых предусмотрена настройка HTTP proxy;
• HTTPS-сайты, если клиент и прокси поддерживают CONNECT.

SOCKS5

• приложения с нативной поддержкой SOCKS;
• произвольные TCP-соединения;
• сценарии, где требуется DNS-разрешение на стороне прокси;
• UDP — только при фактической поддержке клиента и прокси-сервиса.

Для приложений критична реальная поддержка HTTP CONNECT или SOCKS5, включая нужный способ авторизации. Протокол не следует выбирать по обещанию универсального ускорения или защиты: скорость зависит от маршрута, нагрузки и реализации, а безопасность — от TLS и настроек приложения.

Что важно при использовании мобильных прокси

В интерфейсе LTESpace доступны HTTPS и SOCKS5. Выбор зависит от поддержки конкретной программы или браузера.

Посмотреть доступные варианты подключения можно на сайте мобильных прокси LTESpace. При длительной работе также важно согласовать протокол со стратегией ротации IP, чтобы смена адреса не прерывала активную сессию.

Целевой сайт обычно видит выходной IP и ASN, параметры TLS/HTTP fingerprint, заголовки, географию, частоту запросов и поведенческие признаки клиента. Протокол на участке клиент → прокси обычно завершается на прокси и не является прямым сигналом для целевого сайта. При этом настройки клиента могут косвенно менять видимый сетевой и HTTP-профиль.

Поэтому для мобильных прокси важнее качество и география выходного IP, оператор и ASN, стабильность сессии, корректная ротация, совместимость приложения и последовательное поведение запросов. SOCKS5 сам по себе не повышает доверие сайта и не обеспечивает «антифрод-устойчивость», а выбор другого протокола автоматически не вызывает и не отменяет проверки.

Частые вопросы