Прокси для веб-скрапинга: подключения, ошибки и повторные попытки

Когда запрос проходит через прокси, ответ может прийти от прокси или от сайта, и один лишь код статуса не всегда показывает, от кого именно. Код 407 с Proxy-Authenticate это проверка (challenge) со стороны прокси, а 401 с WWW-Authenticate это проверка (challenge) со стороны исходного сервера. Код 429 означает слишком много запросов, и для него, как и для 403, нужно уточнить, какой узел ответил. В этом руководстве объясняется, что стандарты говорят об этих сигналах и как реагировать на них взвешенно на сайтах, к которым у вас есть разрешённый доступ.

Сначала авторизация

Можно ли парсить конкретный сайт, зависит от его условий, ваших договоров и применимого законодательства. Документы протоколов не дают ответа на этот вопрос. Прокси — это сетевой посредник: он передаёт ваш трафик, но не даёт разрешений на сайте или платформе. Техническая доступность — тоже не разрешение.

Всё ниже исходит из того, что у вас уже есть законные основания для доступа. Здесь нет рекомендаций по обходу средств контроля доступа.

Сначала проверьте robots.txt

Протокол исключений для роботов (Robots Exclusion Protocol) (RFC 9309) позволяет владельцам сервисов указывать, как поисковые роботы могут получать доступ к их контенту, а роботов просят соблюдать эти правила.

Для работы с подключением важны две детали:

• Если robots.txt недоступен из-за ошибок сервера или сети, краулер должен считать, что доступ полностью запрещён. Поэтому сбой прокси при получении robots.txt — повод остановиться и исправить соединение, а не продолжать без правил.
• Протокол не является мерой безопасности. В RFC 9309 сказано, что доступом к путям следует управлять с помощью чего-то вроде HTTP-аутентификации. Поэтому разрешающий robots.txt — это не выданное разрешение, а запрещающий — не замок.

Crawl-delay не входит в RFC 9309, поэтому не считайте его стандартной директивой.

Как работают CONNECT-туннели

Для HTTPS-адресов клиент обычно просит прокси открыть туннель методом CONNECT, определённым в RFC 9110. Для диагностики важны следующие детали:

• Цель запроса — только host:port. Порта по умолчанию нет, поэтому клиент должен передать его явно.
• Любой ответ 2xx переключает соединение в режим туннеля. Неуспешный ответ означает, что туннель не был сформирован.
• CONNECT предназначен для запросов к прокси, а большинство исходных серверов его не реализуют.
• Прокси, поддерживающие CONNECT, должны ограничивать его ограниченным набором известных портов или настраиваемым списком безопасных адресов назначения. Отказ для необычного порта может быть обычным решением в рамках политики.
• Ответы на CONNECT не кэшируются.

Ответ на CONNECT, отличный от 2xx, говорит лишь о том, что туннель пока не создан. Причиной может быть аутентификация или политика прокси, собственная попытка прокси подключиться к целевому адресу либо другой прокси дальше по цепочке. Прежде чем делать вывод, прочитайте код статуса и сообщение, которое возвращает прокси, и не предполагайте, что дело в правилах целевого сайта.

Туннельный запрос с значениями-заполнителями выглядит так:

CONNECT TARGET_HOST:TARGET_PORT HTTP/1.1
Host: TARGET_HOST:TARGET_PORT
Proxy-Authorization: PROXY_CREDENTIALS

407, 401 и 403 — это разные проблемы

Эти три кода легко перепутать, но каждый указывает на своё место.

• 407 Proxy Authentication Required это запрос аутентификации от прокси. Он должен содержать Proxy-Authenticate заголовок. Клиент может ответить, отправив Proxy-Authorization, и он может повторить запрос с новыми или заменёнными учётными данными.
• 401 Unauthorized это запрос аутентификации от исходного сервера, отправляемый с WWW-Authenticate. Это отдельный механизм, который не совпадает с авторизацией на прокси.
• 403 Forbidden это то, что сервер должен отправить, получив корректные учётные данные, которых недостаточно для доступа. Одни лишь корректные учётные данные не гарантируют доступ к ресурсу.

Два заголовка challenge — надёжные маркеры того, какая сторона запрашивает аутентификацию. Одиночный код 403 такой информации не содержит. Определите, пришёл ли он в ответ на запрос CONNECT (ответил прокси), вернулся внутри пересланного запроса или содержит заголовки либо тело, указывающие на отправителя.

Proxy-Authorization применяется только к следующему входящему прокси, который запросил аутентификацию. В цепочке прокси первый, ожидающий учётные данные, использует их. Если вы маршрутизируете трафик через несколько узлов, проверьте, какой узел выдаёт 407.

Аутентификация на прокси также может использоваться для получения права на создание туннеля CONNECT, как в примере из RFC, где заголовок отправляется в самом запросе CONNECT.

429 и Retry-After

Статус 429 приходит от RFC 6585 и означает, что пользователь отправил слишком много запросов за определённый промежуток времени. Ответ должен содержать подробности о ситуации и может включать Retry-After заголовок, указывающий, сколько нужно подождать.

В RFC остаётся неопределённым ряд моментов:

• Как сервис идентифицирует пользователя и подсчитывает запросы, не указано. Лимиты могут применяться на уровне ресурса, всего сервера или набора серверов, а пользователь может определяться по учётным данным или файлу cookie.
• Серверы не обязаны использовать код 429. При высокой нагрузке они могут вместо этого разрывать соединения, поэтому сброс или тихое закрытие соединения тоже может быть признаком ограничения скорости.
• Ответ 429 не должен сохраняться в кэше.

