403, 429 и timeout: диагностика доступа к сайту

403, 429 и timeout нельзя складывать в одну метрику «прокси не работает». Первые два ответа пришли от HTTP-сервера, а timeout означает, что полный ответ не был получен за заданное время.

Сначала определите слой ошибки

Один запрос проходит несколько слоёв: DNS → соединение с прокси → TLS до источника → HTTP-ответ → проверка содержимого. Логируйте каждый слой отдельно.

Сигнал	Что уже известно	Что проверить
Ошибка DNS	Имя не разрешилось	DNS клиента и прокси, опечатку в hostname
Connection refused	Узел отверг соединение	host, port, доступность прокси
TLS error	Не установлен защищённый канал	схему прокси, сертификат, SNI, время системы
timeout	Операция не завершилась вовремя	connect/read timeout, маршрут, нагрузку источника
403	HTTP-сервер отказал	тело ответа, правила доступа, User-Agent, URL
429	Превышен лимит	Retry-After, частоту, параллельность, ключ API
200 с CAPTCHA	HTTP успешен, данные не получены	тип содержимого и маркеры страницы проверки

Проверка «пришёл ли 200» недостаточна. Валидатор ответа должен подтвердить ожидаемый content-type и обязательные поля.

Минимальный диагностический запрос

Используйте безопасную публичную цель, например https://httpbin.org/status/200, и не выводите credentials в лог.

import os
import time
import requests

proxy_url = os.environ["PROXY_URL"]
proxies = {"http": proxy_url, "https": proxy_url}

started = time.perf_counter()
try:
    response = requests.get(
        "https://httpbin.org/status/200",
        proxies=proxies,
        timeout=(10, 20),
        headers={"User-Agent": "InfraProxy-Diagnostic/1.0"},
    )
    elapsed_ms = round((time.perf_counter() - started) * 1000)
    print({
        "status": response.status_code,
        "elapsed_ms": elapsed_ms,
        "content_type": response.headers.get("content-type"),
        "retry_after": response.headers.get("retry-after"),
    })
except requests.ConnectTimeout:
    print({"layer": "connect", "error": "timeout"})
except requests.ReadTimeout:
    print({"layer": "read", "error": "timeout"})
except requests.ProxyError as error:
    print({"layer": "proxy", "error": type(error).__name__})
except requests.SSLError as error:
    print({"layer": "tls", "error": type(error).__name__})

Раздельные connect/read timeouts показывают, на каком этапе закончился бюджет времени. Для production добавьте request ID, домен, тип прокси и номер попытки, но не сохраняйте пароль.

Как реагировать на 429 и 503

429 Too Many Requests — команда замедлиться. Заголовок Retry-After может содержать секунды или HTTP-дату; оба формата описаны в MDN.

Порядок реакции:

1. Остановите новые задачи для домена.
2. Учтите Retry-After, если он есть.
3. Уменьшите параллельность и частоту.
4. Повторите ограниченное число раз с jitter.
5. После исчерпания бюджета перенесите задачу в очередь ошибок.

Не меняйте IP в бесконечном цикле ради сохранения прежней нагрузки. Это не устраняет причину лимита и увеличивает нагрузку на источник.

Как проверить, виноват ли прокси

Сравните четыре режима с одинаковым URL и одинаковым профилем запросов:

1. Прямое соединение.
2. Один фиксированный DC-прокси.
3. Другой DC-прокси из того же пула.
4. ISP-прокси, если его использование допустимо для задачи.

Если один узел не устанавливает соединение с httpbin.org, а остальные работают, проблема вероятнее на уровне узла или маршрута. Если все режимы получают одинаковый 429, причина вероятнее в лимите источника или ключа API.

18 августа 2026 года мы провели отдельный контроль на открытом HTTP endpoint: один DC-прокси корректно доставил ожидаемые 200, 403, 429 и 503. Время четырёх запросов составило 818–860 мс. Это подтверждает узкий вывод: полученный HTTP-статус нужно отделять от сетевой ошибки.

Полная методика, таблица и тест трёх попыток с backoff опубликованы в отдельном исследовании.

Этичность и ограничения

Сначала проверьте официальный API, robots.txt и условия использования. Соблюдайте Disallow и Crawl-delay, кэшируйте ответы и ограничивайте параллельность. Не обходите логин, paywall и запрет доступа. Не собирайте персональные данные без законного основания.

Прокси помогают управлять сетью и диагностикой. Они не дают разрешения на автоматический доступ и не превращают 403 или 429 в сетевую неисправность.

Для проверки конфигурации на разрешённом источнике используйте страницу прокси InfraProxy.

Ключевые выводы

• 403 и 429 — HTTP-ответы; timeout — незавершённая операция.
• Проверяйте не только статус, но и содержимое ответа.
• При 429 учитывайте Retry-After и снижайте нагрузку.
• Сравнивайте режимы при одинаковых URL, таймаутах и параллельности.

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