Ретранслятор аутентификации SOCKS5 Proxy: создать или обойтись без него

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

Ретранслятор аутентификации SOCKS5 proxy — это небольшой локальный процесс, который отвечает на запрос прокси о вводе имени пользователя и пароля от вашего имени, а затем передает вашему инструменту простой, не требующий аутентификации, конечный пункт на 127.0.0.1. Он существует, чтобы закрыть упорный пробел: Chromium никогда не поддерживал аутентифицированный SOCKS5 (отслеживается как ошибка Chromium 40829748), и множество инструментов автоматизации принимают только голый host:port. Тема на Reddit, которая вызвала резонанс — кто-то настолько разочаровался, что создал маленький ретранслятор, потому что инструменты до сих пор не могли справиться с аутентифицированным SOCKS5 — это весь жанр в одном предложении. Это руководство показывает минимально работающий ретранслятор, готовые инструменты и, что не менее важно, когда он не нужен.

Шаблон: без аутентификации спереди, аутентифицированный сзади

Каждый ретранслятор в этой области делает одно и то же. Он слушает локально без аутентификации, и для каждого соединения открывает верхний участок с использованием ваших реальных учетных данных. Ваш инструмент подключается к 127.0.0.1 — пароль не нужен — и ретранслятор выполняет рукопожатие аутентификации SOCKS5 с шлюзом SOCKS5. Учетные данные хранятся в одном месте, на loopback, и никогда не касаются конфигурации инструмента. Это важно по второй причине: SOCKS5 не зашифрован и передает учетные данные в открытом виде, поэтому удержание аутентифицированного участка на вашем собственном компьютере, привязанного к 127.0.0.1, — это безопасный способ сделать это.

Ретранслятор в одну команду: gost

Вам редко нужно писать ретранслятор вручную. gost — это инструмент с открытым исходным кодом для туннелирования, который реализует полную спецификацию SOCKS5, включая аутентификацию по имени пользователя и паролю, и превращает всю работу в одну команду. Экспонируйте локально слушатель SOCKS5 без аутентификации и перенаправьте на ваш аутентифицированный верхний участок:

# local no-auth SOCKS5 on :1080  ->  authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT

# now point any tool at the loopback address, no credentials:
#   --proxy-server=socks5://127.0.0.1:1080   (Chrome, nodriver, zendriver)

Если ваш инструмент поддерживает HTTP, но не SOCKS5, та же команда конвертирует протоколы — экспонируйте локально HTTP proxy, который перенаправляет на аутентифицированный шлюз SOCKS5. Это чистый ответ на повторяющийся вопрос "конвертировать SOCKS5 в HTTP proxy", и он превосходит классическую конфигурацию Privoxy, потому что gost обрабатывает аутентификацию верхнего участка в одном месте:

# local HTTP proxy on :8080  ->  authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT

# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080

Минимальный ретранслятор с нуля

Если вы хотите понять движущие части, вот самая маленькая полезная версия на чистом Python. Она использует PySocks (pip install PySocks) для открытия аутентифицированного верхнего участка и передает байты в обе стороны. Этот конкретный набросок туннелирует один целевой хост — достаточно, чтобы скрапить один API через аутентифицированный выход SOCKS5 — что делает его коротким и правильным; общий сервер SOCKS5, который анализирует рукопожатие клиента, — это то, что инструменты, такие как gost, уже делают за вас:

import asyncio, socks   # PySocks

UP_HOST, UP_PORT = "gate.quantumproxies.io", 0000   # your SOCKS5 gateway
UP_USER, UP_PASS = "USER", "PASS"
TARGET = ("example.com", 443)                        # the one host to reach

async def pipe(reader, writer):
    try:
        while data := await reader.read(65536):
            writer.write(data)
            await writer.drain()
    finally:
        writer.close()

async def handle(local_r, local_w):
    # open the upstream leg with SOCKS5 auth (PySocks is blocking -> a thread)
    up = await asyncio.to_thread(
        socks.create_connection, TARGET,
        proxy_type=socks.SOCKS5, proxy_addr=UP_HOST, proxy_port=UP_PORT,
        username=UP_USER, password=UP_PASS,
    )
    up_r, up_w = await asyncio.open_connection(sock=up)
    await asyncio.gather(pipe(local_r, up_w), pipe(up_r, local_w))

async def main():
    server = await asyncio.start_server(handle, "127.0.0.1", 1080)
    async with server:
        await server.serve_forever()

asyncio.run(main())

