Ошибка 407 на прокси: что она означает и как её исправить

Как код 407 отличается от 401 и 403

Эти три кода состояния похожи, но указывают на совершенно разные участки сетевого пути.

401 Unauthorized означает, что конечный сервер не распознал или не принял предоставленные вами учётные данные. Сервер говорит, что ему нужно знать, кто вы, прежде чем отдать запрашиваемый ресурс, и обычно добавляет заголовок WWW-Authenticate с указанием, какой токен или способ входа он ожидает. Ошибка 401 решается правкой учётных данных для целевого сайта, а не для прокси.

403 Forbidden означает, что сервер понял запрос и отказывает в нём, независимо от того, вошли ли вы: например, из-за прав аккаунта или блокировки IP или региона. Повтор с теми же данными результат не изменит.

407 Proxy Authentication Required относится к прокси, а не к исходному серверу. Прокси стоит между вами и конечным сервером и решил, что перед передачей любого трафика нужно проверить действительное имя пользователя и пароль. Только после того как прокси примет ваши учётные данные, он переправит запрос дальше — и на этом этапе конечный сервер может сам вернуть ошибку 401 или 403 по своим причинам. Заголовки также различаются: в ответе 401 используется WWW-Authenticate, а в ответе 407 — Proxy-Authenticate. Если вы отлаживаете запрос с подробным логированием, этот заголовок является самым явным признаком того, что вы работаете с прокси, а не с сайтом.

Пять самых частых причин

Большинство ошибок 407 возникают из-за небольшого набора ошибок в настройках. Систематическая проверка по порядку экономит время.

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

2. Учётные данные указаны в неверном поле. Многие библиотеки и инструменты для работы с HTTP различают учётные данные для целевого сайта и для прокси. Заголовок Authorization аутентифицирует вас на конечном сервере, а заголовок Proxy-Authorization — на прокси. Если указать имя пользователя и пароль прокси в поле Authorization, прокси никогда их не увидит, и всегда вернётся ошибка 407.

3. Спецсимволы не закодированы в URL. Символы @, :, %, # и & имеют специальное значение внутри URL. Если ваш пароль — P@ss:w0rd%, то знак @ сломает разбор строки вида user:password@host, а знак % может быть воспринят как начало escape-последовательности, что незаметно изменит пароль, который получит прокси. Решение — закодировать каждый специальный символ в URL-кодировке, например @ превращается в %40. В Python используйте urllib.parse.quote(), в JavaScript — encodeURIComponent().

4. IP-адрес отсутствует в белом списке. Некоторые провайдеры прокси ограничивают доступ списком разрешённых исходных IP-адресов вместо запроса учётных данных в каждом запросе. Если публичный IP-адрес, с которого вы отправляете запрос, не указан в этом списке, прокси может вернуть 407 или закрыть соединение ещё до проверки имени пользователя и пароля. Уточните, какой IP-адрес видит прокси — это можно сделать простой командой curl — и сравните с тем, что зафиксировал провайдер.

5. Неверный протокол для конечной точки. HTTP-прокси не может аутентифицировать клиент SOCKS5, а прокси SOCKS5 не примет обычный HTTP-запрос. Несовпадение протокола обычно даёт ошибку соединения или рукопожатия, а не 407: HTTP-клиент на порту SOCKS5 вообще не получает HTTP-ответа. Всё же проверьте это, прежде чем заново вводить учётные данные. У Proxy302 используйте http:// с портом 2222 и socks5h:// с портом 3333 — по протоколу купленного IP.

Сначала проверьте прокси через curl

Прежде чем трогать код приложения, проверьте прокси прямо из терминала с помощью curl.

Используйте параметр -x, чтобы указать curl адрес прокси. Запрос без учётных данных выглядит так:

Сначала проверьте прокси через curl: пример

curl -v -x http://proxy.example.com:8080 https://ipinfo.io/json

Только пример: замените значения-заглушки своими.

Сначала проверьте прокси через curl, продолжение

