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

Временно раскройте начальный статус перенаправления и заголовок Location проксированного GET через метаданные запроса, отделив обработку перенаправлений от фильтрации ошибок HTTP.

Проксированный GET может дойти до сервера и затем следовать перенаправлениям, пока итоговая ошибка не скроет первый ответ. Раскройте этот первый ответ для диагностики:

request = scrapy.Request(
    'https://service.example/page',
    callback=inspect_redirect,
    meta={
        'proxy': 'http://proxy.example:8080',
        'dont_redirect': True,
        'handle_httpstatus_list': [301, 302, 303, 307, 308],
    },
)

Запланируйте этот запрос через существующий поток запуска или callback паука. Для разрешённой проверки публичной страницы список HTTP-прокси предлагает кандидатов для прокси-URL запроса. inspect_redirect должен записывать статус ответа и заголовок Location, а не снова слепо следовать ему.

dont_redirect останавливает автоматическое перенаправление для этого запроса. handle_httpstatus_list позволяет указанным статусам дойти до callback, вместо того чтобы быть отклонёнными фильтрацией ошибок HTTP. Эти настройки относятся к разным обязанностям middleware.

Проверьте, что выбирает перенаправление: нужный канонический URL, другая схема или имя хоста, страница входа или повторяющийся цикл. Полученный после успешной передачи 302 — это другое наблюдение, чем неудача при открытии прокси-соединения.

Когда обычная обработка перенаправлений восстановлена, Scrapy раскрывает redirect_urls и redirect_reasons в метаданных запроса ответа. Они могут сохранить путь к итоговому результату, не оставляя перенаправления отключёнными на весь обход.

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

Похожие статьи