Прокси с паролем без авторизации: локальный шлюз

Вы купили прокси, получили строку вида login:password@host:port, а программа просит только «адрес и порт». Знакомая ситуация: Chrome с флагом --proxy-server, системные настройки Windows и Android, старый парсер, Selenium-грид, утилита без поля для пароля. Решение одно и то же уже много лет — локальный шлюз: маленький прокси на вашей же машине, который принимает соединения без пароля и сам подставляет логин при подключении к настоящему прокси. Разбираем четыре проверенных инструмента, команды под каждый и ошибки, на которых обычно теряют время и деньги.

Почему программы «не понимают» прокси с паролем

Есть два способа авторизоваться у провайдера прокси: по логину и паролю (Basic Auth) или по белому списку IP. Второй вариант снимает проблему, но работает, только если у вас постоянный внешний IP — у домашнего интернета и мобильной сети его часто нет, а у облачных функций он меняется при каждом запуске. Подробно оба способа мы сравнивали в гайде по аутентификации прокси.

С логином и паролем упираемся в ограничения самих программ:

Chrome и Chromium. Флаг --proxy-server по документации Chromium принимает схему, хост и порт (например, --proxy-server="foopy:8080") — поля для учётных данных в этом синтаксисе нет. В обычном окне браузер покажет диалог с паролем, но в headless-режиме и в автотестах его некому заполнить.
Системные настройки. В ручной настройке прокси Windows и в настройках Wi-Fi на большинстве Android-прошивок есть только хост и порт. Пароль либо спросит конкретное приложение, либо его нигде не введёшь.
Старый и самописный софт. Многие утилиты и библиотеки поддерживают прокси, но без авторизации, или ломаются на спецсимволах в пароле.
Программы без поддержки прокси вообще. Консольные утилиты, которые не читают ни переменные окружения, ни настройки.

Локальный шлюз закрывает все четыре случая: программа видит прокси 127.0.0.1:8080 без пароля, а шлюз пересылает трафик к провайдеру уже с логином.

Как работает схема

На вашей машине (или VPS, где работает парсер) запускается лёгкий прокси-сервер и слушает локальный порт, например 127.0.0.1:8080.
В конфиге шлюза прописан «родительский» (upstream) прокси — адрес провайдера, логин и пароль.
Программа подключается к локальному порту без авторизации.
Шлюз открывает соединение к провайдеру, проходит авторизацию и прокидывает трафик дальше. Для сайта вы выглядите IP-адресом провайдера, а не своим.

HTTPS при этом не расшифровывается: через HTTP-прокси браузер устанавливает туннель методом CONNECT, и шлюз просто передаёт зашифрованные байты.

Вариант 1: gost — одна команда, без конфигов

gost (GO Simple Tunnel) — один исполняемый файл на Go для Windows, macOS и Linux. Это самый быстрый способ поднять шлюз. В gost флаг -L задаёт локальный сервис, -F — узел, через который пересылать трафик. Учётные данные указываются прямо в адресе узла:

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

