Мой дэйли дайджест

одно техническое понятие в день

SOCKS5

17 сентября 2026 · ~13 мин чтения

протокол сеть прокси приватность инструмент

SOCKS5

SOCKS5 — сетевой протокол, по которому программа просит посредника («прокси») установить TCP-соединение с нужным адресом и дальше просто перегоняет байты в обе стороны. Он ничего не знает о содержимом трафика: ни про HTTP, ни про почту, ни про игры — он работает на уровень ниже, чем сами протоколы приложений.

История

SOCKS родился в начале 1990-х внутри корпоративных сетей, когда появилась массовая проблема: компания ставит firewall (межсетевой экран), и вдруг ни одна внутренняя машина не может выйти наружу. Для каждого протокола писать свой шлюз — безумие: отдельный шлюз для FTP, отдельный для telnet, отдельный для почты. Хотелось один универсальный «пропускной пункт».

Статус сегодня: SOCKS5 — стабильный интернет-стандарт без владельца. Порт по умолчанию — 1080 (IANA закрепила имя socks за ним). Ни один вендор его не контролирует, и именно поэтому он повсюду: от ssh -D до Tor.

Что это такое

Представь, что твоя программа хочет открыть TCP-соединение с example.com:443. Обычно она сама делает connect(). С SOCKS5 она вместо этого коннектится к прокси (скажем, 127.0.0.1:1080), говорит короткую служебную фразу: «версия 5, вот как я умею авторизоваться», при необходимости предъявляет логин и пароль, а потом — «CONNECT на example.com, порт 443». Прокси сам устанавливает соединение наружу, отвечает «готово», и с этого момента канал становится прозрачным: всё, что клиент пишет в сокет, попадает на example.com, и наоборот.

Ключевое слово — прозрачным. Прокси не парсит HTTP-заголовки, не подставляет X-Forwarded-For, не кэширует, не переписывает. Он труба.

Сравнения, которые важно держать в голове:

SOCKS5 vs HTTP-прокси. HTTP-прокси понимает HTTP: он видит URL, заголовки, может кэшировать, логировать, резать по домену. Для HTTPS он использует метод CONNECT и там тоже превращается в трубу — но только для того, что похоже на веб. SOCKS5 универсален: через него ходит IMAP, SSH, BitTorrent, игровой трафик, что угодно с TCP. Зато HTTP-прокси гораздо лучше поддержан в софте (особенно в браузерах) и умеет аутентификацию, которую понимают все.

SOCKS5 vs VPN. VPN работает на уровне сетевого интерфейса: весь трафик всей машины уходит в туннель, включая DNS и UDP, и приложение об этом не знает. SOCKS5 — на уровне приложения: туда идёт только тот софт, которому ты явно сказал. Это одновременно плюс (выборочность, ноль прав администратора) и минус (кто не настроен — тот утекает мимо).

SOCKS5 vs SOCKS4. Пятая версия добавила три вещи: аутентификацию (RFC 1929), IPv6 (ATYP = 0x04), и UDP через команду UDP ASSOCIATE. Плюс штатную передачу доменного имени (ATYP = 0x03), которая в четвёртой была костылём SOCKS4a.

SOCKS5 сам по себе не шифрует. Совсем. Если ты ходишь через него по HTTP, всё видно и прокси, и его провайдеру. Приватность даёт TLS внутри (то есть HTTPS) или обёртка вроде SSH-туннеля или Shadowsocks. SOCKS5 меняет только то, с какого IP выходит соединение.

Аналогии из жизни

Курьер-«купи-передай». Ты звонишь курьеру: «съезди в такой-то магазин, купи вот это». Он едет, продавец видит курьера, а не тебя. Ты остаёшься дома.
Где работает: адрес назначения знает только курьер, магазин видит его лицо и его район.
Где ломается: курьеру ты называешь адрес вслух — то есть прокси знает, куда ты идёшь, и знает, что это ты. SOCKS5 не анонимизирует тебя перед самим прокси. Плюс курьер может подсмотреть в пакет, если он не запечатан — то есть если внутри не TLS.

Стрелочник на железной дороге. Он не заглядывает в вагоны, ему всё равно, везут уголь или пассажиров — его дело перевести стрелку на нужный путь.
Где работает: отлично передаёт «протокол-агностичность» — SOCKS5 всё равно, что за трафик.
Где ломается: стрелочник переводит состав один раз и забывает о нём; SOCKS5-прокси, наоборот, держит соединение всё время жизни и гоняет через себя каждый байт в обе стороны. Он не разовая развилка, а постоянный участник.

Дежурный на проходной бизнес-центра. Ты подходишь, показываешь пропуск (аутентификация), говоришь, к кому идёшь, он звонит и проводит.
Где работает: точно передаёт последовательность: сначала переговоры и проверка, потом доступ.
Где ломается: на проходной ты дальше идёшь сам, а в SOCKS5 дежурный ходит вместо тебя и пересказывает разговор. И ещё: в реальном здании есть пожарные выходы — трафик может утечь мимо проходной (привет, UDP и WebRTC). У настоящей проходной такого нет, и это как раз самая опасная часть аналогии.

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

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

