407 требует аутентификации на прокси, а 401 — для целевого ресурса. Один запрос может встретить оба ответа, поэтому перед отправкой пароля выясните, кто его запрашивает.

Сравните статус и заголовки запроса аутентификации

ОтветЗаголовок запроса аутентификацииЗаголовок учётных данныхУчастник
407 Proxy Authentication RequiredProxy-AuthenticateProxy-AuthorizationПромежуточный прокси
401 UnauthorizedWWW-AuthenticateAuthorizationПроцесс аутентификации исходного ресурса

Статус — важная первая подсказка, но изучите весь обмен. Число 407 в тексте страницы не равнозначно настоящему ответу HTTP 407. Аналогично, собственная страница входа сайта может вернуть 200 и всё равно требовать аутентификации на уровне приложения.

Почему HTTPS-запрос может получить 407 ещё до сайта

При передаче HTTPS-запроса через обычный HTTP-прокси клиент, как правило, сначала просит создать туннель CONNECT. Прокси может потребовать аутентификацию для самого запроса CONNECT. Если она не завершена, TLS-сеанс с целевым сервером через туннель ещё не установлен. Поэтому смена API-токена сайта вряд ли исправит этот этап.

Выполните запрос с подробным выводом, чтобы увидеть место запроса аутентификации:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Замените локальный слушающий адрес своим и найдите первый запрос аутентификации в журнале. 407 во время CONNECT возникает до TLS с целевым сервером; последующий 401 может появиться уже после успешного создания туннеля.

Передавайте данные прокси через предназначенный для него интерфейс

Для адреса и аккаунта от доверенного администратора curl умеет согласовать схему аутентификации прокси и запросить недостающий пароль:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Замените пример адреса и имени пользователя данными сервиса, которым вам разрешено пользоваться. Указав только имя пользователя, вы не помещаете пароль непосредственно в приведённую команду. Поддерживаемые методы зависят от сборки curl и прокси; при сбое согласования проверьте фактический запрос аутентификации и возможности сборки.

Параметр аутентификации прокси отделён от параметра curl для пользователя исходного сервера. Не добавляйте заголовок Authorization для исходного сервера вместо ответа на запрос прокси. Также не пересылайте вручную заголовки учётных данных прокси в посторонние запросы и не сохраняйте их среди заголовков, повторно используемых всем приложением.

Если прокси постоянно возвращает 407

  • Убедитесь, что указаны нужные хост и порт прокси.
  • Проверьте предлагаемые прокси схемы, а не считайте, что используется Basic.
  • Проверьте состояние аккаунта и требуемый сервисом формат имени пользователя.
  • Если данные встроены в URL, проверьте передачу специальных символов.
  • Выясните, нужна ли корпоративной аутентификации, интегрированной с браузером, поддержка среды выполнения или платформы.
  • Если данных клиента недостаточно, попросите администратора предоставить очищенный от конфиденциальных сведений идентификатор запроса или запись серверного журнала.

403 или отказ CONNECT может быть решением политики доступа даже после успешного входа. Дополнительные попытки ввода пароля не откроют доступ к запрещённому адресу.

HTTPS целевого сервера защищает не каждый обмен учётными данными прокси

Аутентификация прокси может происходить до установления TLS с целевым сервером. Если соединение с самим прокси незашифровано, а метод раскрывает на нём многократно используемые данные, HTTPS у цели не защитит уже состоявшийся обмен. Выберите подходящие сервису транспорт и аутентификацию; не отправляйте личные аккаунты неизвестному публичному прокси.

Перед публикацией подробных журналов просмотрите их. Даже если инструмент скрывает распространённые поля учётных данных, там могут остаться имена пользователей, внутренние адреса, cookies и другие идентифицирующие сведения.

Похожие статьи