407 Требуется аутентификация прокси: все причины и способы устранения

HTTP 407 имеет только одно значение: прокси перед вами отклонил ваши учетные данные. Этот единственный факт исключает большинство неверных направлений — вот остальная часть карты.

HTTP 407 Требуется аутентификация прокси имеет только одно значение, и оно уже, чем предполагают многие: прокси, находящийся между вами и интернетом, отклонил запрос из-за отсутствия действительных учетных данных для самого прокси. Целевой веб-сайт никогда не был контактирован. Он никогда не видел ваш запрос, не принимал решения и не может быть причиной. Исправление 407 всегда означает исправление вашей конфигурации прокси — и список того, что может быть неправильно, короткий и полностью перечисляемый. Это руководство проходит по всему списку, с исправлениями, специфичными для инструментов, которые чаще всего сбивают людей с толку.

Сначала прочитайте заголовок Proxy-Authenticate

Согласно спецификации HTTP (RFC 9110), 407 должен сопровождаться заголовком Proxy-Authenticate, описывающим, как аутентифицироваться — обычно что-то вроде Proxy-Authenticate: Basic realm="Access to internal site". Ожидается, что ваш клиент повторит запрос с заголовком Proxy-Authorization. Это сочетание стоит запомнить, потому что оно отличает 407 от его соседа: 401 исходит от исходного сервера и сочетается с WWW-Authenticate и Authorization, в то время как 407 исходит от посредника и использует версии с префиксом Proxy-. Если вы смотрите на заголовок WWW-Authenticate, вы отлаживаете неправильный переход.

# See exactly which hop is refusing you, and what scheme it wants
curl -v -x http://USER:PASS@gate.quantumproxies.io:8000 https://httpbin.org/ip

# Response you are looking for on failure:
#   HTTP/1.1 407 Proxy Authentication Required
#   Proxy-Authenticate: Basic realm="..."
#
# Response you want on success: your exit IP, not your own
#   {"origin": "203.0.113.45"}

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

Причина 1: учетные данные отсутствуют, неверны или находятся не в том месте

Наиболее распространенная причина также самая скучная. Учетные данные должны находиться в URL прокси, перед хостом, в форме user:pass@host:port — и библиотека клиента строит заголовок Proxy-Authorization из них. Копирование конечной точки с панели управления без учетных данных или вставка пароля вашей учетной записи вместо пароля прокси (они обычно разные) приводит к немедленному, постоянному 407 на каждый запрос.

import requests

proxy = "http://USER:PASS@gate.quantumproxies.io:8000"
proxies = {"http": proxy, "https": proxy}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(r.status_code, r.json())   # 200 and the exit IP = auth is correct

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

Причина 2: специальные символы, которые никогда не были закодированы процентами

Это стоит людям целых дней. URL прокси — это URL, поэтому любой зарезервированный символ в вашем имени пользователя или пароле должен быть закодирован процентами, иначе парсер разделит строку в неправильном месте. Пароль, содержащий @, завершает секцию userinfo преждевременно, и ваш клиент пытается подключиться к несуществующему хосту; : разделяет имя пользователя от пароля в неправильном месте.

from urllib.parse import quote

user = quote("team@example.com", safe="")   # team%40example.com
pwd  = quote("p@ss:w#rd", safe="")          # p%40ss%3Aw%23rd

proxy = f"http://{user}:{pwd}@gate.quantumproxies.io:8000"
Контрольный список, сопоставляющий симптомы 407 требуется аутентификация прокси с их реальными причинами, включая сбои туннелей, изменения белых списков и настройки прокси для каждого инструмента
Один и тот же код состояния, шесть разных неисправностей. Сопоставьте симптом слева, прежде чем что-либо менять.

Причина 3: аутентификация по белому списку и IP, который изменился

Большинство провайдеров поддерживают два режима аутентификации: учетные данные в URL или белый список IP, где вы авторизуете публичный адрес вашего сервера на панели управления и не отправляете никаких учетных данных. QuantumProxies поддерживает оба. Режим сбоя специфичен и очень узнаваем: все работало неделями, затем каждый запрос начал возвращать 407 без изменения кода. Это ваш публичный IP изменился — обновление аренды DHCP в офисе, новый шлюз NAT после развертывания облака, мобильная привязка или CI-раннер, который получает новый адрес на каждую задачу.

Подтвердите это, прежде чем отлаживать что-либо еще: получите ваш текущий публичный адрес с помощью curl -sS https://api.ipify.org, сравните его с белым списком и добавьте его снова, если он отличается. Если ваш выходной IP нестабилен — CI-раннеры и группы автоматического масштабирования редко стабильны — переключите эту среду на аутентификацию user:pass, которая перемещается с конфигурацией, а не с сетью. Другая половина этой ловушки — смешивание режимов: некоторые шлюзы отклоняют учетные данные на конечной точке только по белому списку, поэтому отправка обоих может не сработать там, где отправка ни одного из них успешна.

Причина 4: HTTPS проходит через туннель CONNECT

407, который появляется только на https:// URL, часто как ошибка Python OSError: Tunnel connection failed: 407 Proxy Authentication Required, имеет структурную причину. Простые HTTP-запросы пересылаются прокси, но HTTPS-запросы сначала открывают туннель с запросом CONNECT — и этот CONNECT несет свой собственный заголовок Proxy-Authorization. Если ваша конфигурация установила только HTTP-прокси или установила учетные данные на одной схеме, а не на другой, туннель пытается анонимно и отклоняется до начала TLS.

