Як налаштувати облікові дані проксі в Scrapy

1. Коли облікові дані проксі важливі під час краулу в Scrapy

У проєктах Scrapy ця проблема з’являється швидко: проксі працює, а потім цільовий сайт починає запитувати автентифікацію. Це типово для сервісів із ротацією, приватних пулів датацентрів і фіксованих корпоративних проксі. Якщо ви з’ясовуєте, як налаштувати облікові дані проксі в Scrapy, головне правило просте: це має бути в коді павука або middleware, а не в системних налаштуваннях мережі.

Проксі з ім’ям користувача та паролем змінює обробку запиту саме в момент, коли Scrapy створює запит. Налаштування в терміналі не може вирішити, якому павуку дістанеться який проксі або яке повторення спроби має перейти на другий набір облікових даних. Scrapy сам виконує HTTP-роботу, тож рішення щодо проксі має бути поруч із об’єктом запиту. Так поведінка прив’язується до краулу, а не до машини.

Уявіть краул із 3 цільовими ресурсами. Один домен дозволяє спільний проксі, другий хоче окремий логін, а один endpoint блокує перший проксі після 20 запитів. Якщо проксі налаштувати на рівні ОС, усі 3 запити виглядатимуть однаково. Якщо зробити це в Scrapy, кожен запит може мати власні дані проксі. Ця різниця стає важливою вже після першої невдалої відповіді.

Scrapy також робить рішення щодо проксі видимим у коді. Ви можете подивитися на павука, downloader middleware або callback запиту й точно побачити, де саме призначається проксі. Це складніше, коли проксі живе в shell-профілі на ноутбуці розробника. Одне місце. Одне рішення. Саме тому фраза Scrapy proxy credentials тут означає не просто технічну деталь, а спосіб тримати автентифікацію під контролем у межах проєкту.

2. Виберіть, де зберігатимуться облікові дані у вашому проєкті Scrapy

У проєкті Scrapy є 4 практичні місця для зберігання облікових даних проксі: settings.py, налаштування для конкретного павука, змінні середовища або власна конфігурація middleware. Кожен варіант має вузький сценарій використання. Глобальні облікові дані для одного краулу можуть жити в settings.py; павук, який працює з одним вендором, може мати власне налаштування; змінні середовища підходять для деплойменту; конфігурація middleware зручна, коли кілька павуків ділять один і той самий формат входу.

Жорстке вбудовування облікових даних у вихідний код — найгірший варіант, навіть для приватного репозиторію. Коміт копіюють, дзеркалять, кешують і переглядають більше людей, ніж ви очікуєте. Одного випадкового пушу досить. Зберігайте в коді лише назву налаштування, а секрет підставляйте під час виконання. Це робить проєкт Scrapy переносимим і позбавляє подальшого прибирання.

Якщо ваша команда вже використовує конфігураційні файли, не тримайте ім’я користувача та пароль проксі всередині класу павука. Покладіть значення в змінні під час деплойменту, а потім читайте їх через os.environ або завантажувач налаштувань. Для швидкого локального тесту тимчасове значення в settings.py може підійти, але ставтеся до нього як до одноразового. Воно не має пережити тиждень. Саме так легше підтримувати облікові дані проксі Scrapy без зайвого ризику.

Для ширшого вступу до пов’язаних термінів, глосарій VPN і проксі допоможе, коли в одному завданні змішані мова проксі, VPN і автентифікації. Невелика різниця, велика користь. Облікові дані проксі — це не те саме, що логін у VPN.

3. Додайте проксі з обліковими даними через метадані запиту

Найпряміший спосіб — прикріпити автентифікований проксі до одного запиту за раз. Scrapy підтримує метадані запиту, і ключ проксі там розміщується цілком природно. Це дає контроль на рівні окремого запиту, що корисно, коли одному краулу потрібні кілька проксі-ідентичностей або коли один павук працює зі сторінками з різними правилами доступу.

Типовий запит може передавати проксі так:

yield scrapy.Request(
    url,
    callback=self.parse_page,
    meta={
        "proxy": "http://user:[email protected]:8000"
    }
)

Цей приклад навмисно простий. Він показує структуру, а не повний павук. Запит несе проксі в meta, а Scrapy направляє його через автентифікований проксі. Якщо провайдер проксі вимагає іншу схему, змініть префікс відповідно до сервісу. Один запит може використовувати один проксі; наступний — інший. Якщо ви шукаєте, як налаштувати проксі з логіном і паролем у Scrapy, цей спосіб часто найшвидший для точкових запитів.

