Как устранять коды ошибок статуса проксиЧтение 4xx, 5xx и разорванных соединений

Ошибка прокси, это редко загадка, если воспринимать её как предложение. Код статуса говорит вам, кто дал сбой (ваш клиент, прокси или цель), а тело или заголовки обычно объясняют причину. Сложность в том, что один и тот же код может означать разные вещи в зависимости от того, поступил ли он с прокси-сервера или с исходного сервера, и именно эта неоднозначность заставляет людей блуждать по кругу. 403 от цели, это блокировка; 407 от прокси, проблема аутентификации; 502 может прийти от любой стороны при таймауте. Определите, какой уровень говорит, и решение почти всегда окажется очевидным.

Это справочник, который можно держать открытым во время отладки. Он сопоставляет коды статусов, с которыми вы реально сталкиваетесь при скрапинге через прокси-сервер, с тем, что они означают в контексте прокси, и объясняет, как их устранить, с акцентом на специфику прокси (аутентификация, лимиты запросов, сбои шлюза, геоблокировки) вместо обобщённых формулировок. Просмотрите таблицу, перейдите к своему коду и примените исправление.

Коды ошибок прокси, быстрый обзор

Начните здесь. Таблица охватывает коды, которые реально останавливают скрапинг; разделы ниже подробнее рассматривают те из них, которые имеют специфику прокси.

Одно правило чтения перед деталями: спросите, какой переход сгенерировал код. 4xx с пометкой «proxy» (407) говорит сам прокси; почти все остальные 4xx, это цель, говорящая через работающий прокси. 5xx, приходящий мгновенно, обычно означает, что прокси не смог добраться до вышестоящего сервера; 5xx после долгой паузы, как правило, таймаут на стороне исходного сервера. Одно это различие ведёт вас к правильному исправлению быстрее, чем запоминание каждого кода.

4xx: запрос дошёл до цели и был отклонён

Это означает, что запрос прошёл, но был отвергнут. За одним исключением (407) прокси выполнил свою работу, а вердикт вынес исходный сервер.

403 Forbidden: вас заблокировали, но не навсегда

Этот код скраперы видят чаще всего. Цель приняла соединение, изучила запрос и решила не отвечать. В контексте прокси это почти всегда означает, что выходной IP был помечен (известный диапазон дата-центра или уже превысивший лимит адрес) или что отпечаток запроса выглядел автоматизированным (отсутствующие или стандартные заголовки, нереалистичный User-Agent, порядок заголовков, не характерный ни для одного браузера).

Исправление многоуровневое. Сначала сменить выходной IP и повторить попытку: одна блокировка не означает, что весь пул сгорел. Если чистые IP тоже получают 403, проблема в доверии, а не в удаче: защищённая цель блокирует диапазоны дата-центров с порога, поэтому перейдите к резидентным. Смотрите статью дата-центр vs резидентные прокси, чтобы понять, где проходит эта граница. Если ротация и более высокий уровень доверия не помогают, блокировка идёт на уровне отпечатка, и вам нужны реалистичные заголовки, а нередко и рендеринг страницы вместо «сырого» запроса. Полное руководство по этой теме, в статье как парсить без блокировок.

407 Proxy Authentication Required: спрашивает прокси, а не сайт

407, единственный из 4xx, исходящий именно от прокси-узла, и чаще всего неверно понимается. Цель вообще не видела ваш запрос; прокси отказался его пересылать, потому что вы не прошли аутентификацию на прокси. Причин две: неверные или отсутствующие учётные данные, либо прокси с белым списком IP, который не распознаёт адрес, с которого вы обращаетесь.

Передайте учётные данные в URL прокси или добавьте ваш IP в белый список в панели управления провайдера, в зависимости от того, какой режим аутентификации использует ваш план. В curl учётные данные передаются в аргумент -x, а не в запрос к цели.

# 407 fix: authenticate TO the proxy in the -x URL.
# user:pass here are the proxy's credentials, not the site's.
curl -x "http://USER:[email protected]:8080" \
     "https://httpbin.org/ip"

# IP-whitelist plans take no credentials; the proxy
# checks your source IP instead. Confirm it is allowed.

Если вы успешно аутентифицируетесь на каждом другом запросе, а один внезапно бросает 407, проверьте, не изменился ли ваш исходящий IP (новый контейнер, VPN, раннер CI), и повторно добавьте его в белый список. Больше паттернов curl и прокси, в статье как использовать curl с прокси.

401 Unauthorized: цель требует учётные данные

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

400 Bad Request: само сообщение сломано

