Авторизация прокси: логин и пароль или белый список IP

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

В этом гайде показываем, что каждый метод реально отправляет по сети (замерено на тестовом прокси, а не пересказано по памяти), какие инструменты умеют только один из них, и разбираем баг с паролем, из-за которого в первый же день так часто звучит «прокси не работает».

Что на самом деле отправляют логин и пароль

У HTTP-прокси учётные данные передаются в заголовке Proxy-Authorization в каждом запросе или туннеле. Мы прогнали curl через тестовый прокси, который логирует всё входящее:

curl -x http://user:p%40ss%23word@127.0.0.1:18407 http://example.com/

Прокси получил:

Proxy-Authorization: Basic dXNlcjpwQHNzI3dvcmQ=

Это не хеш. dXNlcjpwQHNzI3dvcmQ= это base64 от user:p@ss#word, и любой, кто видит соединение, раскодирует его одной строкой. Basic-авторизация кодирует пароль, но не шифрует его. Между вашей машиной и HTTP-прокси логин идёт по сети в виде, который может прочитать любой на маршруте, если только само подключение к прокси не идёт по TLS (а у большинства прокси-сервисов это не так). Поэтому доступы к прокси стоит считать секретом того же уровня, что и API-ключ: им не место в истории шелла, логах CI и на скриншотах.

В SOCKS5 учётные данные идут не в заголовке, а отдельным шагом рукопожатия (метод username/password из RFC 1929). Именно поэтому SOCKS-клиенты просят их в отдельных полях, а не внутри URL. Передаются они тоже открытым текстом.

Два кода ответа подскажут, где именно сбой:

• 407 Proxy Authentication Required отдаёт сам прокси. Логин не передан или неверный. Наш тестовый прокси ответил 407 и на запрос без учётных данных, и на запрос с неправильным паролем.
• 401 Unauthorized отдаёт целевой сайт. Прокси вас пропустил, а сайт хочет собственную авторизацию.

Большая часть времени, потерянного на «авторизацию», уходит на отладку не того из этих двух кодов. Полный чек-лист по первому есть в статье 407 Proxy Authentication Required.

Баг с паролем, который ломает большинство первых настроек

Учётные данные в URL выглядят так: http://user:password@host:port. В синтаксисе URL символ @ отделяет учётные данные от хоста, а # начинает фрагмент. Пароль с любым из этих символов ломает разбор, и библиотеки не предупреждают об этом, а уверенно делают что-то не то.

Мы передали Python requests пароль p@ss#word как есть:

proxies = {"http": "http://user:p@ss#word@127.0.0.1:18407"}

Ошибки «неверный пароль» не было. Библиотека попыталась подключиться к прокси с именем ss на порту 80:

ProxyError: HTTPConnectionPool(host='ss', port=80): Max retries exceeded

Тот же запрос с паролем в процентной кодировке, p%40ss%23word, вернул 200, как и httpx с закодированным вариантом.

Правило: внутри URL пароль нужно кодировать процентами: @ как %40, # как %23, : как %3A, / как %2F. Или вообще обойтись без URL и передавать данные в отдельных полях, если инструмент это позволяет: username и password в Playwright, page.authenticate в Puppeteer, поля логина в профиле любого антидетект-браузера. В отдельных полях проблемы с кодировкой нет.

Что такое белый список IP и чем он не является

Белый список (whitelist) это перечень исходящих адресов, которые прокси принимает без учётных данных. Вы добавляете публичный IP машины, с которой будете подключаться, и дальше она вообще не отправляет логин.

Причина его существования одна, и она реальная: некоторые инструменты не умеют передавать учётные данные прокси. Классический пример Selenium. Ни Chrome, ни Firefox не принимают логин прокси через стандартную capability WebDriver, так что остаётся либо помощник вроде selenium-wire, либо сгенерированное расширение, либо белый список для машины. Для парсера на постоянном сервере белый список просто означает меньше настроек.

Но это не повышение безопасности. Он ломается тремя способами, и все три без предупреждения:

