Автентифікація проксі
Метод перевірки того, що користувач авторизований використовувати проксі-ендпоінт - або логін/пароль, або whitelist IP-адреси.
Автентифікація проксі запобігає несанкціонованому використанню проксі-сервісу. Існують два основні методи: автентифікація за логіном/паролем і автентифікація за whitelist IP.
Автентифікація за логіном/паролем вимагає включити облікові дані в URL проксі: http://username:password@host:port. Проксі-сервер перевіряє дані перед пересиланням запиту. Цей метод працює з будь-якої IP-адреси, що робить його гнучким для розподілених систем.
Автентифікація за whitelist IP дає доступ на основі вашої вихідної IP-адреси. Ви реєструєте свій IP (або діапазон) у провайдера, і запити з цього IP пропускаються без облікових даних. Ні логіна, ні пароля в запиті не потрібно - простіше в налаштуванні.
Коли використовувати логін/пароль: застосунки на динамічних IP, розподілені системи, де воркери працюють на різних машинах, або коли ви не контролюєте вихідний IP. Коли використовувати whitelist IP: сервери зі статичними IP, простіше налаштування для довірених середовищ і коли ви волієте не зберігати облікові дані в коді застосунку.
Деякі конфігурації проксі підтримують обидва методи одночасно. Логін/пароль більш переносний; whitelist IP простіший для статичних розгортань.
Proving the connection belongs to a customer
A proxy has to decide whether to serve a connection. Two mechanisms are in common use: credentials sent with the connection, or a whitelist of addresses that are trusted without credentials.
With HTTP, credentials travel in a Proxy-Authorization header and a failure returns 407, which is distinct from the 401 a destination would send. With SOCKS5, authentication is part of the protocol handshake, which is why a SOCKS client asks for a username and password before any request is made.
The distinction between 401 and 407 is the single most useful diagnostic in this area. One means the proxy refused you, the other means the destination did, and confusing them sends people to debug the wrong system.
How our products authenticate
Everything uses login and password, and residential can additionally trust your server addresses:
Both mechanisms
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 means we rejected the login. Nine times out of ten a suffix is malformed rather than the password being wrong.
- Some tools cannot send proxy credentials at all. Selenium is the classic case, which is why selenium-wire or a generated extension exists.
- Whitelist servers, not laptops. Home connections change address and the failure looks like a proxy fault.
- Keep credentials working alongside a whitelist so a change of server address does not lock you out entirely.
Authentication confusions
407 is not 401
The first comes from us, the second from the site. They send you to different places to debug.
Credentials in the launch flag rarely work
Chromium-based tools take host and port only. Authentication happens through a separate call.
Whitelisting is not more secure by default
It swaps a secret for a location, which is safer only if the address is exclusively yours.
A password is not per-proxy on residential
One package password serves every session and every suffix combination.
Пов'язані терміни
Дивись на практиці
Готовий використовувати автентифікація проксі?
SotaProxy надає доступ до ротуючих резидентських, мобільних, дата-центр та ISP проксі. Без мінімальних платежів.
Почати