400 означает, что запрос был некорректно сформирован ещё до оценки его содержимого: неверный синтаксис, плохое URL-кодирование, дублирующиеся или слишком большие заголовки, или тело, не соответствующее заявленному типу контента. При работе через прокси обращайте внимание на двойное кодирование, когда вы передаёте целевой URL как параметр запроса к API, и на инъекцию заголовков при конкатенации строк. Логируйте точные отправляемые байты и перечитывайте их; дефект почти всегда в вашем конструкторе запросов, а не в сети.

429 Too Many Requests: вы превысили лимит запросов

Вы отправили больше запросов, чем цель (или ваш план прокси) допускает за определённое время. Честное исправление, замедлиться и распределить нагрузку: добавьте задержку между запросами, ограничьте параллелизм и ротируйте выходные IP, чтобы нагрузка распределялась по многим адресам вместо одного. Соблюдайте заголовок Retry-After, если ответ его содержит, вместо слепых повторных попыток.

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

451 Unavailable For Legal Reasons: геоблокировка или блокировка по политике

451 означает, что контент недоступен по юридическим или региональным причинам, а не из-за технической неисправности. В контексте прокси это обычно геоблокировка: выходной IP находится в регионе, который цель не обслуживает. Исправление, выйти из разрешённой страны. Выберите прокси с геотаргетингом и убедитесь, что он действительно покрывает нужный регион, затем проверьте выходную локацию через эхо-сервис, прежде чем предполагать наличие покрытия.

5xx: сбой на вышестоящем узле, но на каком именно?

Они приходят от сервера, а не из-за вашего запроса, однако через прокси «сервер» неоднозначен: это может быть прокси, не достигший исходного сервера, или сам исходный сервер, давший сбой. Время помогает их различить.

502 Bad Gateway: прокси получил мусор от вышестоящего сервера

502 означает, что шлюз (в данном случае ваш прокси) получил неверный или пустой ответ от сервера, к которому пытался обратиться. Обычно приходит быстро, потому что прокси сдался быстро. Причины делятся на две категории: нездоровый или неправильно настроенный прокси, либо мёртвый вышестоящий выходной IP. Сначала повторите попытку, поскольку 502 часто бывает транзиентным; если повторные попытки продолжают давать сбой, переключитесь на другой выходной IP и убедитесь, что сам прокси-эндпоинт работает, отправив запрос к известному хорошему эхо-сервису через него. Если и это даёт 502, проблема на уровне прокси, а не цели.

503 Service Unavailable: перегрузка или недоступность

503 означает, что сервер временно не может обработать запрос: перегружен, на обслуживании или сбрасывает нагрузку. Через прокси это может быть цель, конкретно сбрасывающая ваш трафик (мягкая блокировка под видом 503), или реальный сбой для всех. Откатитесь и повторите попытку с джиттером; если один выходной IP получает 503, пока другие успешны, этот IP тротлируется, ротируйте. Если все выходные IP одновременно получают 503, цель недоступна и остаётся только ждать.

504 Gateway Timeout: кто-то в цепочке исчерпал время

504, таймаут на шлюзовом переходе: прокси ждал исходного сервера, а тот так и не ответил вовремя, либо сам прокси отвечал слишком медленно. В отличие от 502, он приходит после долгой паузы. Увеличьте таймаут клиента для действительно медленных страниц, повторите попытку (таймауты часто бывают транзиентными) и смените выходы, если один маршрут постоянно медлит. Если страницам требуется браузер для завершения рендеринга, «сырой» запрос может выглядеть как таймаут, тогда как реальная проблема, неполное выполнение JavaScript, что решает уровень рендеринга, а не увеличение таймаута.

Сбои на уровне соединения: HTTP-код вообще не был получен

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

Connection refused означает, что по указанному хосту и порту ничего не слушало: неверный порт, неверный хост, прокси не запущен или несоответствие схемы (отправка HTTP на эндпоинт только для HTTPS). Проверьте точные host:port и протокол, предоставленные провайдером.

Connection reset / timeout означает, что сокет открылся, но был сброшен или не ответил: мёртвый выходной IP, агрессивный файрвол или цель, молча сбрасывающая помеченный трафик. Повторите с новым выходом; если сбросы группируются на одном IP, он сгорел. TLS / certificate errors через прокси обычно означают, что что-то прерывает TLS посередине. Используйте туннелирование через CONNECT для HTTPS, чтобы прокси ретранслировал зашифрованные байты без их инспекции; подробности, в статье HTTP vs HTTPS прокси.

Как заставить целые классы ошибок исчезнуть

