OP-Proxy
ЦеныБлогРеселлингAPI
Личный кабинет
← Блог
Решение проблем·17 августа 2026 г.·4 мин чтения

Программа не принимает логин и пароль от прокси: кто не умеет их передавать и что делать

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

В этой статье

  • Chrome и Chromium: по HTTP — да, по SOCKS5 — никогда
  • Кто ещё не умеет передавать пароль
  • Почему в Firefox работает, а в Chromium нет
  • Проверка: прокси или клиент
  • Решение: авторизация по IP
  • Когда whitelist не подойдёт
  • Про локальный релей

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».

Проверить это стоит, но не то, чего обычно боятся: Chrome не уходит молча напрямую при отказе прокси — при единственном настроенном прокси запросы падают с ERR_PROXY_CONNECTION_FAILED, а прямое соединение возможно, только если DIRECT явно указан в списке. Так что откройте через профиль страницу проверки IP и посмотрите, чей адрес она показывает: если ваш — прокси не применился, и это видно сразу.

Кто ещё не умеет передавать пароль

  • Приложения на 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.

bash
# macOS: логин и пароль — обычные аргументы
networksetup -setsocksfirewallproxy Wi-Fi ШЛЮЗ ПОРТ on ЛОГИН ПАРОЛЬ

# Windows: параметра для учётных данных здесь нет вовсе
netsh winhttp set proxy proxy-server="ШЛЮЗ:ПОРТ"

Почему в Firefox работает, а в Chromium нет

Firefox реализует авторизацию по логину и паролю в SOCKS5, Chromium — нет. Отсюда самая частая загадка в антидетект-браузерах: одна и та же строка прокси работает в одном инструменте и не работает в другом. Дело не в инструменте как таком, а в его движке: браузеры на Chromium вынуждены делать свой слой поверх прокси, чтобы авторизованный SOCKS5 заработал вообще, а браузеры на Firefox получают это из движка.

Проверка: прокси или клиент

Прежде чем менять настройки, отделите одно от другого. curl умеет передавать учётные данные отдельно от адреса, поэтому его ответ говорит только о прокси.

bash
# 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 ₽.

Смотреть тарифы

Прокси под эту задачу

  • Для многопоточного софта
  • Статические датацентр-IPv4
  • Ротационные IPv6 и IPv4

Проверить нашими инструментами

  • Мой IP-адрес
  • Проверка анонимности

Читайте также

  • Авторизация прокси по IP или по логину: когда что включатьДве схемы решают разные задачи. Где whitelist единственный выход, где надёжнее пароль, и почему держать обе сразу удобнее, чем выбирать.
  • Один шлюз вместо списка прокси: как настроить софт, который ждёт списокПарсеры считают масштаб числом прокси, а ротационный шлюз — это одна строка. Разбор по программам: где переключить режим, где продублировать строку и где честный ответ — купить список.
  • 403 через прокси: отказал сайт, отказал прокси или дело вообще не в адресе403 приходит и от прокси, и от целевого сайта, и различить их можно не всегда. Разбор: где смотреть код Cloudflare, какие коды не лечатся сменой адреса и почему заголовки прокси — плохой тест.
OP-Proxy
Планы и информация
ЦеныБлогРеселлингAPIПользовательское соглашениеПолитика конфиденциальности
Прокси под задачу
Для парсинга и скрапингаДля многопоточного софтаДля маркетплейсовДля антидетект-браузеровДля капча-софтаДля SEO и съёма выдачиРотационные IPv6 и IPv4IPv6-проксиСтатические датацентр-IPv4
Инструменты
Мой IP адресТест скоростиПроверка анонимностиWHOIS запросТест утечки DNSПроверка сайта
ИП Артамонов Анатолий Михайлович ОГРНИП 324700000026212 ИНН 701755408691