Аутентификация прокси: логин и пароль или IP whitelist?

Аутентификация прокси нужна, чтобы прокси-сервер понял, кто к нему подключается, и отказал тем, у кого нет доступа. Способов два. При аутентификации по логину и паролю клиент передаёт учётные данные при каждом подключении. При IP whitelist (белом списке IP) прокси смотрит на публичный IP-адрес, с которого пришло соединение, и пускает адреса из списка без пароля.

Если ваш IP часто меняется или вы работаете с прокси с нескольких устройств, берите логин и пароль. Если код работает на сервере со статическим IP или программа не умеет передавать пароль, удобнее IP whitelist. В примерах используется адрес шлюза WeProxy gw.weproxy.com.tr:8989; USER и PASSWORD — ваши данные из личного кабинета.

Что такое аутентификация прокси и как она работает?

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

Для HTTP-прокси порядок описан в RFC 9110. Если клиент подключается без учётных данных, прокси отвечает 407 Proxy Authentication Required с заголовком Proxy-Authenticate. Клиент повторяет запрос, теперь уже с заголовком Proxy-Authorization: Basic .... В схеме Basic пара логин:пароль только кодируется в Base64, но не шифруется (RFC 7617).

В SOCKS5 клиент сначала перечисляет методы, которые он поддерживает (RFC 1928). 0x00 означает подключение без аутентификации, 0x02 — по логину и паролю. Если прокси выбирает 0x02, логин и пароль уходят открытым текстом в отдельном субсогласовании по RFC 1929. При IP whitelist прокси принимает 0x00: решение по IP источника он уже принял.

IP whitelist от протокола не зависит. Прокси сверяет адрес, с которого пришло TCP-соединение, со списком в личном кабинете. Есть адрес в списке — соединение принимается. Нет — в HTTP вы получите 407, в SOCKS5 отклонённый метод (0xFF) или закрытое соединение.

Как пользоваться прокси с логином и паролем?

Учётные данные дописываются в адрес прокси или вводятся в отдельные поля программы. В cURL работают оба варианта:

curl -x "http://USER:[email protected]:8989" https://api.ipify.org
curl -x "http://gw.weproxy.com.tr:8989" -U "USER:PASSWORD" https://api.ipify.org

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

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

Второе ограничение: некоторые программы учётные данные вообще не принимают. Флаг Chrome --proxy-server не читает часть user:pass@, а SOCKS5-прокси с логином и паролем Chrome не поддерживает. В системных настройках прокси Windows и Android есть только поля для хоста и порта. Для прокси с паролем в браузере можно поставить официальное расширение; настройка описана на странице интеграции с Chrome. Если в пароле есть символы вроде @ или :, в формате URL их нужно закодировать процентным кодированием. Правила записи собраны в руководстве по форматам прокси.

Что такое IP whitelist и как он работает?

Вместо пароля вы добавляете в личный кабинет свой публичный IP-адрес. Подключения с этого адреса прокси принимает без пароля, а строка прокси сокращается до host:port:

curl -x "http://gw.weproxy.com.tr:8989" https://api.ipify.org

Добавлять нужно не локальный адрес компьютера (192.168.x.x, 10.x.x.x). Прокси видит только публичный адрес, с которым вы выходите в интернет. Узнать его можно на том устройстве, где будет работать прокси: при выключенном прокси откройте инструмент My IP или выполните команду:

curl https://api.ipify.org     # ваш публичный IPv4
curl https://api64.ipify.org   # ваш IPv6, если он есть

Если сервер подключается к шлюзу по IPv6, в списке должен быть IPv6-адрес; когда там только IPv4, соединение будет отклонено. В облаке внутренний адрес машины, на которой работает код, и NAT-адрес, через который она выходит в интернет, различаются. В список всегда вносите адрес выхода (egress).

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

Некоторые интернет-провайдеры и мобильные операторы через CGNAT отдают один публичный IP многим абонентам. Если внести такой общий адрес в whitelist, к вашему тарифу без пароля сможет подключиться любой, кто сидит за тем же адресом. Используйте whitelist только со статическими адресами, которые принадлежат вам.

Логин и пароль или IP whitelist: сравнение

На скорость аутентификация влияет только при новых соединениях. SOCKS5 с логином и паролем на каждом новом соединении делает лишний круг запрос-ответ, при IP whitelist этого шага нет. На соединениях, которые держатся открытыми, разницы не заметно. Остальные различия между протоколами разобраны в статье HTTP vs SOCKS5.

Какой способ выбрать в каждом случае?

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

Какой способ используется в продуктах WeProxy?

Доступный способ зависит от продукта. На страницах продуктов указано следующее:

Для других продуктов способ аутентификации и поддерживаемые протоколы указаны в технических характеристиках и FAQ на странице продукта. Общие вопросы собраны на странице FAQ. Учётными данными и настройками whitelist вы управляете в личном кабинете. Добавляйте в whitelist только свои IP-адреса или те, которыми вам разрешено пользоваться.

Whitelist на стороне целевого сайта: когда нужен постоянный выходной IP

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

Для этого нужен продукт, у которого выходной адрес не меняется. У rotating-прокси IP меняется от запроса к запросу или по истечении сессии, и список на той стороне перестаёт работать при первой же смене. Статический дата-центровый IPv4-прокси даёт вам выделенный постоянный IP, и адрес не меняется весь срок тарифа. К прокси вы подключаетесь по логину и паролю, а целевой сервис узнаёт вас по постоянному выходному IP. Чем статические IP отличаются от ротационных, рассказано в руководстве по sticky и rotating прокси, а выбор между дата-центровыми и ISP-прокси разобран в статье ISP proxy vs datacenter proxy.

Как исправить ошибку 407 и проблемы с whitelist?

Большинство проблем с аутентификацией выглядят как 407 Proxy Authentication Required. В SOCKS5 та же проблема обычно проявляется так: соединение сразу закрывается.

Чтобы проверить саму строку независимо от программы, вставьте её в proxy checker. Если в чекере строка работает, а в вашей программе нет, ищите проблему в настройках прокси самой программы. На каком уровне возникают 407, 403, 429 и 502, объясняется в руководстве по кодам ошибок прокси. Как выстроить цепочку, если вы используете VPN вместе с прокси, рассказано в статье прокси или VPN.

Чек-лист: как защитить учётные данные прокси

• Не храните пароль в репозитории с кодом; читайте его из переменной окружения или менеджера секретов.
• Удаляйте пароль из URL, прежде чем отправлять логи, отчёты об ошибках и обращения в поддержку.
• Если подозреваете утечку пароля, перестаньте им пользоваться и запросите новые данные через личный кабинет или поддержку.
• Добавляйте в whitelist только статические адреса, которые принадлежат вам; домашние и мобильные IP за CGNAT туда не вносите.
• Убирайте из списка IP серверов, которыми больше не пользуетесь. Адрес удалённого VPS через какое-то время может достаться другому клиенту.
• В HTTP-прокси учётные данные Basic идут до прокси без шифрования. Содержимое страниц HTTPS-сайтов остаётся зашифрованным внутри туннеля CONNECT, но учитывайте это, когда пользуетесь прокси в сетях, которым не доверяете.

Какой бы способ вы ни выбрали, для всего, что вы делаете через прокси, действуют условия использования целевого сайта, файл robots.txt, GDPR и местное законодательство о персональных данных (например, KVKK в Турции или 152-ФЗ в России). Разрешённые варианты использования сервисов WeProxy перечислены на странице правил допустимого использования.