Ошибка 407 Proxy Authentication Required означает, что для запроса нужна авторизация на прокси — промежуточном сервере между клиентом и сайтом. Пароль от личного кабинета сайта обычно не решает эту задачу: сначала нужно выяснить, какой прокси ответил и почему он не принял клиента.
Если страница работает через мобильную сеть, а в офисе возвращает 407, начинайте с офисного маршрута. Если ошибка видна и из независимой сети, проверяйте также прокси у приложения или интеграции: одного сравнения сетей недостаточно для окончательного вывода.
Чем 407 отличается от 401 и 403
По RFC 9110, раздел 15.5.8, ответ 407 должен содержать Proxy-Authenticate: прокси сообщает, какой способ авторизации требуется. Клиент передаёт данные для него в Proxy-Authorization.
У 401 другой адресат авторизации — целевой ресурс; используется WWW-Authenticate. Если запрос дошёл до сайта и отказ возникает при входе в кабинет, пригодится разбор ошибки 401. Код 403 означает отказ выполнить запрос и сам по себе не подтверждает проблему с паролем прокси.
Не ориентируйтесь только на надпись на странице. «407» в тексте ошибки приложения и HTTP-статус 407 — разные наблюдения; для диагностики нужен фактический ответ.
Шаг 1. Зафиксируйте, где появляется отказ
Запишите публичный URL, время с часовым поясом, сеть и программу, в которой произошла ошибка. Уточните, не менялись ли перед этим VPN, прокси, корпоративный пароль или настройки рабочего компьютера.
Затем сравните один и тот же безопасный запрос:
| Проверка | Что уточняет результат | | --- | --- | | Тот же компьютер и URL через другую разрешённую сеть | Связан ли отказ с офисным маршрутом | | Другой компьютер в той же сети | Проблема одного устройства или общая настройка | | Браузер и служебный скрипт в одной сети | Совпадают ли их маршрут и способ авторизации | | Независимая внешняя проверка публичного URL | Доступен ли ресурс с другой точки |
Проводите сравнение на просмотре страницы, а не на повторной оплате или отправке заказа. Если 407 получает только скрипт, а браузер работает, проверьте настройки именно скрипта: браузер может использовать корпоративный вход, который утилита не повторяет.
Шаг 2. Найдите прокси и этап запроса
Посмотрите настройки прокси операционной системы, браузера и приложения. Если используется PAC-файл — сценарий автоматического выбора прокси, — уточните у администратора, какой маршрут он выбирает для проблемного домена; соседние сайты могут идти другим путём.
При HTTPS клиент через HTTP-прокси обычно сначала создаёт туннель командой CONNECT. Если 407 получен на этом этапе, туннель ещё не установлен: такой ответ не доказывает отказ веб-приложения и не является основанием перевыпускать сертификат сайта. Механизм туннеля описан в RFC 9110, раздел 9.3.6.
Если доступен ответ, проверьте статус и наличие Proxy-Authenticate. Заголовки Via, Server и оформление страницы могут подсказать источник, но подтверждать его лучше по маршруту и журналам прокси: эти признаки могут отсутствовать или быть изменены.
Шаг 3. Сравните прямой запрос и запрос через прокси
Для технического специалиста полезно явно задать маршрут в curl. Примеры используют условные адреса и не передают учётные данные:
curl -q --noproxy '*' -sS -D - -o /dev/null --max-time 20 https://example.com/
curl -q --noproxy '' --proxy http://proxy.example:3128 -sS -D - -o /dev/null --max-time 20 https://example.com/В первом запросе --noproxy '*' отключает использование настроенного прокси в curl; во втором пустой список исключений позволяет проверить явно указанный прокси. -q отключает чтение стандартного файла настроек curl. Значение параметров можно сверить с документацией curl.
Прямую проверку выполняйте только там, где её разрешает политика сети. Она не обходит прозрачный сетевой шлюз и может не работать, если прямой выход запрещён; это ещё не означает, что сайт упал.
407 без данных авторизации на защищённом прокси может быть ожидаемым первым ответом. Не добавляйте пароль сайта в команду: способ входа на прокси и разрешённый способ передачи его учётных данных должен определить администратор. Не публикуйте сырой вывод диагностики с Cookie, токенами и заголовками авторизации.
Шаг 4. Исправьте установленную причину
Выберите действие по результатам сравнения:
- Ошибка на одном устройстве: проверьте адрес и порт прокси, рабочий профиль и сохранённые данные входа. Удалять настройки стоит после подтверждения, что они устарели.
- Ошибка у нескольких сотрудников: передайте сетевому администратору время, URL, схему из
Proxy-Authenticateи результаты сравнения. Нужна проверка правил доступа и журналов отказа. - Браузер работает, скрипт получает 407: согласуйте способ авторизации служебного клиента и его права; не копируйте браузерную сессию в скрипт.
- 407 виден из разных сетей: проверьте цепочку приложения, CDN и исходящих интеграций. Приложение могло передать клиенту отказ своего upstream-прокси; сопоставьте запрос с серверными журналами.
Не отключайте корпоративную защиту и не меняйте DNS наугад. После исправления повторите исходный запрос в пострадавшей сети и проверьте ожидаемую страницу: исчезновение 407 при появлении другого отказа ещё не означает восстановление.
Следующий шаг после диагностики
Внешний мониторинг Web-Puls помогает наблюдать доступность публичного сайта, но успешный ответ с внешней точки не подтверждает исправность офисного прокси. Для этого нужен повторный тест из сети, где возникла проблема.
Если источник отказа остаётся неясным, отправьте заявку на диагностику: укажите публичный URL, время, затронутые сети и результаты сравнений без паролей и токенов. Эти данные помогут определить предмет проверки и согласовать объём работ.