Ошибка прокси-сервера 407, 403 или 502? Сначала узнайте, кто её прислал

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

Короткая шпаргалка по кодам есть в статье почему прокси не работает. Здесь разбор глубже, с заголовками ответа.

Кто прислал код: прокси или сайт

К HTTPS-сайту через HTTP-прокси запрос идёт в два этапа. Сначала программа отправляет прокси команду CONNECT с именем сайта и портом 443, прокси решает, пускать ли, и отвечает своим кодом. Ответ 200 Connection established открывает туннель. Всё, что идёт внутри, зашифровано: прокси это не читает и подменить не может.

Отсюда правило на все случаи. Код до туннеля прислал прокси. Код изнутри туннеля прислал сайт.

Видно это в подробном выводе curl (в Windows вместо /dev/null пишите NUL):

curl -v -x http://LOGIN:PASS@IP:PORT https://example.com -o /dev/null

Фрагмент вывода при отказе в авторизации выглядит так, realm у вашего прокси будет своим:

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="proxy"
curl: (56) CONNECT tunnel failed, response 407

Строки со знаком > ушли от вас, строки со знаком < пришли в ответ. Ошибка сразу после CONNECT значит, что до сайта запрос даже не дошёл. Если CONNECT вернул 200, а ниже, уже после строк о TLS, стоит 403 или 429, это ответ сайта. Старые версии curl пишут тот же отказ другими словами: Received HTTP code 407 from proxy after CONNECT.

С обычными http-адресами туннеля нет. Прокси сам пересылает запрос и возвращает ответ, поэтому отправителя выдают заголовки: Server с именем программы, которая ответила, Via, который добавляют прокси по пути, и тело страницы с ошибкой, где прокси часто подписывается.

Ошибка прокси-сервера по кодам: семь разборов

407 Proxy Authentication Required

Код прокси по определению. Стандарт обязывает прокси прислать вместе с ним заголовок Proxy-Authenticate, где названа схема авторизации: Basic, Digest, NTLM или Negotiate. Программа должна повторить запрос с заголовком Proxy-Authorization. Оба заголовка живут только на участке до ближайшего прокси и дальше не уходят, так что сайт ваш пароль от прокси не увидит.

Виноват доступ к прокси. Причины по частоте:

• логин или пароль неверны или программа не передаёт их вовсе;

• в пароле есть @, двоеточие или слеш без кодирования (%40, %3A, %2F), и строка разрезана в неправильном месте;

• авторизация по IP, и ваш внешний адрес сменился;

• программа знает только Basic, прокси просит NTLM.

Что делать: прочитать Proxy-Authenticate, сверить схему, перепроверить логин в кабинете, обновить привязку IP. Повторять запрос без исправлений бессмысленно, 407 вернётся ровно такой же.

403 Forbidden

Здесь отправителей два, и путают их постоянно.

Если 403 пришёл на этапе CONNECT, вас не пускает прокси. Типичная причина: правила доступа запрещают такой адрес или порт. У Squid в стандартной настройке туннель разрешён только на порт 443, и CONNECT на любой другой порт получит 403 с заголовком X-Squid-Error: ERR_ACCESS_DENIED. У части провайдеров так же выглядит отказ по привязке IP.

Если 403 пришёл изнутри туннеля, это сайт. Он увидел адрес, запросы с которого ему уже не нравятся, и закрыл доступ. Менять настройки программы тут бесполезно. Нужен другой IP и спокойнее темп, иногда ещё нормальные заголовки браузера вместо голого User-Agent библиотеки.

429 Too Many Requests

Самый честный код. Сайт посчитал ваши запросы и упёрся в свой лимит.

Код описан в RFC 6585, и к нему можно приложить заголовок Retry-After: число секунд или точную дату, после которой стоит пробовать снова. Если заголовок есть, слушайтесь его. На одном прогоне по каталогу я гнал 40 потоков через один адрес, сайт на трёхсотом запросе ответил 429 с Retry-After: 600, а скрипт этот заголовок игнорировал и повторял через секунду, так что через десять минут адрес получил уже 403 и не открывал сайт до утра.

Что помогает: выдержать паузу из Retry-After, без него наращивать паузу ступенями, и распределять запросы по многим адресам, чтобы счётчик на каждом не добегал до лимита.

400 Bad Request

Запрос сломан, и сломал его ваш клиент: битая строка, лишний пробел или кривой заголовок.

Варианты в работе с прокси:

• строка прокси с пробелом, кириллицей или лишним символом, и программа собирает из неё кривой запрос;