Правило простое: всегда настраивайте обе схемы с одними и теми же учетными данными. В Python это означает оба ключа в словаре proxies; в командной строке это означает HTTP_PROXY и HTTPS_PROXY; в npm это означает proxy и https-proxy. Обратите внимание, что HTTPS_PROXY почти всегда принимает схему http:// — схема описывает, как вы общаетесь с прокси, а не то, что вы извлекаете через него.

// Node 18+ with undici: one dispatcher covers http and https targets
import { ProxyAgent, fetch } from "undici";

const dispatcher = new ProxyAgent(
  "http://USER:PASS@gate.quantumproxies.io:8000"
);

const res = await fetch("https://httpbin.org/ip", { dispatcher });
console.log(res.status, await res.json());

Причина 5: инструмент имеет свою собственную конфигурацию прокси

Переменные окружения не универсальны. Множество инструментов читают свой собственный файл конфигурации и полностью игнорируют оболочку, что создает раздражающее состояние, когда curl работает, а ваша сборка — нет. Долгосрочная проблема GitHub Desktop является учебным примером: разработчик за корпоративным прокси установил прокси в .gitconfig и в окружении, но вход все равно не удавался с 407 и net::ERR_TUNNEL_CONNECTION_FAILED — потому что конфигурация git аутентифицировала только git, в то время как встроенный браузер, выполняющий OAuth-поток, не имел собственных учетных данных прокси. Каждой подсистеме нужно сообщать отдельно.

# shell-wide (respected by curl, wget, pip, most SDKs)
export HTTP_PROXY="http://USER:PASS@gate.quantumproxies.io:8000"
export HTTPS_PROXY="$HTTP_PROXY"
export NO_PROXY="localhost,127.0.0.1,.internal"

# npm - both keys, or https installs will 407
npm config set proxy       "$HTTP_PROXY"
npm config set https-proxy  "$HTTPS_PROXY"

# git
git config --global http.proxy  "$HTTP_PROXY"
git config --global https.proxy "$HTTPS_PROXY"

# apt - /etc/apt/apt.conf.d/95proxies
# Acquire::http::Proxy  "http://USER:PASS@gate.quantumproxies.io:8000";
# Acquire::https::Proxy "http://USER:PASS@gate.quantumproxies.io:8000";

Одна заметка по безопасности, пока вы редактируете все эти файлы: учетные данные в глобальной конфигурации git или npm оказываются в виде открытого текста, а URL прокси с встроенными паролями просачиваются в историю оболочки, журналы CI и трассировки ошибок. На машинах с стабильным адресом белый список IP полностью избегает секрета.

Сравнение аутентификации прокси user:pass и аутентификации по белому списку IP, показывающее переносимость и компромиссы в обработке секретов
Учетные данные перемещаются с вашей конфигурацией; белые списки перемещаются с вашей сетью. Выбирайте для каждой среды, никогда не используйте оба сразу.

407 никогда не является виной целевого сайта

Это стоит повторить, потому что это спасает вас от погони за призраками. Если вы получаете 407, никакое количество вращающихся пользовательских агентов, добавления заголовков или изменения выходных стран не поможет — запрос еще не покинул ваш прокси. Блокировки, исходящие от цели, выглядят иначе: 403 Forbidden означает, что сайт отказал вам, а 429 Too Many Requests означает, что вы шли слишком быстро. Определите, какой из трех у вас на самом деле, прежде чем писать какой-либо код. И если Python выдает ProxyError или SSLError вместо чистого 407, наше руководство по отладке ProxyError в Requests охватывает сбои на уровне транспорта.

Часто задаваемые вопросы

Как устранить 407 Требуется аутентификация прокси?

Поместите действительные учетные данные в URL прокси в виде http://user:pass@host:port, закодировав процентами любые зарезервированные символы, и настройте как HTTP, так и HTTPS настройки прокси. Если ваш провайдер использует белый список IP вместо этого, авторизуйте ваш текущий публичный IP и не отправляйте учетные данные. Проверьте с помощью curl -x против эхо-сервиса IP перед изменением кода вашего приложения.

Что означает 407 Требуется аутентификация прокси?

Это означает, что промежуточный прокси отклонил запрос из-за отсутствия действительных учетных данных прокси. Ответ включает заголовок Proxy-Authenticate, указывающий схему, и ожидается, что клиент повторит попытку с Proxy-Authorization. Это отличается от 401, который исходит от сервера назначения, а не от прокси между ними.

Как исправить ошибку npm 407?

Установите оба ключа: npm config set proxy и npm config set https-proxy, каждый с полным URL http://user:pass@host:port. Трафик реестра идет по HTTPS, поэтому настройка только HTTP не удается на туннеле CONNECT. Закодируйте процентами специальные символы в пароле и проверьте наличие проектного .npmrc, переопределяющего ваш глобальный.

Почему Python выдает Tunnel connection failed: 407?

Потому что HTTPS-запрос открыл туннель CONNECT, который не нес прокси-учетных данных. Установите оба ключа http и https в словаре proxies на тот же URL с аутентификацией. Также проверьте, не переопределяет ли ваш словарь HTTP_PROXY или HTTPS_PROXY в окружении — установите session.trust_env = False, чтобы исключить это.

Как установить аутентификацию прокси в Postman?

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

Пять причин охватывают практически каждый 407 в природе: отсутствующие учетные данные, не закодированные специальные символы, изменившийся IP в белом списке, неаутентифицированный туннель CONNECT и инструмент с собственной конфигурацией. Работайте с ними в этом порядке, и код состояния исчезнет — затем вы можете начать беспокоиться о том, что целевой сайт думает о вас.

Получите резидентные прокси с аутентификацией user:pass или по белому списку IP