Ошибка прокси 503: на чьей стороне проблема

Страница не грузится, вместо неё — «503 Service Unavailable». Первая мысль — сломался прокси. Иногда так и есть, но чаще ошибка прокси 503 приходит от самого сайта, а прокси просто передаёт её дальше. Ниже — как за пару минут понять, на чьей стороне проблема, и что делать в каждом случае.

Что означает ошибка 503 и кто её отдаёт

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

Целевой сайт. Упал бэкенд, идут работы, кончились воркеры под нагрузкой. Ошибку видят все, а не только вы.
Антибот-защита сайта. Некоторые площадки отвечают 503 вместо 403, когда считают трафик автоматическим. Классический пример — Amazon при парсинге: страница-заглушка с предложением обсудить автоматический доступ к данным и код 503.
Сам прокси-сервер. Он не смог соединиться с сайтом: таймаут, ошибка DNS, у сайта нет адреса нужного протокола, узел перегружен.

Как понять, на чьей стороне ошибка прокси 503

Самый быстрый способ — посмотреть подробный вывод curl. Для HTTPS-сайта прокси сначала получает команду CONNECT, и уже потом внутри туннеля идёт запрос к сайту. Это и есть граница ответственности.

curl -v -x http://user:pass@[2a03:4000::1]:8080 https://example.com/ -o /dev/null

Смотрите на строки, начинающиеся с <:

Если сразу после CONNECT example.com:443 пришло HTTP/1.1 503 — туннель не построен, ошибку отдал прокси. До сайта запрос не дошёл.
Если на CONNECT пришло 200 Connection established, затем TLS-рукопожатие, и только потом HTTP/2 503 — прокси отработал нормально, отказал сайт.

Дополнительные подсказки в заголовках ответа:

Признак	О чём говорит
`server: cloudflare`, `cf-ray`	Ответ от CDN сайта: перегрузка источника или проверка трафика
`Retry-After: 120`	Сайт сам говорит, через сколько секунд повторить
`Server: squid`, `X-Squid-Error`, `Via`	Ошибку сгенерировал прокси или промежуточный шлюз
Капча или текст про роботов в теле	Антибот, а не перегрузка

Второй контрольный тест — открыть тот же адрес без прокси и через другой прокси. Если 503 везде, проблема у сайта. Если только через один адрес — дело в нём или в его подсети. Как быстро прогнать такую проверку, разобрано в статье про проверку прокси на работоспособность.

Если 503 отдаёт сайт

Обычная перегрузка лечится ожиданием. Пара практических правил:

Уважайте Retry-After. Повтор раньше срока часто продлевает отказ.
Делайте повторы с растущей паузой: 5, 15, 45 секунд. Мгновенные ретраи из скрипта добивают и без того лежащий сервер, а вам дают серию тех же 503.
Проверьте статус-страницу сервиса или его соцсети — работы обычно анонсируют.

Если 503 появляется только у вас и только под нагрузкой, это уже ограничение вашего трафика, просто оформленное другим кодом. Логика здесь та же, что с ошибкой 429: снизить частоту запросов, разнести поток по нескольким адресам, добавить паузы между запросами с одного IP. Сколько адресов брать под объём и как их чередовать, разобрано в разделе о прокси для парсинга.

Если 503 — это антибот

Когда сайт отвечает 503 со страницей-заглушкой, ждать бесполезно — он не перегружен, он не хочет обслуживать конкретно вас. Что помогает:

Сменить IP и посмотреть, повторяется ли блок. Если чистый адрес сразу получает страницу, а старый — нет, был помечен адрес.
Привести запросы к виду браузерных: реальный User-Agent, Accept-Language, куки сессии, без сотни запросов в секунду.
Учитывать тип адресов. Серверные IP из дата-центров на крупных маркетплейсах проверяют строже, чем домашние. Это не значит, что они не работают, но частоту и поведение придётся подбирать аккуратнее.

Если 503 отдаёт прокси

Тест с CONNECT показал, что туннель не построился. Проверьте по порядку:

Открывается ли другой сайт через тот же прокси. Если всё лежит — проблема с узлом или с вашей сетью до него.
Не истёк ли срок прокси. После окончания аренды одни провайдеры отдают 407, другие — 503 или обрыв соединения.
Есть ли у сайта адрес нужного протокола. Если прокси умеет ходить только по IPv6, а у сайта есть лишь IPv4, соединиться ему просто некуда — в ответ придёт 502 или 503.
Не упирается ли всё в DNS. Попробуйте указать прокси как SOCKS5 с удалённым резолвом (socks5h:// в curl) — тогда имя сайта разрешает прокси, а не ваш компьютер.

Если перечисленное в порядке, а ошибка держится дольше 10–15 минут, пишите провайдеру с выводом curl -v: по нему сразу видно, на каком шаге оборвалось соединение. Полный список причин, по которым прокси перестаёт работать, собран в отдельном разборе неисправностей.

Коротко: что делать при 503

Сначала curl -v и вопрос «на каком шаге пришёл код». Ошибка до туннеля — разбираетесь с прокси. Ошибка после туннеля — с сайтом: при перегрузке ждёте и повторяете с паузами, при заглушке антибота меняете адрес и снижаете темп. Тест без прокси и через второй адрес закрывает оставшиеся сомнения.

У IPv6-прокси ModJus последний пункт из списка про протоколы снят: адрес выдаётся по IPv6, но до сайта запрос идёт по тому протоколу, который сайт поддерживает, поэтому IPv4-сайты тоже открываются. Если 503 возникает на нашем прокси, а сайт без прокси открывается нормально, напишите в поддержку через бот с выводом curl — так разберёмся быстрее.