Теперь любая программа может использовать HTTP-прокси 127.0.0.1:8080 без пароля. Если в пароле есть спецсимволы (@, :, #), документация gost предлагает передать их через параметр auth в base64:

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<результат_base64>

Учтите: если задан auth, логин и пароль, записанные прямо в адресе, gost игнорирует. Несколько флагов -F подряд образуют цепочку из нескольких прокси.

Когда брать: нужно быстро «подружить» один браузер или скрипт с прокси, без установки пакетов и правки конфигов.

Вариант 2: 3proxy — много портов на одной машине

3proxy — компактный прокси-сервер с конфигом в одном файле. Ключевая директива — parent; по документации её синтаксис: parent <weight> <type> <ip> <port> <username> <password>, и она должна стоять после правила allow. Минимальный конфиг шлюза:

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

Что здесь важно:

auth iponly — без пароля, но с проверкой по ACL; правило allow * 127.0.0.1 пускает только локальные подключения.
Вес 1000 означает «всегда через этого родителя». Веса меньше 1000 3proxy использует, чтобы собирать случайные цепочки.
Тип родителя: http, connect, socks4, socks5 и другие — берите тот протокол, который выдал провайдер.
-i127.0.0.1 привязывает сервис к локальному интерфейсу. По умолчанию 3proxy принимает соединения на всех интерфейсах.

Удобный приём: повторить блок allow / parent / proxy несколько раз с разными портами и разными учётками провайдера. Так получается «порт = отдельный прокси»: 127.0.0.1:8081 — США, :8082 — Германия и так далее. Этот формат понимает почти любой софт, включая тот, где прокси вводятся списком «хост:порт».

Когда брать: десятки профилей или потоков, каждому нужен свой выход.

Вариант 3: Squid — если нужен кэш и журнал

Squid тяжелее, зато даёт кэширование, подробные логи и гибкие ACL. Провайдер прописывается как родительский узел через cache_peer, а директива never_direct allow all запрещает Squid ходить в интернет напрямую в обход родителя:

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Нюансы из документации Squid:

Порт ICP ставят 0, если родитель его не поддерживает — у коммерческих прокси его нет.
В login= допускаются URL-escape последовательности (например, %20 для пробела), поэтому символ % в пароле нужно писать как %%.
Без never_direct Squid может решить, что выгоднее сходить к сайту напрямую, — и запрос уйдёт с вашего реального IP. Для парсинга и мультиаккаунтинга это худший сценарий.

Когда брать: офис или команда, где нужен журнал, кто куда ходил, или повторяющиеся запросы к одним и тем же ресурсам.

Вариант 4: proxychains-ng — для программ без поддержки прокси

Если программа не умеет прокси вообще, поможет proxychains-ng (Linux и macOS). Он перехватывает сетевые вызовы программы и заворачивает её TCP-соединения в прокси. Поддерживаются SOCKS4a, SOCKS5 и HTTP, авторизация — логин и пароль для SOCKS и Basic для HTTP. Строка в разделе [ProxyList] имеет формат тип ip порт [логин пароль]:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

Запуск: proxychains4 curl https://api.ipify.org — в ответе будет IP провайдера, а не ваш.

strict_chain — все прокси списка используются по порядку, и если один недоступен, соединения не будет. Безопаснее, чем dynamic_chain, который пропускает мёртвые узлы.
proxy_dns — DNS-запросы тоже уходят через прокси. Без этого провайдер вашего интернета видит, какие домены вы запрашиваете, а сайт может заметить несовпадение геолокации DNS и IP.
Конфиг ищется по порядку: файл из -f или переменной PROXYCHAINS_CONF_FILE, затем ./proxychains.conf, ~/.proxychains/proxychains.conf и /etc/proxychains.conf.

Ограничения, о которых пишут сами авторы: только TCP (UDP и ICMP не проксируются), возможны сбои у программ, порождающих много процессов, а на macOS защита SIP не даёт перехватывать системные программы.

Какой инструмент выбрать: короткая шпаргалка

Один браузер или скрипт, нужно «прямо сейчас» — gost.
Много профилей, у каждого свой IP или страна — 3proxy с отдельным портом на учётку.
Команда, журнал запросов, кэш — Squid.
Программа вообще без настроек прокси — proxychains-ng.

Пять ошибок, которые обходятся дороже всего

Шлюз слушает все интерфейсы. Запустили gost с -L http://:8080 на VPS — и получили открытый прокси для всего интернета на ваших гигабайтах. Открытые прокси сканеры находят быстро. Всегда указывайте 127.0.0.1, а если шлюзом пользуются другие машины — закрывайте порт фаерволом. Про то, как быстро ботнеты находят открытые порты на серверах с парсерами, мы писали в разборе червя CARBONATO.
Утечка мимо шлюза. Squid без never_direct, proxychains без proxy_dns, браузер, который ходит по WebRTC/UDP напрямую, — всё это раскрывает реальный IP. Проверяйте результат на сервисе определения IP и на тесте утечек DNS.
Один шлюз на все аккаунты. Если 30 профилей антидетекта смотрят в один порт с одной sticky-сессией, у всех будет один IP — это прямой путь к связке аккаунтов. Разводите профили по портам или используйте параметры сессии провайдера.
Спецсимволы в пароле. @ и : ломают разбор адресов вида login:pass@host. Используйте base64-параметр в gost, экранирование в Squid или сгенерируйте пароль без спецсимволов.
Шлюз — лишний хоп и точка отказа. На локальной машине задержка почти нулевая, но если шлюз стоит в другом дата-центре, к каждому запросу добавляется сетевая задержка. Держите шлюз рядом с программой и настройте автозапуск (systemd, служба Windows), иначе после перезагрузки сервера парсер тихо пойдёт в никуда.

Какие прокси ставить за шлюзом

Шлюзу всё равно, какой тип прокси стоит за ним, — выбор зависит от задачи:

Резидентные прокси — для парсинга защищённых сайтов, маркетплейсов и антидетект-профилей: IP домашних пользователей вызывают меньше подозрений у антиботов.
Мобильные прокси — для соцсетей и приложений, где проверка строже всего: за одним IP мобильного оператора (через CGNAT) обычно выходят в сеть многие реальные абоненты, и блокировать его рискованно для самой площадки.
Прокси дата-центров — для объёмных задач без строгой защиты: проверки доступности, API, тестов. Дешевле всего за гигабайт.

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

Итог

Прокси с логином и паролем подходит любой программе, если поставить между ними локальный шлюз. gost решает задачу одной командой, 3proxy удобен для «порт = профиль», Squid — для команд с журналом, а proxychains-ng подключает к прокси даже софт, который о прокси ничего не знает. Главные правила: слушать только 127.0.0.1, запрещать прямые соединения в обход родителя и проверять, что сайт видит IP провайдера, а не ваш.