Авторизация прокси: привязка своего адреса и доступ по логину с паролем

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

Оба способа входят в пакет, переключаться между ними можно в любой момент и без доплаты. Ниже разобрано, как устроен каждый, где именно вводится строка в браузере, в curl и в прикладных программах, что делать при меняющемся адресе провайдера, почему привязок в пакете две и как при двух привязках делится лимит потоков. Отдельным разделом идут коды ошибок, по которым способ доступа опознаётся с первого запроса.

Два способа доступа: где живёт проверка права

Разница между способами сводится к одному вопросу: по какому признаку выходной узел узнаёт своего клиента. Мы держим на узлах обе проверки одновременно, поэтому клиент сам выбирает удобный ему порядок.

При привязке узел смотрит на адрес источника входящего соединения и сверяет его со списком, который клиент завёл в кабинете. Совпало, соединение принято. Не совпало, соединение закрывается ещё до обмена по протоколу HTTP. Такой список принято называть whitelist по IP, и вся проверка укладывается в одно сравнение.

При доступе по логину узел ждёт учётные данные внутри протокола. В HTTP они приезжают заголовком Proxy-Authorization, в SOCKS5 отдельным шагом рукопожатия. Пока пары нет, узел отвечает кодом 407 и держит соединение открытым, ожидая повтора запроса уже с данными.

Мы выдаём оба формата в одном разделе кабинета, поэтому смена способа доступа сводится к переключателю в настройках. Многие наши клиенты держат оба варианта сразу: сервер работает по привязке, ноутбук ходит по логину. Ограничений на такое сочетание нет, доплаты за второй формат тоже.

Привязка своего адреса: как она устроена изнутри

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

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

# внешний адрес рабочей машины
curl -s https://ifconfig.me
curl -s https://api.ipify.org

