Доступ к платному прокси-сервису открывается одним из двух способов: либо вы на каждом запросе отправляете логин и пароль , либо указываете свой публичный IP-адрес в панели провайдера и создаёте whitelist (список разрешённых). Оба решают одну и ту же задачу — «действительно ли это соединение принадлежит подписчику?» — но в повседневной работе дают очень разные результаты.
В этой статье мы разбираем, как оба метода работают на уровне протокола, в каком сценарии какой из них верен и с какими кодами ошибок вы столкнётесь.
Способ 1: Логин и пароль
В этом методе учётные данные отправляются прокси при каждом подключении. Формат зависит от протокола:
- HTTP-прокси:
Proxy-Authorization: Basic <base64(kullanici:sifre)>добавляется заголовок. - SOCKS5: выполняется согласование username/password, описанное в RFC 1929; логин и пароль передаются в двоичном виде.
На стороне HTTP поток выглядит так: клиент отправляет запрос без учётных данных, прокси отвечает Если требуется аутентификация , клиент добавляет учётные данные и повторяет запрос.
Большинство клиентов выполняет эти два круга автоматически. curl и браузеры, увидев 407, добавляют учётные данные и повторяют запрос; простые же HTTP-библиотеки иногда не повторяют попытку и сразу возвращают ошибку.
Basic метод учётные данные не шифрует, а лишь кодирует в Base64. Base64 — обратимое кодирование. Поэтому конфиденциальность учётных данных зависит от защищённости самого соединения с прокси.
Способ 2: IP whitelist
В модели whitelist пароля нет. Вы добавляете свой публичный IP-адрес в панель провайдера, и прокси принимает соединения только с этого адреса. Поскольку учётные данные не передаются, клиентская сторона сильно упрощается: curl -x http://proxy.example.com:8080 https://example.com вполне достаточно.
Ключевой вопрос этой модели таков: ваш публичный IP-адрес статичен? В большинстве домашних подключений IP динамический и меняется при перезагрузке модема. При смене whitelist перестаёт действовать, и все соединения отклоняются.
Выбор в основном сводится к вопросу «есть ли у вас статический IP». Для автоматизаций, работающих на сервере, лучше whitelist, для работы в разъездах — логин с паролем.
Что и в каком сценарии?
Скрапер или бот, работающий на сервере
IP вашего VPS статичен — выбирайте whitelist. Учётные данные не зашиваются в код или переменные окружения, поверхность утечки сокращается. Сценарии автоматизации — именно такой вариант мы рекомендуем по умолчанию.
Ручное использование с ноутбука
Если вы перемещаетесь между офисом, домом и кафе, IP постоянно меняется. Используйте логин с паролем — это работает из любой сети без проблем.
Совместное использование внутри команды
Если вам нужен ответ на вопрос, кто сколько трафика израсходовал, заведите отдельного пользователя на каждого. В whitelist вся команда выглядит как одна учётная запись.
Несколько профилей в антидетект-браузере
Если каждому профилю назначается свой исходящий IP, логин с паролем обязателен: выбор сессии чаще всего кодируется внутри логина (например, user-session-a1).
Встраивание данных о сессии в логин
В residential-пулах распространён такой подход: логин — это не только идентификатор, но и команда . Например:
Символ-разделитель и имена параметров у разных провайдеров отличаются. Ориентируйтесь на документацию в вашей панели; формат здесь приведён лишь для демонстрации структуры.
Преимущество такого подхода в том, что на стороне клиента не нужен ни один вызов API: страну или сессию вы меняете, изменив логин. Недостаток — логин удлиняется, а опечатки приводят к незаметным изменениям поведения. Логику rotating proxy мы подробно разбираем в статье, где рассматриваем и влияние этой модели на управление сессиями.
Частые ошибки
Различие между 407 и 403 критично: 407 говорит «предъявите учётные данные», а 403 означает «учётные данные я видел, прав у вас нет».
Ловушка спецсимволов
Когда учётные данные записываются в формате URL, некоторые символы пароля путаются с разделителем. В выражении http://user:p@ss@ip:8080 второй @ принимается за разделитель, и соединение не устанавливается. Решение — процентное кодирование:
| Символ | Кодированный вид | Символ | Кодированный вид |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
Более надёжный подход — не встраивать учётные данные в URL, а передавать их в отдельных полях клиента. Это поддерживают Python requests, Node undici и опция curl --proxy-user .
Чтение учётных данных из переменной окружения вместо их встраивания в код и предотвращает попадание секретов в систему контроля версий, и упрощает их ротацию.
Что меняется с точки зрения безопасности?
Оба метода несут разные риски. В модели с логином и паролем секрет могут украсть: достаточно строки команды, попавшей в лог-файл, конфигурационного файла, просочившегося в систему контроля версий, или скриншота. В модели whitelist секрета нет, но есть риск совместного использования IP : все, кто находится в той же офисной сети, могут, сами того не зная, пользоваться вашим прокси.
Самая надёжная конфигурация — объединить оба: сузьте источник с помощью whitelist и добавьте поверх логин с паролем. Большинство корпоративных провайдеров поддерживает эту гибридную модель. Если вас интересует, что именно видит прокси с точки зрения приватности, наша статья безопасен ли прокси даёт исчерпывающий обзор; для тестов на утечки — DNS leak и WebRTC leak вы можете воспользоваться нашими инструментами.
Практические правила управления учётными данными
- Используйте переменные окружения, не записывайте секреты в код.
- Заводите отдельные учётные данные для каждой среды : разработка, тестирование и продакшен не должны делить один пароль.
- Задавайте квоты и лимиты; утёкшие учётные данные не должны расходовать безлимитный трафик.
- Регулярно меняйте их; после ухода сотрудника из команды смена обязательна.
- Маскируйте в логах; отладочный вывод не должен печатать пароль открытым текстом.
Резюме
IP whitelist — самое чистое решение с минимальным риском утечки на серверах со статическим IP. Логин и пароль незаменимы при работе в разъездах и в сценариях, требующих нескольких сессий. Для решения достаточно ответить на вопросы: «статичен ли мой IP», «сколько человек будет пользоваться» и «нужно ли мне передавать параметр сессии». Чтобы протестировать вашу конфигурацию, вы можете инструмент проверки прокси использовать, а исходящий IP проверить с помощью Мой IP-адрес .