Аутентификация прокси
Метод проверки того, что пользователь авторизован использовать прокси-эндпоинт - либо логин/пароль, либо whitelist IP-адреса.
Аутентификация прокси предотвращает несанкционированное использование прокси-сервиса. Существуют два основных метода: аутентификация по логину/паролю и аутентификация по whitelist IP.
Аутентификация по логину/паролю требует включить учётные данные в URL прокси: http://username:password@host:port. Прокси-сервер проверяет данные перед пересылкой запроса. Этот метод работает с любого IP-адреса, что делает его гибким для распределённых систем.
Аутентификация по whitelist IP даёт доступ на основе вашего исходящего IP-адреса. Вы регистрируете свой IP (или диапазон) у провайдера, и запросы с этого IP пропускаются без учётных данных. Ни логина, ни пароля в запросе не нужно - проще в настройке.
Когда использовать логин/пароль: приложения на динамических IP, распределённые системы, где воркеры работают на разных машинах, или когда вы не контролируете исходящий IP. Когда использовать whitelist IP: серверы со статическими IP, более простая настройка для доверенных сред и когда вы предпочитаете не хранить учётные данные в коде приложения.
Некоторые конфигурации прокси поддерживают оба метода одновременно. Логин/пароль более переносим; whitelist IP проще для статических развёртываний.
Как доказать, что соединение принадлежит клиенту
Прокси должен решить, обслуживать соединение или нет. В ходу два механизма: учётные данные, отправленные вместе с соединением, или белый список адресов, которым доверяют без учётных данных.
В HTTP учётные данные едут в заголовке Proxy-Authorization, а отказ возвращает 407, и это не тот 401, который отправила бы цель. В SOCKS5 авторизация часть рукопожатия протокола, и поэтому SOCKS-клиент спрашивает логин и пароль ещё до всякого запроса.
Различие между 401 и 407 это самая полезная диагностика в этой области. Один означает, что вас отклонил прокси, другой что цель, и путаница отправляет людей отлаживать не ту систему.
Как авторизуются наши продукты
Всё работает по логину и паролю, а резидентка вдобавок может доверять адресам ваших серверов:
Оба механизма
Credentials login[_suffixes]:password@proxy.sotaproxy.com:10000
login:password@your-ip:50100 for static
Whitelist register your server address, then connect without
credentials from it (residential lists)
GET/POST /user/residential/whitelist- 407 означает, что логин отклонили мы. В девяти случаях из десяти дело в неверно собранном суффиксе, а не в пароле.
- Некоторые инструменты вообще не умеют отправлять учётные данные прокси. Классический случай Selenium, и ровно поэтому существуют selenium-wire и генерируемое расширение.
- В белый список вносите серверы, а не ноутбуки. Домашние подключения меняют адрес, и сбой выглядит как отказ прокси.
- Держите учётные данные рабочими наряду с белым списком, чтобы смена адреса сервера не заперла вас снаружи полностью.
Путаница вокруг авторизации
407 это не 401
Первый приходит от нас, второй от сайта. Они отправляют отлаживать разные места.
Учётные данные во флаге запуска редко работают
Инструменты на основе Chromium берут только хост и порт. Авторизация происходит отдельным вызовом.
Белый список не безопаснее по умолчанию
Он меняет секрет на местоположение, что безопаснее лишь тогда, когда адрес принадлежит только вам.
На резидентке пароль не привязан к прокси
Один пароль пакета обслуживает каждую сессию и любое сочетание суффиксов.
Связанные термины
Смотри на практике
Готов использовать аутентификация прокси?
SotaProxy даёт доступ к ротирующим резидентским, мобильным, дата-центр и ISP прокси. Без минимальных платежей.
Начать