# то же самое из PowerShell на Windows
(Invoke-RestMethod https://api.ipify.org)

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

Удобство привязки в том, что учётные данные вообще нигде не хранятся. Строка подключения короткая, её видно целиком в любом поле настроек, случайно испортить нечего. Программы, которые плохо переваривают пару логина и пароля в строке, работают с таким форматом без единой правки: конфигурация сводится к адресу и порту. Именно поэтому серверные скрипты, планировщики и системные утилиты обычно ставят на привязку.

Второе удобство касается журналов. При привязке в конфигурационных файлах и в командах истории оболочки не остаётся ничего, кроме адреса и порта. Администратор копирует команду коллеге, выкладывает фрагмент конфигурации в задачу трекера и ничего при этом не раскрывает.

Есть у привязки и естественная граница применения. Проверка держится на адресе источника, поэтому запросы должны уходить с той машины, которая записана в кабинете. Мы смотрим на это так: привязка отлично закрывает стационарную инфраструктуру, где адрес известен заранее и держится месяцами, а вся подвижная часть парка переводится на второй способ. Наши пакеты дают оба варианта сразу, и распределять машины между ними можно как угодно.

Доступ по логину и паролю: как он устроен

Логин и пароль приходят вместе со списком в формате IP:PORT:LOGIN:PASS. Пара одна на пакет, она подставляется ко всем адресам списка сразу, и это упрощает работу: сменился набор выходных узлов, учётные данные остались прежними.

В HTTP обмен выглядит так. Программа отправляет запрос, узел отвечает 407 Proxy Authentication Required и заголовком Proxy-Authenticate: Basic, программа повторяет запрос уже с заголовком Proxy-Authorization: Basic <base64 логина и пароля>. Дальше туннель поднимается методом CONNECT, и весь дальнейший обмен идёт внутри него.

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk
< HTTP/1.1 200 Connection established

В SOCKS5 порядок другой и короче. Клиент присылает список поддерживаемых методов аутентификации, узел выбирает метод с номером 02, клиент отправляет логин и пароль отдельным пакетом, узел подтверждает и переходит к передаче данных. Никаких заголовков, весь обмен идёт на уровне самого протокола. Подробности сокетного варианта разобраны на странице, где можно подключить прокси SOCKS5 к программам.

Главное практическое достоинство этого способа: машина может быть любой. Ноутбук в дороге, виртуальный сервер у стороннего хостинга, облачный сборщик, чужой компьютер на проекте у заказчика. Адрес источника при этом никого не интересует, потому что право на доступ приезжает вместе с запросом.

Форматы IP:PORT и IP:PORT:LOGIN:PASS в реальном списке

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

# формат под привязанный адрес
185.24.87.14:8000
185.24.87.15:8000
185.24.87.16:1080

# формат с учётными данными
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd
185.24.87.16:1080:user5521:pf39kd

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

Список адресов обновляется в режиме реального времени, пул держится в районе 12 000 активных адресов. Практический вывод такой: перед крупным прогоном список перечитывается заново. Способ доступа при этом не меняется, меняется только набор строк. Разбор строки подключения по полям, вместе с портами и протоколами, вынесен в отдельный материал про строку подключения.

Где вводится каждый вариант: браузер, curl, программы

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

Браузер

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

# запуск Chromium с явным указанием посредника
chrome.exe --proxy-server="http://185.24.87.14:8000"
chrome.exe --proxy-server="socks5://185.24.87.16:1080"

Ключ командной строки принимает адрес и порт, учётные данные через него не передаются, поэтому запуск с ключом удобнее сочетать с привязкой. Когда рабочих профилей несколько и каждому нужен свой выход, вопрос закрывают браузерные профили с полями логина и пароля прямо в карточке профиля, как это устроено в браузере Dolphin Anty.

curl и командная строка

В curl оба варианта пишутся одной строкой. Ключ -x задаёт посредника целиком, ключ -U выносит пару отдельно, что удобнее для скриптов с переменными.

# доступ по привязанному адресу
curl -x http://185.24.87.14:8000 https://ifconfig.me

# доступ по логину, учётные данные внутри ключа -x
curl -x http://user5521:[email protected]:8000 https://ifconfig.me

# то же самое, пара вынесена отдельно
curl -x http://185.24.87.14:8000 -U user5521:pf39kd https://ifconfig.me

# SOCKS5 с разрешением имён на стороне выхода
curl --socks5-hostname 185.24.87.16:1080 -U user5521:pf39kd https://ifconfig.me

Переменные окружения работают в том же ключе и подхватываются большинством консольных утилит, включая wget, git и пакетные менеджеры.

export http_proxy="http://user5521:[email protected]:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1"

Прикладные программы и код

Парсеры и сборщики обычно принимают строку целиком в поле настроек. A-Parser и ZennoPoster читают файл со списком и понимают оба формата, антидетект-браузеры просят разложить строку по четырём полям. В коде картина такая же.

import requests

proxies = {
    "http":  "http://user5521:[email protected]:8000",
    "https": "http://user5521:[email protected]:8000",
}
r = requests.get("https://ifconfig.me", proxies=proxies, timeout=15)
print(r.status_code, r.text)

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

Меняющийся адрес провайдера: порядок действий

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

Вариантов действий два, и оба рабочие.

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

Второй: перейти на формат с логином и паролем. Тогда адрес источника перестаёт участвовать в проверке совсем, и работа продолжается при любых перестановках у оператора связи. Список в нужном формате берётся в том же разделе кабинета.

Две привязки в пакете и деление лимита потоков

В стоимость пакета входит одновременная привязка 2 адресов. Типовой сценарий она закрывает целиком: рабочая станция и сервер, офис и домашний кабинет сотрудника, основная машина и резервная. Менять записи разрешено свободно, без ограничений по числу правок.

Одна деталь напрямую влияет на расчёт нагрузки, и её стоит держать в голове с самого начала. При двух привязанных адресах общий лимит потоков делится между ними пополам. Пакет на 1000 потоков при двух заполненных записях даёт по 500 потоков на каждый адрес.

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

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

Ошибки неверного способа доступа: 407 и отказ соединения

По ответу узла способ доступа опознаётся с первой попытки, потому что ошибки у двух вариантов принципиально разные.

Код 407 приходит тогда, когда узел ждёт пару логина и пароля. Соединение при этом установлено, обмен по протоколу начался, узел прямо сообщает, чего ему недостаёт. Частые причины: список взят в коротком формате, пара потеряна при копировании, программа разложила строку по полям неверно, пароль содержит символ, который требует кодирования в адресной строке.

# так выглядит 407 в подробном выводе curl
curl -v -x http://185.24.87.14:8000 https://example.com
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="proxy"

Отказ соединения выглядит иначе. Ответа нет вовсе, curl завершается с ненулевым кодом за доли секунды. Это признак того, что узел ждал привязанный адрес и не нашёл источник в списке доступа. Вторая возможная причина: запрос ушёл с той машины, которую в кабинет вписать забыли.

curl -x http://185.24.87.14:8000 https://example.com
# curl: (56) Recv failure: Connection reset by peer
echo $?   # 56

Подробный разбор именно кода 407, со всеми частными случаями программ и форматов, вынесен в отдельную статью про ошибку 407. Здесь достаточно запомнить простое правило: 407 говорит про недостающую пару, мгновенный обрыв говорит про адрес вне списка.

Отдельная история это пароль со спецсимволами. Знак решётки, косая черта, вопросительный знак и амперсанд внутри адресной строки разбираются как служебные, и программа обрезает пару в неожиданном месте. Мы разбираем такие обращения постоянно, лечится это двумя путями: пара выносится в отдельные поля программы либо символы кодируются процентной записью. В curl проще всего использовать ключ -U, там строка читается целиком и никакого разбора адреса не происходит.

Ещё один случай выглядит совсем безобидно: запрос проходит, код 200 приходит, а на выходе виден прежний адрес машины. Значит, программа обошла настройки посредника стороной. Мы проверяем это первым делом при разборе жалоб на неработающий доступ: сравниваем адрес прямого запроса и адрес запроса через выход. Полный список портов и протоколов, которые принимают наши узлы, собран там, где оформляется доступ к пулу IPv4 и SOCKS5, а разбор форматов авторизации для браузерного трафика лежит на странице про прокси HTTP с авторизацией по паре логина и пароля.

Смена привязки в кабинете и переключение между способами

Все правки делаются в одном разделе кабинета. Открывается список пакетов, выбирается нужный, внутри лежат поля привязанных адресов и переключатель формата выдачи. Порядок действий короткий.

1. Узнать текущий внешний адрес машины запросом к сервису эха. 2. Открыть настройки пакета в кабинете. 3. Вписать адрес в свободное поле привязки либо заменить прежнее значение. 4. Сохранить и подождать применения, обычно это меньше минуты. 5. Проверить доступ запросом через любой адрес из списка.

Переключение на логин и пароль делается тем же порядком: в разделе выдачи выбирается формат IP:PORT:LOGIN:PASS, список перечитывается, учётные данные подставляются в программу. Прежние привязки при этом можно оставить, они мешать не будут: узел примет соединение по любому из двух признаков.

# короткая проверка после любой правки доступа
curl -sS -o /dev/null -m 15 -w 'code=%{http_code} time=%{time_total}\n' \
  -x http://185.24.87.14:8000 https://api.ipify.org

Ответ code=200 с разумным временем отклика означает, что доступ настроен верно. Пакет включается примерно за 5 минут после оплаты, и первая проверка делается сразу после включения, до запуска рабочего прогона. Мы советуем прогонять эту команду каждый раз после правки настроек: она занимает секунду и снимает половину вопросов заранее.

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

Сколько адресов можно привязать к пакету?

В стоимость пакета входит одновременная привязка 2 адресов. Менять записи разрешено без ограничений прямо в настройках кабинета. При двух привязанных адресах общее число потоков делится между ними пополам, поэтому вторую запись стоит заполнять тогда, когда работа действительно идёт с двух машин.

Что делать при динамическом адресе провайдера?

Привязанный адрес можно менять без ограничений прямо в настройках кабинета, правка занимает секунды. Второй путь: взять список в формате IP:PORT:LOGIN:PASS и работать по логину, тогда адрес источника в проверке не участвует вовсе. Оба формата доступны в одном разделе кабинета и входят в пакет.

В каком формате выдаётся список прокси?

Форматов два на выбор: IP:PORT для работы по привязанному адресу и IP:PORT:LOGIN:PASS для доступа по логину с паролем. Забрать список можно двумя путями: получить ссылку либо скачать файл. Список обновляется в режиме реального времени, поэтому перед крупным прогоном его стоит перечитать.

Как подключиться к прокси после покупки?

Всё делается в кабинете: после регистрации и покупки указывается свой адрес в настройках либо берётся формат с логином. Пакет включается примерно за 5 минут, после чего раздел выдачи начинает отдавать список. Перед покупкой доступен бесплатный тест до 2 часов, и настройку доступа удобно пройти именно в нём, вместе с оператором.

Тему продолжают соседние материалы раздела: что такое прокси IPv4 с разбором пути запроса по шагам, приватный доступ и общий пул про устройство доступа к адресам, сколько адресов нужно под задачу с расчётом по потокам. Практическую часть закрывает статья про первое подключение по шагам, от оплаты до рабочего запроса.