Коды ошибок прокси: как исправить 407, 403, 429, 502 и таймауты

Код ошибки прокси показывает, на каком уровне остановился запрос. 407 означает, что прокси вас не узнал, 403 и 429 чаще всего говорят о том, что запрос отклонил целевой сайт, а 502 и 504 — что оборвалось соединение между прокси и целевым сервером. Таймауты и сообщения «tunnel connection failed» читаются по той же логике: сначала выясните, кто сгенерировал ошибку, а затем исправляйте именно этот уровень.

В этом руководстве самые частые коды разбиты на три группы: аутентификация, отказ со стороны целевого сайта и сетевые ошибки/таймауты. Для каждой мы приводим типичную причину, место, куда смотреть в первую очередь, и то, как ошибка выглядит в cURL и Python. В примерах используется адрес шлюза WeProxy gw.weproxy.com.tr:8989; USER и PASSWORD — ваши данные из личного кабинета.

Кто сгенерировал ошибку: прокси или целевой сайт?

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

При HTTPS-запросах клиент сначала отправляет прокси CONNECT example.com:443. Если прокси отвечает 200 Connection Established, туннель установлен, и любой HTTP-код после этого принадлежит целевому сайту. Если прокси туннель не установил, ошибка приходит в ответе на CONNECT: 407, 403, 502 и т. п. Быстрее всего увидеть эту разницу в выводе curl -v:

curl -v -x "http://USER:[email protected]:8989" https://api.ipify.org

Если в выводе есть строка < HTTP/1.1 200 Connection established, прокси свою работу выполнил. Если ошибка появляется после этой строки, проблема на стороне цели. Если ошибочен ответ на CONNECT, проблема в соединении с прокси. В обычных HTTP-запросах (без TLS) CONNECT нет; здесь источник кода выдают заголовки ответа вроде Server, Via или cf-ray.

Общее правило:

• 407 всегда приходит от прокси.
• 403, 429 и CAPTCHA — чаще всего решение целевого сайта.
• 502, 503, 504 говорят о том, что прокси не смог достучаться до цели или не получил ответ вовремя.
• Клиентские ошибки (curl: (7), ProxyError, ERR_PROXY_CONNECTION_FAILED) появляются, когда до прокси не удалось достучаться, и HTTP-код даже не успевает сформироваться.

407 Proxy Authentication Required

407 означает, что прокси не принимает запрос без аутентификации. Этот код определён в RFC 9110: прокси отправляет в ответе заголовок Proxy-Authenticate, а клиент в следующем запросе передаёт учётные данные в Proxy-Authorization.

Самые частые причины:

1. Неверный логин или пароль. При копировании из личного кабинета очень часто захватывается пробел в начале или в конце.
2. Спецсимволы не закодированы. Если в пароле есть @, :, /, # или %, внутри URL прокси его нужно процентно кодировать. Пароль p@ss в URL записывается как p%40ss. Без кодирования клиент примет всё после @ за хост.
3. Не совпадает whitelist по IP. Если вы работаете через авторизацию по IP без передачи учётных данных, IP, с которого вы выходите в сеть, должен быть добавлен в личном кабинете. Если у домашнего интернета сменился IP или сервер выходит с другого IPv6-адреса, вы получите 407.
4. Клиент не отправляет учётные данные. Одни библиотеки читают данные прокси только из URL, другие требуют отдельный параметр. Браузерные расширения при прокси с паролем ожидают всплывающее окно.
5. Срок действия или баланс пакета. Данные неактивного пакета не принимаются, даже если они верные. Проверьте статус пакета в личном кабинете.

В пакетах WeProxy авторизация по логину/паролю и белый список IP могут использоваться одновременно — как для HTTP, так и для SOCKS5. Если вы используете учётные данные в нескольких инструментах, не набирайте формат вручную, а конвертируйте между ip:port:user:pass и URL-форматом с помощью конвертера форматов прокси.

Безопасное кодирование пароля в Python:

from urllib.parse import quote