Тут є корисний побічний ефект. Ви можете тримати endpoint-и з авторизацією на одному проксі, а публічні сторінки — на іншому. Це зменшує шум у логах і робить повторні спроби зрозумілішими. Якщо один запит падає, ви знаєте, який саме проксі був задіяний, бо він прикріплений до об’єкта запиту, а не захований у глобальному шарі.

Практична деталь: не розкидайте рядки проксі по десятках callback-ів. Винесіть призначення проксі в один допоміжний метод, а потім викликайте його там, де павуку це потрібно. Навіть невеликий павук стає простішим для перевірки, коли логіка проксі зосереджена в одному місці.

4. Передавайте облікові дані проксі через downloader middleware

Для великого проєкту Scrapy downloader middleware часто є чистішим варіантом. Middleware може призначати request.meta["proxy"] для всіх відповідних запитів, а також робити те саме для заголовка входу чи іншої автентифікації, якщо це потрібно вашому проксі-сервісу. Так код павука лишається зосередженим на цільових сторінках, а не на передачі облікових даних.

Це добре працює, коли правило просте: всі запити від павука A використовують один проксі, або всі запити до одного домену використовують один автентифікований проксі. Middleware може перевірити URL, назву павука чи власний прапорець запиту, а потім встановити проксі ще до того, як запит потрапить до downloader. Жодного ручного дублювання. Жодного copy-paste в callback-ах.

Ось загальна схема логіки:

class ProxyAuthMiddleware:
    def process_request(self, request, spider):
        if getattr(spider, "use_proxy", False):
            request.meta["proxy"] = spider.proxy_url

Цей фрагмент мінімальний, і так і має бути. У реальному проєкті можна додати вибір облікових даних, перевірки доменів або перевизначення для окремих павуків. Важлива саме точка розміщення. Middleware обробляє запит до завантаження, а це саме те місце, де й має призначатися проксі, якщо правило застосовується широко.

Ще одна дрібниця: якщо проксі-сервіс очікує окремий заголовок автентифікації, а не облікові дані в URL проксі, middleware все одно є правильним місцем. Ви можете один раз зібрати заголовок і потім перевикористовувати його в усіх запитах. Це захищає кожен павук від повторного винаходу того самого коду.

Для пов’язаних рішень із налаштування, посібник із найкращих практик автентифікації проксі вартий уваги, якщо вашій команді потрібна політика щодо того, де має жити логіка auth. Це найбільше важливо, коли один і той самий обліковий запис проксі спільно використовує більше ніж один павук.

5. Обробляйте проксі, яким потрібне форматування імені користувача та пароля

Автентифіковані URL проксі зазвичай мають просту структуру: схема, ім’я користувача, пароль, хост і порт. У багатьох налаштуваннях Scrapy облікові дані можна безпосередньо вбудувати в URL проксі, наприклад http://user:pass@host:port. Точний формат залежить від типу проксі та провайдера, тому перевірте документацію сервісу перед тим, як запускати код у продакшн.

Є 2 поширені підходи. У першому в URL проксі вже містяться ім’я користувача та пароль, і Scrapy читає весь рядок із request.meta["proxy"]. У другому хост проксі зберігається окремо, а дані для входу керуються в іншому місці, часто через middleware або правило конкретного провайдера. Перший варіант простіше тестувати. Другий простіше централізувати.

Якщо ви вбудовуєте облікові дані в URL, ставтеся до цього рядка як до секрету. Він з’явиться в логах, якщо необережно виводити об’єкти запиту. Він також може потрапити в інструменти налагодження або stack trace. Одного витоку URL достатньо, щоб розкрити обліковий запис. Це помилка безпеки, а не просто неохайний рядок у логах.

Деякі провайдери проксі використовують логіни з додатковими сегментами, наприклад назвами зон, session ID або тегами країни. Це може змінити формат URL настільки, що приклад, скопійований бездумно, перестане працювати. Один раз прочитайте формат у провайдера, а потім рівно один раз закодуйте його в коді. Проксі має відповідати провайдеру, а не навпаки.

6. Перевірте, що Scrapy справді використовує автентифікований проксі

Перевірки самого запиту недостатньо; вам потрібен доказ, що Scrapy надсилає трафік через автентифікований проксі. Перше місце, куди варто подивитися, — лог виводу. Якщо ваш middleware або павук друкує призначений проксі, ви маєте побачити очікуваний хост і порт на етапі запиту. Якщо в логах немає проксі взагалі, запит так і не підхопив налаштування.

Тут важливий порядок middleware. Пізніший middleware може перезаписати раніше призначений проксі, і це може статися непомітно. Якщо один middleware встановлює проксі, а інший змінює запит, перевірте порядок у settings.py. Один невірно розміщений клас може перетворити коректний автентифікований проксі на звичайне вихідне з’єднання. На малих краулах таку помилку легко не помітити.