Параметр -v выводит полный диалог, включая запрос аутентификации от прокси с заголовком Proxy-Authenticate и заголовок Proxy-Authorization, который curl отправляет в ответ. Если прокси требует имя пользователя и пароль, добавьте их с помощью параметра -U:

Сначала проверьте прокси через curl: пример

curl -v -x http://proxy.example.com:8080 -U "myuser:mypassword" https://ipinfo.io/json

Только пример: замените значения-заглушки своими.

Сначала проверьте прокси через curl, продолжение

Если этот запрос выполняется успешно — вы получаете HTTP 200 от конечного сервера — значит, учётные данные прокси верны, и проблема в том, как ваше приложение передаёт их. Если ошибка 407 остаётся, сами данные неверны или IP-адрес не разрешён. Параметр -U (полная форма --proxy-user) передаёт учётные данные прокси, а -u (--user) — конечному серверу. Их легко перепутать.

Исправление в браузере

Браузеры обычно сами запрашивают учётные данные прокси при получении ошибки 407. Если вместо окна видите ошибку, проверьте адрес и порт в системных настройках прокси, удалите сохранённые учётные данные прокси (Диспетчер учётных данных Windows или Связка ключей macOS) и перезагрузите страницу, чтобы браузер спросил их снова; чтобы сохранить логин и пароль, используйте расширение для прокси. В macOS их можно указать в разделе «Системные настройки → Сеть → Подробнее → Прокси». В корпоративных сетях, где для прокси используется вход в домен Windows, обратитесь в IT-отдел.

Исправление в Python с библиотекой Requests

Библиотека requests передаёт учётные данные прокси в словаре proxies. Сформируйте URL прокси с встроенным именем пользователя и паролем и не забудьте закодировать спецсимволы:

Исправление в Python с библиотекой Requests: пример

import urllib.parse

username = "myuser"
password = "P@ss:w0rd%"
encoded_password = urllib.parse.quote(password, safe="")

proxies = {
    "http":  f"http://{username}:{encoded_password}@proxy.example.com:8080",
    "https": f"http://{username}:{encoded_password}@proxy.example.com:8080",
}

Только пример: замените значения-заглушки своими.

Исправление в Python с библиотекой Requests, продолжение

Две частые ошибки: нет ключа https в словаре (HTTPS-запросы идут напрямую, и вы видите свой IP, а не 407) и незакодированный пароль, который как раз и даёт 407.

В качестве альтернативы установите переменные окружения HTTP_PROXY и HTTPS_PROXY. В macOS или Linux: export HTTP_PROXY="http://user:pass@host:port". В Windows PowerShell: $env:HTTP_PROXY = "http://user:pass@host:port". Библиотека Requests считывает их автоматически.

Исправление в Node.js

В Node.js 24.5+ (или 22.21+) задайте NODE_USE_ENV_PROXY=1 вместе с HTTPS_PROXY=http://user:pass@host:port, и встроенные модули http/https и fetch будут работать через прокси. В более старых версиях или для SOCKS5 используйте https-proxy-agent или socks-proxy-agent и кодируйте пароль через encodeURIComponent.

• Источники:
• Документация Node.js: встроенная поддержка прокси

Исправление через переменные окружения

Многие консольные утилиты и библиотеки считывают переменные окружения HTTP_PROXY и HTTPS_PROXY (это не то же самое, что системные настройки прокси Windows или macOS) в формате http://username:password@host:port. Установите их в профиль оболочки в macOS или Linux, или через диалог переменных окружения в Windows.

Когда обращаться к провайдеру

Обратитесь к провайдеру, если адрес, порт, протокол и учётные данные указаны верно, но ошибка остаётся. Типичные случаи: белый список ещё не обновлён для вашего текущего публичного IP-адреса, учётные данные не активированы, или конечная точка не работает.

Что именно сообщает заголовок Proxy-Authenticate?

Заголовок Proxy-Authenticate, который возвращается вместе с ответом 407, перечисляет методы аутентификации, которые поддерживает прокси — например Basic, Digest, NTLM или Negotiate. Basic — самый распространённый вариант для простых прокси с именем пользователя и паролем; NTLM или Negotiate указывают на среду домена Windows или Kerberos и могут потребовать дополнительной поддержки на стороне клиента.