• Адрес меняется. Домашний интернет, мобильная точка доступа, ноутбук, который кочует между сетями. Запись в белом списке устаревает, и прокси начинает отвечать 407 машине, на которой «ничего не меняли». Добавляйте в белый список серверы, а не ноутбуки.
• Адрес общий. На облачном хосте, в общем офисном интернете или у оператора за NAT публичный адрес принадлежит не только вам. Любой, кто может отправить трафик с него, получает ваш доступ и ваш счёт за трафик.
• Адрес не тот, что вы думаете. Контейнеры, VPN и корпоративный выход в интернет меняют адрес, который видит прокси. Проверяйте простым запросом к сервису, показывающему IP, с самой машины, а не из своего браузера.

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

Что выбрать в зависимости от ситуации

Важная деталь, связанная с тем, как некоторые провайдеры (и мы в том числе) устроили логин: имя пользователя это не только идентификатор, в нём же передаётся таргетинг. Наш логин для резидентских прокси принимает суффиксы страны, города и sticky-сессии, например login_c_US_s_7_ttl_1h. При белом списке логина нет, суффиксы некуда поставить, и действуют настройки по умолчанию. Если нужны гео или сессии на уровне отдельного запроса, одно это решает выбор в пользу логина и пароля. Синтаксис суффиксов описан в справочнике по строке подключения.

Какие продукты что поддерживают

Это зависит от провайдера, и проверить лучше до покупки, а не после. У нас резидентские прокси поддерживают и логин, и белый список; ISP, датацентровые, IPv6 и мобильные адреса авторизуются только по логину и паролю. Белым списком можно управлять в личном кабинете или через API, эндпоинты описаны в справочнике авторизация и белый список IP.

Как не оставить учётные данные где попало

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

• Не в командной строке, если без этого можно обойтись. curl -x http://user:pass@... оседает в истории шелла. Используйте --proxy-user с запросом пароля, переменную окружения или конфиг с ограниченными правами доступа.
• Не в репозиториях и не в логах CI. Библиотеки печатают URL прокси в сообщениях об ошибках вместе с учётными данными, что видно по ошибке requests выше. Вычищайте их, прежде чем куда-то вставлять трейсбек.
• Отдельные логины под каждый проект, если провайдер это позволяет, чтобы утечка в одном месте не стоила всего аккаунта.
• Меняйте пароль, когда уходит любой, у кого был доступ. Запись в белом списке для сервера ушедшего подрядчика это та же проблема в другой форме.

Как проверить, какой метод сейчас работает

Три быстрых теста с той машины, которая реально будет ходить через прокси:

1. Запрос с логином и паролем. 200 значит, учётные данные работают. 407 значит, логин неверный или искажён; первым делом проверьте кодировку.
2. Запрос без учётных данных. 200 значит, ваш адрес в белом списке (или прокси открыт, а это отдельная проблема). 407 значит, адреса в списке нет.
3. Запрос с логином и паролем из другой сети. 200 подтверждает, что работают именно учётные данные, а не адрес.

Каждый тест это одна команда curl, все вместе занимают минуту. Полный набор проверок перед оплатой объёма есть в статье как проверить прокси перед покупкой.

FAQ

Что такое авторизация прокси?

Способ, которым прокси решает, обслуживать ли подключение: либо клиент отправляет логин и пароль при каждом подключении, либо прокси принимает подключения с заранее одобренного списка адресов без учётных данных. На отклонённую попытку прокси отвечает 407; код 401 приходит от сайта, а не от прокси.

Безопасна ли авторизация прокси по логину и паролю?

Учётные данные кодируются в base64, а не шифруются, поэтому любой на сетевом маршруте между вами и HTTP-прокси может их прочитать, если само подключение не идёт по TLS. На практике логин нужно считать секретом: не держать его в URL в истории шелла, логах и репозиториях и менять, если он мог утечь.

Почему не работает пароль от прокси?

Чаще всего потому, что в нём есть @, #, : или /, а в URL его вставили без кодирования. Python requests с паролем p@ss#word в URL прокси пытался подключиться к хосту ss. Закодируйте пароль процентами (%40, %23, %3A, %2F) или передайте его в отдельных полях логина и пароля.

Белый список IP лучше пароля?

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

Можно ли использовать логин и белый список одновременно?

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