Для полного локального сервера SOCKS5, на который может указывать любой клиент, проект сообщества socks-relay на GitHub — хорошая ссылка: он запускает слушатель без аутентификации или с user/pass и ретранслирует на другой сервер SOCKS5, в несколько сотен строк, построенных на PySocks. Проект socks-to-http-proxy (Rust) выполняет задачу конвертации HTTP, если вы предпочитаете скомпилированный бинарный файл. В любом случае, вы запускаете тот же шаблон, который gost дает вам в одной строке.

Когда вам НЕ нужен ретранслятор

Ретранслятор — это ваш собственный переход, и часто вы можете удалить всю проблему вместо этого. Обойдитесь без него, если выполняется любое из следующих условий:

• Ваш провайдер имеет HTTP конечный пункт. HTTP proxy аутентифицируются с помощью Basic auth в URL, который почти каждый инструмент обрабатывает. Укажите на HTTP шлюз, и головная боль с аутентификацией SOCKS5 исчезнет — компромиссы описаны в SOCKS5 против HTTP.
• Доступно белый список IP. Зарегистрируйте ваш выходной IP у провайдера, и учетные данные для ретрансляции вообще не нужны. Каждый план QuantumProxies поддерживает белый список наряду с user:pass на своих резидентных прокси — самое простое решение, когда ваш IP стабилен.
• Ваша библиотека уже поддерживает аутентификацию SOCKS5. curl, Python requests[socks] и httpx, и большинство HTTP клиентов поддерживают аутентифицированный SOCKS5 нативно. Ретранслятор нужен только для инструментов, которые не могут — в основном браузеры на базе Chromium.

# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip

# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip

Честный минус

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

Тот же шаблон ретранслятора встречается по всему скрытому экосистеме, потому что пробел SOCKS5 в Chromium разделяется каждым браузером, построенным на нем. Если вы подключаете это к конкретной структуре, смотрите аутентификация Playwright SOCKS5 и наш руководство по устранению ошибок 407 для ошибок, с которыми вы столкнетесь на этом пути.

Часто задаваемые вопросы

Что такое ретранслятор аутентификации SOCKS5 proxy?

Небольшой локальный процесс, который слушает без аутентификации и перенаправляет каждое соединение на верхний SOCKS5 proxy, используя ваше имя пользователя и пароль. Он позволяет инструментам, которые не могут отправить учетные данные SOCKS5 — в основном браузеры на базе Chromium — достичь аутентифицированного прокси, указывая на адрес loopback, такой как 127.0.0.1:1080. gost создает его одной командой.

Как конвертировать SOCKS5 proxy в HTTP proxy?

Вы не можете конвертировать сам прокси; вы запускаете посредник, который говорит HTTP локально и SOCKS5 на верхнем уровне. gost -L http://:8080 -F socks5://USER:PASS@host:port экспонирует локальный HTTP proxy, который перенаправляет на аутентифицированный шлюз SOCKS5. Специализированные инструменты, такие как socks-to-http-proxy и Privoxy, выполняют ту же задачу, если вы предпочитаете их.

Почему Chrome не может использовать аутентифицированный SOCKS5 proxy?

Chromium никогда не реализовывал аутентификацию по имени пользователя и паролю для SOCKS5 — это давнее ограничение, зарегистрированное как ошибка Chromium 40829748. Неаутентифицированный SOCKS5 работает через --proxy-server=socks5://host:port, но нет способа предоставить учетные данные. Локальный ретранслятор или белый список IP — это стандартное решение, а расширение для аутентификации proxy покрывает HTTP proxy.

Безопасно ли отправлять учетные данные SOCKS5 на ретранслятор?

Только через loopback. SOCKS5 не зашифрован и передает учетные данные в открытом виде, поэтому ретранслятор должен быть привязан к 127.0.0.1 и никогда к публичному интерфейсу — это удерживает аутентифицированный участок на вашем собственном компьютере. Зашифрованный туннель к цели устанавливается от конца до конца для HTTPS в любом случае, так что ретранслятор видит только байты TLS, которые он не может прочитать.

Обращайтесь к ретранслятору только тогда, когда инструмент не оставляет вам выбора. gost — это ответ в одну строку, PySocks — вариант с нуля — но самое быстрое решение для большинства людей — это белый список IP или использование HTTP конечного пункта и отсутствие дополнительных действий. Меньше движущихся частей, меньше ночных вызовов.

Получите SOCKS5 proxy с белым списком IP