Шаг 1. Приветствие. Клиент шлёт: версия (0x05), сколько методов аутентификации знает, и список методов. Самые ходовые: 0x00 — без аутентификации, 0x02 — логин/пароль.

клиент → прокси:  05 02 00 02       (v5, 2 метода: no-auth и user/pass)
прокси → клиент:  05 02             (выбираю user/pass)

Если прокси не устраивает ни один метод, он отвечает 05 FF и рвёт соединение.

Шаг 2. Аутентификация (если выбран 0x02, по RFC 1929). Формат: версия подпротокола 0x01, длина логина, логин, длина пароля, пароль. Ответ — 0x01 и статус, где 0x00 значит «пустили».

Пароль летит открытым текстом

RFC 1929 не шифрует и даже не хэширует пару логин/пароль — это буквально байты в TCP-потоке. Если канал до самого прокси не защищён, креды видны любому на пути. Поэтому авторизованный SOCKS5 уместен внутри доверенной сети или поверх SSH, а не «через весь интернет по привычке».

Шаг 3. Запрос. Клиент говорит, чего хочет:

05 01 00 03 0B example.com 01BB
│  │  │  │  │  │           └── порт 443, 2 байта big-endian
│  │  │  │  │  └── само имя хоста
│  │  │  │  └── длина имени (11)
│  │  │  └── ATYP: 01=IPv4, 03=доменное имя, 04=IPv6
│  │  └── RSV: зарезервированный ноль
│  └── CMD: 01=CONNECT, 02=BIND, 03=UDP ASSOCIATE
└── версия 5

Шаг 4. Ответ. Прокси пробует подключиться и отвечает похожей структурой, где второй байт — код результата: 0x00 — успех, 0x03 — сеть недоступна, 0x04 — хост недоступен, 0x05 — соединение отвергнуто, 0x07 — команда не поддерживается. Дальше идут BND.ADDR/BND.PORT — адрес, с которого прокси вышел наружу.

Шаг 5. Данные. Никакого обрамления. Чистый двунаправленный поток байтов до закрытия.

Три команды стоит различать:

Отдельный практический сюжет — кто резолвит DNS. Если клиент сам превращает example.com в IP и шлёт ATYP=0x01, то DNS-запрос ушёл с твоей машины, с твоего IP — и наблюдатель видит, куда ты собрался, даже если само соединение прошло через прокси. Если клиент шлёт ATYP=0x03 (имя), резолвит прокси, и утечки нет. В curl это ровно разница между --socks5 и --socks5-hostname, а в URL-схемах — между socks5:// и socks5h://. Буква h значит «hostname через прокси». Дешёвый способ проколоться на пустом месте.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Альтернативы и конкуренты

HTTP-прокси (метод CONNECT).
Плюсы: поддержан абсолютно везде, включая браузеры; аутентификация логин/пароль работает без плясок; умеет фильтровать и логировать по домену.
Минусы: только TCP и по сути только веб-трафик; посредник видит домен даже в HTTPS (через SNI и строку CONNECT).

VPN (WireGuard, OpenVPN, IPsec).
Плюсы: заворачивает весь трафик машины, включая UDP и DNS; никаких «настрой каждое приложение»; шифрует по умолчанию.
Минусы: требует прав администратора и установки; всё или ничего (split tunneling настраивается отдельно и болезненно); легче детектируется и блокируется.

Shadowsocks / V2Ray / Xray.
Плюсы: зашифрованный транспорт, маскировка под обычный трафик, а локально — тот же удобный SOCKS5-порт; создавался (Китай, ~2012, автор под ником clowwindy) именно против цензуры.
Минусы: нужен свой сервер; экосистема фрагментирована, форков много, документация неровная.

MASQUE / CONNECT-UDP (RFC 9298, 2022).
Плюсы: современная замена, умеет проксировать UDP и QUIC поверх HTTP/3, уже используется Apple iCloud Private Relay.
Минусы: молодая, поддержки в обычном софте почти нет — пока это про инфраструктуру, а не про «настроил у себя за пять минут».

Когда НЕ стоит использовать

Самая дорогая ошибка — не в протоколе, а в проверке

Health-check «прокси жив» по коду ответа 200 ничего не доказывает: если соединение проскочило мимо прокси напрямую, сервис-определитель IP тоже вернёт 200 — просто с твоим настоящим адресом. Проверять надо содержимое ответа: совпадает ли увиденный IP с ожидаемым IP прокси. Разница между «запрос удался» и «запрос ушёл оттуда, откуда я думаю» стоит часов отладки.

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера разбирался с одним из автоматизационных агентов: ему понадобилось выходить в сеть с московских IP, и всплыл старый мостик — локальный скрипт, который поднимает у себя HTTP-прокси без пароля и внутри логинится в настоящий авторизованный SOCKS5 провайдера. Написан он был ровно из-за того, что Chromium не умеет авторизованный SOCKS5. В итоге выяснилось, что купленные точки оказались HTTP-прокси, а не SOCKS5, и мост вообще не понадобился. Зато дальше был целый день охоты за «утечкой IP» — проверяли гипотезы про WebRTC и QUIC, а причина оказалась в собственной проверке живости прокси, которая смотрела только на код ответа.

Краткое резюме