Поведінка відповіді теж багато чого каже. Проксі з неправильними обліковими даними часто повертає статус 407, тоді як дійсний проксі може повернути сторінку цілі, сторінку блокування або іншу відповідь із echo IP. Якщо ви тестуєте сервіс, який показує вашу IP-адресу, порівняйте результат із очікуваною локацією проксі. Ви також можете додатково перевірити як переконатися, що ваша IP-адреса відповідає очікуванням, перш ніж довіряти краулу.

Одна практична перевірка: запустіть 5 запитів із підвищеним рівнем логування, а потім порівняйте хост проксі в кожному рядку. Якщо всі 5 запитів ідуть через один і той самий автентифікований проксі, ваш middleware або метадані запиту працюють. Якщо один запит ігнорує проксі, шукайте callback, який створює власний запит без спільного допоміжного методу. Це трапляється частіше, ніж команди готові визнати.

7. Ротуйте або перемикайте облікові дані проксі за доменом чи типом запиту

Деяким завданням Scrapy потрібно більше одного набору облікових даних. Роздрібний сайт може дозволяти один обліковий запис проксі для сторінок товарів і інший для checkout-сторінок. Пошуковий краул може потребувати різних проксі для різних доменів, або повторна спроба може вимагати свіжого session ID. У такому разі рішення щодо проксі має ґрунтуватися на простому правилі: за доменом, за назвою павука або за типом запиту.

Найчистіше місце для такої логіки зазвичай middleware, бо він може перевірити кожен вихідний запит перед завантаженням. Ви можете перемикати облікові дані, коли цільовий домен збігається зі списком, або коли запит містить власний прапорець, наприклад meta["proxy_group"]. Це зберігає читабельність павука і позбавляє жорстко вшитих гілок у кожному callback.

Повторні спроби потребують особливої обробки. Якщо один проксі блокується після 2 спроб, повтор може взяти інший набір облікових даних перед повторним надсиланням запиту. Це не те саме, що випадкова ротація; це керований fallback. Для ширшого підходу до цього патерну дивіться посібник із ротації проксі для вебскрапінгу. Він добре поєднується з логікою повторів Scrapy.

Тут є межа. Якщо ротувати облікові дані надто агресивно, налагодження стає шумним. Запит, який змінює ідентичність на кожному повторі, важче відстежити, особливо коли сайт повертає нестабільні блокування. Почніть із 2 або 3 груп облікових даних, а потім додавайте більше лише тоді, коли краул дає чітку причину. Така стриманість окупається.

8. Не зберігайте облікові дані проксі в системі контролю версій

Робота із секретами — це те, що люди виправляють останнім, і те, що потім найсильніше б’є. Тримайте облікові дані проксі поза системою контролю версій: читайте їх із змінних середовища під час виконання, а потім підставляйте в налаштування Scrapy або конфігурацію middleware під час деплойменту. Це працює і на ноутбуці, і в контейнері, і в CI-завданні без змін у коді павука.

Пайплайн деплойменту може задати PROXY_URL, PROXY_USER або PROXY_PASS перед запуском Scrapy. Потім павук читає ці значення і формує рядок автентифікованого проксі. Це зберігає кодову базу чистою і робить ротацію облікових даних завданням конфігурації, а не зміною коду. Зміна одного пароля не має вимагати нового коміту.

Будьте обережні з логами, тестовими фікстурами та прикладними файлами. Фейковий рядок проксі в тесті все одно може виглядати достатньо правдоподібно, щоб його скопіювали в тікет. Файл .env має залишатися поза репозиторієм. Деплоймент-секрет має залишатися в системі деплойменту. Ці два кордони прості, але їх легко розмити, коли дедлайн уже близько.

Якщо у вашому проєкті використовується кілька провайдерів проксі, задокументуйте, які назви налаштувань належать якому провайдеру. Колега, який бачить PROXY_URL і SESSION_ID, має розуміти, чи ці значення обов’язкові, чи опційні. Для ширшого погляду на інструменти приватності поруч зі Scrapy, сторінка посібників із VPN, proxy та приватності допоможе з’єднати всі частини без змішування кодових шляхів. Scrapy все одно потребує власної логіки проксі.

І остання практична порада: протестуйте підставляння секретів на тестовому обліковому записі проксі, перш ніж запускати production-краул. Якщо тестовий обліковий запис не працює, ви виявите помилку в безпечному середовищі. Якщо працює, ви знаєте, що шлях для облікових даних проксі налаштований правильно. Тоді реальний краул може стартувати з меншим числом сюрпризів.