user = "USER"
password = quote("p@ss:w0rd/1", safe="")
proxy = f"http://{user}:{password}@gw.weproxy.com.tr:8989"
proxies = {"http": proxy, "https": proxy}

403 Forbidden и 429 Too Many Requests

403 означает, что запрос понят, но отклонён. При работе через прокси его чаще всего генерирует защитный слой целевого сайта (WAF, антибот-защита, правило CDN). Если 403 возвращает сам прокси, обычно это происходит на этапе CONNECT — для запрещённого порта или цели.

Типичные причины 403 со стороны цели: низкая репутация IP-адреса, неподходящий для сайта тип IP (например, сайт массово блокирует датацентровые IP), ограничение по стране или заголовки запроса, не похожие на настоящий браузер. Сменить IP — первый рефлекс, но пока не исправлена согласованность User-Agent, Accept-Language и cookies, новый IP получит тот же ответ.

429 — это явный лимит частоты запросов. Код определён в RFC 6585, и сервер обычно сообщает в заголовке Retry-After, сколько нужно подождать. Счётчик, как правило, ведётся по IP и срабатывает, когда вы отправляете много одновременных запросов с одного выходного IP.

В пакетах WeProxy нет ограничений на число одновременных соединений и потоков. Поэтому, если вы получили 429, лимит почти всегда выставляет целевой сайт. Что делать:

• Соблюдайте значение Retry-After, а если его нет — используйте экспоненциальную задержку (1, 2, 4, 8 секунд).
• Снизьте параллельность, сосредоточенную на одном IP.
• Смена IP на каждый запрос подходит для задач, не требующих сессии. Для задач с сессией используйте sticky-сессию; разницу разбираем в руководстве sticky vs rotating.
• Для целей, где нужен IP с высоким уровнем доверия, выбирайте ротационные резидентные прокси, а если нужна одна долгоживущая идентичность — ISP-прокси.

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

502, 503 и 504: прокси не смог достучаться до цели

Эти три кода относятся к семейству «gateway» и говорят о проблеме на стороне цели, с которой столкнулся прокси.

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

503 Service Unavailable: целевой сервер или промежуточный слой временно не обслуживает запросы. Этот код возвращает страница техработ целевого сайта или защита от перегрузки. Если есть Retry-After, соблюдайте его.

504 Gateway Timeout: прокси не получил ответ от цели вовремя. Причиной бывает медленный API, удалённая география или тяжёлая страница. Чтобы сократить расстояние между прокси и целью, выбирайте страну выхода поближе к целевому серверу.

Чтобы различить случаи, откройте тот же URL и без прокси. Если ошибка есть и без прокси, проблема на целевом сайте. Если она возникает только через прокси и исчезает при повторе, проблема в отдельном выходном узле пула. Если ошибка повторяется постоянно, сообщите в поддержку, с какой целью, в какое время и на каком пакете это происходит.

Таймауты и ошибки соединения

Таймаут возникает на двух разных этапах, и каждый говорит о своём:

• Connect timeout: клиент не смог открыть TCP-соединение с прокси. Неверный адрес шлюза, закрытый порт или соединение блокирует локальная сеть/файрвол.
• Read timeout: соединение установлено, но время ожидания ответа истекло. Обычно причина в медленной цели или длинной цепочке ответов.

Чтобы их различать, задайте в библиотеке два отдельных значения. Для Python requests timeout=(10, 30) даёт 10 секунд на подключение и 30 на чтение. Если указать одно значение, оба этапа используют его, и диагностика усложняется.

Если до прокси вообще не удаётся достучаться, сначала проверьте локальную сторону: с помощью инструмента проверки портов убедитесь, что порт 8989 на gw.weproxy.com.tr виден открытым снаружи, а затем — что ваша сеть разрешает исходящие соединения на этот порт. Корпоративные сети и некоторые облачные провайдеры закрывают исходящий трафик на нестандартные порты.