• в адресе HTTP-прокси указана схема https://, клиент начинает с ним TLS-рукопожатие, прокси получает вместо запроса двоичный мусор и отвечает 400 открытым текстом. curl в ответ ругается на SSL;

• программа шлёт SOCKS5-приветствие на HTTP-порт;

• слишком большие заголовки или куки: nginx на стороне сайта отвечает 400 с текстом Request Header Or Cookie Too Large.

Первые три лечатся правкой строки прокси, четвёртый чисткой кук.

502 Bad Gateway

По стандарту 502 значит, что шлюз или прокси получил от следующего сервера некорректный ответ. На практике прокси не смог соединиться с сайтом или получил обрубок. Тот же код умеет отдавать и балансировщик самого сайта, поэтому снова смотрите на этап: на CONNECT это прокси, внутри туннеля это сайт.

Один повтор через 2-5 секунд закрывает случайные сбои. Держится 502 на одном сайте и не трогает остальные? Проблема у сайта. Сыплется на всех сайтах сразу? Пишите провайдеру прокси и приложите вывод curl -v.

503 Service Unavailable

Сервер временно не может обработать запрос: перегрузка или обслуживание. Стандарт разрешает приложить Retry-After, как у 429. Сайты часто отдают 503 вместе со страницей проверки на бота, и тогда это ближе к 403 по смыслу. Часть прокси отвечает 503, когда не смогла соединиться с сайтом, например Squid при сбое соединения. Отличите по этапу и по заголовку Server.

504 Gateway Timeout

Прокси ждал ответа сайта и не дождался. Не путайте с собственным таймаутом клиента: при 504 прокси вам ответил, при curl: (28) не ответил никто. Виноват медленный сайт или слишком плотный поток запросов к нему, и поднимать таймаут в своей программе бесполезно, ждёт-то прокси. Снижайте число параллельных запросов к этому сайту.

Заголовки ответа, которые экономят час

Тело страницы с ошибкой часто пустое или красивое и бесполезное. Заголовки честнее. Посмотреть их без загрузки страницы можно так:

curl -s -D - -o /dev/null -x http://LOGIN:PASS@IP:PORT https://example.com

На что смотреть:

• Proxy-Authenticate приходит с 407 и называет схему авторизации и realm.

• Retry-After приходит с 429 и 503: секунды или дата.

• Server называет программу, которая ответила: nginx, cloudflare, squid.

• Via добавляют прокси по пути, по нему видна цепочка.

• X-Squid-Error ставит Squid и пишет внутренний код ошибки.

Набор заголовков отвечает на главный вопрос быстрее, чем любой текст ошибки. За пять лет прогонов я ни разу не нашёл причину 403 в теле страницы, зато в заголовке Server нашёл десятки раз.

Какие коды повторять и через сколько

Слепой повтор после каждой ошибки превращает 429 в 403, а 403 в бан адреса на сутки. Политика повторов по кодам:

1. 400 и 407: без повтора. Чинить строку прокси или доступ.

2. 403 от прокси: без повтора. Разбираться с правилами доступа или привязкой IP.

3. 403 от сайта: повтор только с новым IP, пауза от 30 секунд.

4. 429 и 503 с Retry-After: ждать ровно столько, сколько сказано.

5. 429 и 503 без него: паузы 5, 10, 20, 40 секунд с небольшим случайным разбросом.

6. 502 и 504: один-два повтора через 2-5 секунд, потом пауза и снижение потоков.

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

Когда 403 и 429 идут потоком

Все строки исправлены, 407 и 400 ушли, а сайт продолжает отвечать 403 и 429 через раз. Это лимит на адрес. Сайт считает запросы по IP, и сколько ни подбирай паузы, один адрес выдерживает ограниченный поток.

Снимает проблему пул, где адрес меняется сам, плюс разумный темп. Отсюда простое решение: купить приватные прокси с пулом, где новый IP получает каждый запрос, и счётчик сайта на отдельном адресе просто не успевает набежать. У WinGate такой пул работает как https прокси и как SOCKS5, держит до 5000 потоков с безлимитным трафиком, так что повторы по политике выше не упираются в объём трафика. Подключение по IP или строкой IP:PORT:LOGIN:PASS. Для такой задачи подходит аренда ipv4 с привязкой по IP: пароля в строке нет вовсе, и 407 из-за символа @ не случится. Запустите тот же прогон через тестовый пул WinGate и сравните долю 403 и 429 в логе. Тест бесплатный и длится до 2 часов.