Диагностика4 мин чтения

Как исправить ошибку прокси 407, не гадая

Разбираем ошибку Proxy Authentication Required по шагам: шлюз, метод аутентификации, кодирование учётных данных, область действия аккаунта и настройки клиента.

На этой странице

С чего начать

Код 407 указывает на уровень аутентификации прокси. Начните с него, прежде чем менять запрос к целевому серверу или добавлять повторы.

Определите, кто запрашивает учётные данные

HTTP 407 означает, что прокси требует аутентификации. Ответ содержит вызов Proxy-Authenticate. Клиент передаёт учётные данные прокси через Proxy-Authorization. Аутентификация на целевом сервере — отдельный механизм: подставлять пароль прокси в заголовок Authorization целевого сайта — неверное решение.

Для HTTPS-назначения отказ может произойти на этапе CONNECT, ещё до того, как приложение получит ответ целевого сервера. Некоторые клиенты сообщают об исключении прокси или туннеля вместо обычного Response со статусом 407.

Проверяйте по одной переменной за раз

Используйте этот порядок, чтобы получить полезное воспроизведение, а не череду несвязанных изменений.

  • Шлюз: скопируйте точную схему, имя хоста и порт из актуальных инструкций по настройке в аккаунте.
  • Метод: уточните, ожидает ли эта конечная точка имя пользователя и пароль, разрешённый исходный IP-адрес или другой документированный механизм аутентификации.
  • Область учётных данных: убедитесь, что имя пользователя относится к этому продукту или субпользователю, а не просто к логину в панели управления.
  • Кодирование: применяйте percent-encoding к учётным данным при встраивании их в URL; используйте отдельные поля для учётных данных, если клиент их поддерживает.
  • Клиент: проверьте унаследованные настройки прокси и убедитесь, что реально выбран нужный шлюз.

Сравните curl с приложением, в котором возникает ошибка

Выполните ограниченный рецепт curl из связанного руководства с тем же шлюзом, целевым сервером и учётными данными. Если он работает, сосредоточьтесь на том, как приложение отображает эти настройки. В Playwright, например, учётные данные прокси задаются в proxy.username и proxy.password, а не в httpCredentials.

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

Отправьте воспроизводимый отчёт без секретов

Сохраните версию клиента, метку времени в UTC, хост и порт шлюза, имя целевого хоста, метод аутентификации и статус или класс исключения. Укажите, завершается ли ошибкой и минимальное воспроизведение через curl. Эти детали позволяют поддержке найти попытку, не получая вашего пароля.

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

Перед выпуском

  • Отличайте аутентификацию на прокси от аутентификации на сайте.
  • Воспроизведите с теми же настройками во втором клиенте.
  • Делитесь очищенной диагностикой, а не учётными данными или сырыми трассировками.

Источники и дополнительное чтение

Технические материалы, использованные при подготовке руководства. Сверяйтесь с документацией вашей версии и с поддерживаемой конфигурацией вашего провайдера.