В браузерах та же ситуация отображается под другими именами. Chrome показывает ERR_PROXY_CONNECTION_FAILED, когда не может подключиться к прокси, и ERR_TUNNEL_CONNECTION_FAILED, когда подключился к прокси, но не смог установить туннель. Во втором случае за ошибкой стоит ответ прокси вроде 407 или 502.

Таблица кодов ошибок

curl: (35) чаще всего появляется при попытке подключиться к HTTP-прокси со схемой https://. Схема в URL прокси описывает протокол самого прокси, а не цели. Даже для HTTPS-целей адрес прокси записывается с http://.

Ответы об ошибках SOCKS5

SOCKS5 не использует HTTP-коды. По RFC 1928 на запрос соединения приходит ответ с полем «reply». Библиотеки обычно показывают это значение в виде сообщения:

Аутентификация в SOCKS5 — отдельный шаг (RFC 1929). Если логин/пароль отклонены, соединение закрывается с сообщением вроде «authentication failed»; это аналог 407 в HTTP. Чтобы DNS разрешался на стороне прокси, используйте socks5h:// вместо socks5://, иначе возникнет утечка DNS. Подробнее — в руководстве по утечкам DNS, а разница протоколов — в статье HTTP vs SOCKS5.

Перехват ошибок и повторные попытки в Python

requests выдаёт ошибки прокси в виде отдельных типов исключений. Если ловить их все одним except, диагностика теряется. Пример ниже повторяет запрос с задержкой при временных кодах (429, 502, 503, 504), а постоянные ошибки сообщает по отдельности:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

proxy = "http://USER:[email protected]:8989"

retry = Retry(
    total=5,
    backoff_factor=1,
    status_forcelist=[429, 502, 503, 504],
    allowed_methods=["GET", "HEAD"],
    respect_retry_after_header=True,
)

session = requests.Session()
session.mount("http://", HTTPAdapter(max_retries=retry))
session.mount("https://", HTTPAdapter(max_retries=retry))
session.proxies = {"http": proxy, "https": proxy}

try:
    r = session.get("https://api.ipify.org?format=json", timeout=(10, 30))
    print(r.status_code, r.text)
except requests.exceptions.ProxyError as e:
    print("Прокси отклонил запрос или недоступен (407 / соединение):", e)
except requests.exceptions.ConnectTimeout:
    print("Таймаут подключения к прокси: проверьте порт и файрвол")
except requests.exceptions.ReadTimeout:
    print("Цель не ответила: измените таймаут чтения или страну выхода")
except requests.exceptions.SSLError as e:
    print("Ошибка TLS: проверьте схему прокси", e)

Для HTTPS-целей 407 приходит не как HTTP-ответ, а внутри ProxyError с сообщением «Tunnel connection failed: 407». Не добавляйте 407 в список повторов: повтор с неверными учётными данными результат не изменит. Больше примеров для разных языков — на страницах интеграция с Python и интеграция с Node.js.

Пошаговый порядок диагностики

1. Запишите свой IP без прокси с помощью инструмента My IP.
2. Убедитесь через инструмент проверки портов, что порт шлюза доступен. Если нет — проблема в локальной сети.
3. Запросите свой IP через прокси командой curl -v -x ... https://api.ipify.org. Если вернулся выходной IP прокси, аутентификация и туннель работают.
4. Повторите ту же команду с целевым URL. Если ошибка в ответе на CONNECT, смотрите на сторону прокси; если после туннеля — на сторону цели.
5. Дополнительно проверьте, что прокси в целом работает, с помощью proxy checker.
6. Для 429 и 403 пересмотрите параллельность, заголовки и тип IP. Для 502/504 протестируйте без прокси и разделите таймаут чтения.
7. Если проблема сохраняется, напишите в поддержку, указав целевой URL, код ошибки, время (с часовым поясом) и название пакета. Вывод curl -v с удалённым паролем ускорит диагностику.

Большинство ошибок прокси укладывается в три фразы: 407 — это учётные данные, 403 и 429 — решение цели, 5xx и таймауты — путь между прокси и целью. Связав ошибку с правильным уровнем, вы сделаете верный выбор между сменой IP, исправлением пароля и ожиданием.