Обратите внимание на паттерн в таблице: 403, 429, 502, 503 и большинство сбросов соединений имеют одно общее исправление, сменить выходной IP и повторить попытку. Реализация этого самостоятельно требует здорового пула, политики ротации, экспоненциального отката с джиттером и логики повторных попыток по коду. Управляемый ротируемый эндпоинт делает всё это за вас, что и объясняет, почему несколько классов ошибок просто перестают появляться после того, как ротация и повторные попытки переносятся на сторону сервера.

Цикл повторных попыток, читающий код

Какой бы прокси вы ни использовали, ваш клиент должен реагировать на код статуса, а не обрабатывать все сбои одинаково. Минимальный вариант: повторяйте транзиентные классы с откатом, ротируйте при блокировке конкретного IP и останавливайтесь при настоящей ошибке клиента, которую повторными попытками не исправить.

import time, requests

RETRY = {429, 502, 503, 504}  # transient: back off and retry
ROTATE = {403, 429}        # per-IP: try a fresh exit

def fetch(url, get_proxy, tries=5):
    for n in range(tries):
        proxy = get_proxy()  # new exit IP each call
        r = requests.get(url, proxies=proxy, timeout=30)
        if r.status_code == 200:
            return r
        if r.status_code not in RETRY and r.status_code not in ROTATE:
            r.raise_for_status()  # 400/401/451: stop, fix the request
        wait = int(r.headers.get("Retry-After", 2 ** n))
        time.sleep(wait)
    r.raise_for_status()

Важна структура, а не язык: классифицируйте код, откатывайтесь при транзиентных сбоях, ротируйте при блокировках на конкретном IP и быстро падайте при ошибках, которые повторными попытками не исправить. Управляемый эндпоинт складывает часть «ротируй и повтори» в себя, оставляя вашему циклу обработку только настоящих ошибок клиента.

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

В чём разница между ошибками прокси 403 и 407?

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

Как исправить ошибку 429 Too Many Requests при скрапинге?

Замедлитесь и распределите нагрузку. Добавьте задержку между запросами, ограничьте параллелизм и соблюдайте заголовок Retry-After, если он присутствует, вместо немедленных повторных попыток. Поскольку лимиты обычно считаются на IP, ротация выходного IP, структурное исправление: каждый новый адрес начинает с чистой квоты. Комбинирование интервалов с ротацией устраняет подавляющее большинство 429.

Что вызывает 502 Bad Gateway через прокси?

502 означает, что ваш прокси (выступающий в роли шлюза) получил неверный или пустой ответ от сервера, к которому пытался обратиться. Обычно приходит быстро. Причина, либо нездоровый прокси, либо мёртвый вышестоящий выходной IP. Сначала повторите попытку, поскольку многие 502 транзиентны; если они продолжаются, переключитесь на другой выходной IP и убедитесь, что сам прокси-эндпоинт работает, отправив запрос к известному хорошему эхо-сервису через него.

Почему я получаю connection refused вместо HTTP-кода ошибки?

Connection refused, это сбой на уровне сокета, происходящий до возможности получить какой-либо HTTP-ответ: по указанному хосту и порту ничего не слушало. Убедитесь, что хост, порт и схема прокси точно соответствуют данным провайдера, что процесс прокси запущен и что вы не отправляете обычный HTTP на эндпоинт только для HTTPS. Это ошибка конфигурации, а не отклонение вашего запроса.

Могут ли ротируемые прокси устранить коды ошибок прокси?

Ротация устраняет классы ошибок на конкретный IP, прежде всего 403-блокировки и 429-лимиты, поскольку оба сбрасываются при смене выходного IP; она также помогает с транзиентными 5xx, повторяя попытку по новому маршруту. Она не исправляет коды, вызванные вашим собственным запросом (400 или 401), или юридические геоблокировки (451). Дополните ротацию корректным формированием запросов и геотаргетингом для покрытия остального.

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

Нет. Повторяйте транзиентные классы (429, 502, 503, 504) с экспоненциальным откатом и джиттером и ротируйте выходной IP при блокировках на конкретном IP (403, 429). Не повторяйте слепо ошибки клиента, которые вы сами вызвали (400, 401, 451): повторная попытка с тем же запросом снова даст сбой и может продлить период охлаждения при лимите. Сначала классифицируйте код, затем выберите: повторить, ротировать или остановиться.

HR

Hassan Rehan

Инженер-программист · Crawlbase

Инженер-программист в Crawlbase, пишет практические руководства по ротирующимся прокси, скрейпингу и тонкостям подключения прокси к реальному коду.