Программа не принимает логин и пароль от прокси: кто не умеет их передавать и что делать
Есть класс отказов, где пароль верный, прокси живой, а подключения нет: клиент физически не умеет передать учётные данные. Со стороны прокси это выглядит ровно как неверный пароль, поэтому неделями меняют пароль там, где менять нужно способ авторизации.
Chrome и Chromium: по HTTP — да, по SOCKS5 — никогда
Это записано в документации самого Chromium. Про HTTP-прокси: «HTTP proxies in Chrome support the same HTTP authentiation schemes as for target servers: Basic, Digest, Negotiate, NTLM» — опечатка в оригинале. Про SOCKS5 там же сказано прямо: «No authentication methods are supported for SOCKSv5 in Chrome (although some do exist for the protocol)».
То есть дело не в вашей строке подключения и не в прокси: поддержки нет в браузере. На вопрос в рассылке chromium-dev, как подключиться к SOCKS5 с авторизацией, мейнтейнер сетевой части ответил одной фразой: «This is not supported».
Кто ещё не умеет передавать пароль
- Приложения на Electron: в документации про --proxy-server сказано «The proxy URL does not support username and password authentication».
- Системный прокси Android: в классе ProxyInfo есть только хост, порт и список исключений — поля для логина и пароля в API нет вовсе, как и выбора протокола.
- netsh winhttp в Windows: синтаксис set proxy принимает только адрес сервера и bypass-list, параметра для учётных данных не существует.
- Ручная настройка прокси в параметрах Windows: поля для пароля на этом экране нет.
И наоборот, у кого с этим всё в порядке: Firefox (спрашивает логин и пароль сам), curl (--proxy-user), iOS (в настройках Wi-Fi есть переключатель авторизации с полями логина и пароля) и macOS, где учётные данные — полноправные аргументы команды networksetup.
# macOS: логин и пароль — обычные аргументы
networksetup -setsocksfirewallproxy Wi-Fi ШЛЮЗ ПОРТ on ЛОГИН ПАРОЛЬ
# Windows: параметра для учётных данных здесь нет вовсе
netsh winhttp set proxy proxy-server="ШЛЮЗ:ПОРТ"Почему в Firefox работает, а в Chromium нет
Firefox реализует авторизацию по логину и паролю в SOCKS5, Chromium — нет. Отсюда самая частая загадка в антидетект-браузерах: одна и та же строка прокси работает в одном инструменте и не работает в другом. Дело не в инструменте как таком, а в его движке: браузеры на Chromium вынуждены делать свой слой поверх прокси, чтобы авторизованный SOCKS5 заработал вообще, а браузеры на Firefox получают это из движка.
Проверка: прокси или клиент
Прежде чем менять настройки, отделите одно от другого. curl умеет передавать учётные данные отдельно от адреса, поэтому его ответ говорит только о прокси.
# socks5h, а не socks5: h означает, что имена разрешает прокси —
# именно так поступит и браузер, и путь DNS совпадёт с рабочим.
curl -x socks5h://ШЛЮЗ:ПОРТ -U ЛОГИН:ПАРОЛЬ https://example.com -o /dev/null -w '%{http_code}\n'
# Тот же логин на HTTP-порту:
curl -x http://ШЛЮЗ:ПОРТ -U ЛОГИН:ПАРОЛЬ https://example.com -o /dev/null -w '%{http_code}\n'
# 200 в обоих -> прокси и доступы в порядке, дело в клиенте.
# 407 -> дело в доступах, клиент тут ни при чём.Решение: авторизация по IP
Если клиент не умеет передавать пароль, нужно перестать его требовать. При авторизации по адресу IP машины добавляется в whitelist, и прокси узнаёт клиента по самому подключению — в настройках остаются только хост и порт, а поле пароля остаётся пустым. Это не обход ограничения, а второй штатный способ авторизации.
У нас оба способа активны одновременно, поэтому переключать ничего не нужно и писать в поддержку тоже: серверная машина работает по whitelist, а скрипты с ноутбука продолжают ходить по логину и паролю.
Когда whitelist не подойдёт
- Домашний адрес от провайдера меняется — придётся обновлять whitelist, и в самый неподходящий момент задача встанет. Для таких случаев адрес обновляется запросом к API.
- Общая сеть или NAT: за одним внешним адресом сидят другие люди, и whitelist откроет доступ им всем. Здесь нужен логин с паролем и клиент, который умеет его передать.
Про локальный релей
Обходной путь, который советуют по форумам: поднять локальный прокси без авторизации, а он уже подключается к нашему с логином и паролем. Способ рабочий, но это лишний хоп и вторая точка отказа: когда что-то сломается, разбираться придётся в двух местах вместо одного. При наличии whitelist смысла в нём обычно нет.
Оба способа авторизации сразу
Логин с паролем и whitelist по IP работают параллельно на любом тарифе — выбирать между ними не нужно. Ротационные IPv6 от 650 ₽ за 50 потоков, статические IPv4 от 300 ₽.
Смотреть тарифыПрокси под эту задачу
Проверить нашими инструментами
Читайте также
- Авторизация прокси по IP или по логину: когда что включатьДве схемы решают разные задачи. Где whitelist единственный выход, где надёжнее пароль, и почему держать обе сразу удобнее, чем выбирать.
- Один шлюз вместо списка прокси: как настроить софт, который ждёт списокПарсеры считают масштаб числом прокси, а ротационный шлюз — это одна строка. Разбор по программам: где переключить режим, где продублировать строку и где честный ответ — купить список.
- 403 через прокси: отказал сайт, отказал прокси или дело вообще не в адресе403 приходит и от прокси, и от целевого сайта, и различить их можно не всегда. Разбор: где смотреть код Cloudflare, какие коды не лечатся сменой адреса и почему заголовки прокси — плохой тест.