Этот Retry-After значение — это либо HTTP-date, либо delay-seconds, неотрицательное целое число (RFC 9110). Ваш клиент должен уметь разбирать обе формы. Если в ответе с кодом 429 есть заголовок, подождите указанное время, прежде чем отправлять запрос снова.

Ответ 429 — это просьба снизить темп. Не воспринимайте его как препятствие, которое нужно обойти.

Тайм-ауты и повторные попытки

Протокол не задаёт значения таймаутов. Таймауты соединения, чтения и общий таймаут — это настройки вашего клиента или библиотеки, поэтому подбирайте их под свою нагрузку и тестируйте. HTTP определяет код состояния 408 (Request Timeout), но код состояния не определяет, как долго должен ждать ваш клиент.

Разумная инженерная практика — увеличивать паузы между повторными попытками и добавлять немного случайности (экспоненциальная задержка с добавлением случайной задержки, exponential backoff with jitter). Это общая практика, а не требование протокола, и это не способ избежать обнаружения или принудительных мер.

Несколько привычек, соответствующих ответственному поведению:

1. Honor Retry-After всякий раз, когда он есть в ответе.
2. Ограничьте число попыток для каждого URL и останавливайтесь, когда лимит достигнут.
3. Обратите внимание, произошёл ли сбой до создания туннеля (нет 2xx на CONNECT, 407) или в ответе, когда запросы уже проходят. 401 с WWW-Authenticate обозначает исходный сервер, а 407 с Proxy-Authenticate обозначает прокси. Ответ 403 или 429 может прийти от любого из них, поэтому уточните, какой узел ответил, так как для каждого нужно своё исправление.
4. Записывайте код статуса, какой узел дал ответ и затраченное время для каждой ошибки.
5. Перепроверьте свою авторизацию, если вы продолжаете получать отказы.

SOCKS5 вкратце

SOCKS5, определённый в RFC 1928, — это фреймворк, позволяющий клиент-серверным приложениям TCP и UDP использовать сервисы сетевого межсетевого экрана. Процесс состоит из трёх шагов: клиент согласовывает метод аутентификации, проходит аутентификацию, а затем отправляет запрос на ретрансляцию. Сервер либо устанавливает соединение, либо отклоняет его.

RFC определяет три метода: без аутентификации, GSSAPI и имя пользователя/пароль. Соответствующие стандарту реализации обязаны поддерживать GSSAPI и должны поддерживать имя пользователя/пароль. Команды запроса: CONNECT, BIND и UDP ASSOCIATE.

Аутентификация по логину и паролю указана в RFC 1929 как одно из субсогласований в рамках SOCKS5. Коды состояния HTTP относятся к HTTP, поэтому диагностика в стиле 407, описанная выше, не применима внутри рукопожатия SOCKS5. Там сбой проявляется как ошибка согласования или аутентификации либо как отклонённый запрос на ретрансляцию. Поддержка функции SOCKS5 клиентской библиотекой не говорит о том, что разрешает конкретный сервер, поэтому протестируйте нужный вам метод и команду.

Для дополнительной информации см. руководства SOCKS4 и SOCKS5: сравнение аутентификации, DNS и UDP и Что такое HTTPS-прокси и как работают SSL-прокси?.

Краткая справка: на что указывает каждый сигнал

Сигнал	Откуда это может происходить	Что проверить в первую очередь
CONNECT ответил статусом не из диапазона 2xx	Прокси или его попытка подключиться к целевому ресурсу либо к вышестоящему прокси	Туннель не был создан. Прочитайте статус и любое сообщение прокси и проверьте host:port цель и любые ограничения портов.
407 с Proxy-Authenticate	Прокси	Учётные данные отправляются в Proxy-Authorization, и какой узел в цепочке запрашивает аутентификацию.
401 с WWW-Authenticate	Исходный сервер	Собственная аутентификация сайта, отдельная от аутентификации прокси.
403	Origin или прокси; уточните, что именно	Действительных учётных данных может быть недостаточно для доступа к этому ресурсу, либо может действовать политика прокси. Проверьте права доступа и определите отправителя.
429, при необходимости с Retry-After	Origin или прокси; уточните, что именно	Снизьте скорость и подождите указанное время, если оно указано.
Разрыв или сброс соединения	Любая из сторон	Возможен сброс нагрузки. Проверьте логи, уменьшите объём и повторите попытку осторожно.
robots.txt недоступен	Сеть или сервер	Считайте, что всё запрещено, пока файл не удастся получить.

Для практической проверки подключения, аутентификации и протокола подойдёт руководство Как проверить прокси: воспроизводимые тесты подключения, авторизации, IP, DNS и протоколов посвящён тестированию. Более общий обзор по устранению неполадок смотрите в Почему не работает прокси: ошибки и способы исправления.

FAQ

Означает ли ошибка 407, что сайт меня отклонил?

Нет. 407 выдаёт прокси, и он сопровождается Proxy-Authenticate. Ответ 401 относится к авторизации на сервере назначения и использует WWW-Authenticate. Это разные механизмы: устраняйте ошибку на том узле, который отправил ответ.

Нужно ли всегда повторять запрос после ответа 429?

Только после ожидания и только в пределах заданных вами лимитов. Если ответ содержит Retry-After, соблюдайте его. Значение — это HTTP-date или целое число секунд. Если заголовка нет, замедлитесь и ограничьте число попыток.

Достаточно ли robots.txt, чтобы знать, разрешён ли скрейпинг?

Нет. Он сообщает краулерам, как владелец просит их себя вести, а RFC 9309 говорит, что это не мера безопасности. Разрешение зависит от условий сайта, договоров и закона, поэтому проверяйте это отдельно.

Следующий шаг

Убедившись, что ваше использование разрешено, проверьте, что клиент считывает каждый ответ на нужном уровне: прокси, туннель или источник. Открыть Proxyca в Telegram