Правильный пароль у поставщика не создаёт подходящих учётных данных для фактически выбранного прокси. Начните со схемы, хоста и порта этой конечной точки; поле хоста обычно принимает только имя хоста или IP, а не полный URL.

  1. Прочитайте весь обмен аутентификации. Один 407 с последующей принятой повторной попыткой может быть нормой. Убедитесь, что итоговый результат по-прежнему 407, прежде чем считать вход отклонённым.
  2. Сравните маршрут и область учётных данных. Сопоставьте фактический хост/порт и другие поля, заданные развёрнутым HttpClient 5 AuthScope. Неверный порт может оставить BasicCredentialsProvider без подходящей записи.
  3. Проверьте метод и идентичность. Предложил ли прокси поддерживаемый метод? Использовала ли повторная попытка ожидаемое соединение? Требует ли оператор учётную запись с доменной квалификацией или иной документированный формат?

Используйте API установленной основной версии. Рецепт кэша аутентификации из HttpClient 4 не переносится без изменений в версию 5. Используйте требования оператора к учётной записи, а не перебирайте произвольные варианты имени пользователя.

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

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

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