Может ли прокси возвращать 407 для одного запроса и не возвращать для другого?

Да. Некоторые прокси запрашивают аутентификацию только при первом запросе в сессии, или когда изменился ваш публичный IP-адрес, а прокси использует белый список.

Означает ли код 407, что прокси-сервер сломан?

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

Почему curl показывает код HTTP 000 вместо 407?

Для https:// curl сначала отправляет прокси CONNECT; если прокси отвечает 407, целевой сервер не отвечает и %{http_code} остаётся 000. Код прокси покажет -w "%{http_connect}" или строка «CONNECT tunnel failed, response 407» в выводе -v.

Нужно ли автоматически повторять запрос при ошибке 407?

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

Как это сделать с Proxy302

Ротационные резидентные прокси подходят для этой задачи: вы выбираете страну выхода (195+ стран и регионов, со штатом и городом на линиях, которые это поддерживают) и платите за гигабайты, то есть только за использованный трафик. Настройка описана на странице ротационных резидентных прокси. В таблице ниже — где оказались выходы в 7 странах при нашей последней почасовой проверке; зонд отправляет запрос к ChatGPT, это лишь пример целевого сайта. Проверить свой выход поможет руководство по проверке местоположения прокси.

• странице ротационных резидентных прокси
• руководство по проверке местоположения прокси

Измеренные выходы: ChatGPT, 7 стран

Почасовая проверка зонда Proxy302, 23 октября 2026, 15:47 UTC: по одному запросу к ChatGPT из каждой страны через динамический резидентный выход, по публичной точке входа Proxy302. Публично показаны только первые три октета IP. Один замер на страну, не среднее; следующие проверки будут отличаться.

• Источники:
• Почасовая проверка связности Proxy302

Как это сделать с Proxy302: шаги

1. Шаг 1

   Откройте страницу ротационных резидентных прокси, выберите линию, оставьте протокол HTTP или выберите SOCKS5 и нажмите «Проверить цену и создать».

2. Шаг 2

   Откройте «Мои активы» (раздел консоли со всем, что вы купили) и скопируйте HOST, PORT, USERNAME и PASSWORD. На странице «Подключение» есть готовый пример с вашими данными.

3. Шаг 3

   Введите данные в браузер или программу, которую вы настраиваете.

4. Шаг 4

   Подтвердите выход запросом к https://ipinfo.io/json через прокси.

5. Шаг 5

   Из материкового Китая сначала запустите вспомогательную программу на странице «Подключение» и держите её открытой, пока работает прокси.

   • Руководство по вспомогательной программе

Цены и ограничения

Бюджетная линия стоит $1,50 за ГБ, $1,35 за ГБ в пакете 100 ГБ и $1,20 за ГБ при 300 ГБ. Бесплатного пробного периода нет, а минимальная покупка составляет 1 ГБ. Набор доступных локаций меняется ежедневно.

• Источники:
• Факты о продуктах и прайс Proxy302

Читайте дальше

Адрес, порт, логин и пароль прокси

Каждый рабочий прокси описывается пятью базовыми полями: протокол, адрес хоста, порт, логин и пароль.

Как проверить прокси: IP, страна, провайдер

Как за 30 секунд проверить IP, страну и провайдера прокси, почему сервисы расходятся в городе и что значит «чистота» IP. С нашей проверкой трёх сервисов.

Ротируемые резидентные прокси

Реальные домашние IP в 195+ странах с выбором региона и города. Смена IP на каждый запрос или липкие сессии. От $1,50/ГБ, $1,35/ГБ при 100 ГБ. HTTP и SOCKS5.

Посмотреть параметры и цену

ERR_PROXY_CONNECTION_FAILED: что проверить

Ошибка ERR_PROXY_CONNECTION_FAILED появляется в Chrome и Edge, когда браузер не может установить соединение с прокси-сервером.