Мобільні проксі для Scrapy: middleware, ретраї та ліміти без банів

Чому Scrapy «спотикається» без проксі

Scrapy — один із найпопулярніших Python-фреймворків для краулінгу та парсингу. Він швидкий, асинхронний, гнучкий у налаштуваннях і добре масштабується. Але саме ці переваги часто стають причиною проблем: сайт бачить багато однотипних запитів з однієї IP-адреси, з «підозрілими» заголовками, у прогнозованому ритмі, і швидко вмикає захист — від обмеження швидкості до повного блокування.

Проксі не є «чарівною кнопкою», але в реальних задачах (моніторинг цін, наявності, асортименту, контенту по регіонах) це базовий інструмент. Особливо якщо потрібна мобільна IP-адреса: вона ближча до поведінки звичайного користувача, частіше проходить антибот-фільтри та дозволяє отримувати регіональну видачу так, як її бачать люди з мобільних мереж.

Що таке «індивідуальні мобільні проксі» і коли вони потрібні

Під індивідуальними мобільними проксі зазвичай мають на увазі проксі, які:

• видаються «в одні руки» (ви не ділите IP з іншими клієнтами провайдера);
• працюють через мобільні оператори (4G/LTE/5G), тобто мають мобільну репутацію;
• можуть змінювати IP (ротація) або тримати IP певний час (sticky-сесія);
• часто мають вибір локації/оператора, що важливо для регіональної видачі.

Такі проксі доцільні, якщо у вас є:

• гео-вариативність (ціни/наявність/акції залежать від міста, складу, «зони доставки»);
• антибот (403/429, капчі, редіректи на «blocked» сторінки);
• потреба у стабільності (нічні моніторинги, регулярні перевірки кожні 5–30 хв);
• обмеження по швидкості (rate limit), де важливо керувати ритмом та ретраями, а не «лупити» запити.

Де саме в Scrapy «живе» проксі: downloader middleware

У Scrapy більшість технік керування запитами реалізується через downloader middleware — ланцюжок хуків, які можуть змінювати Request/Response до того, як запит піде в мережу або відповідь потрапить у spider. Проксі підключаються саме тут: ви встановлюєте для кожного Request значення request.meta["proxy"] (наприклад, http://user:pass@host:port) — і Scrapy відправляє трафік через цей проксі.

Плюс middleware у тому, що ви робите це централізовано: можна швидко додати правила «для цього домену — тільки sticky», «для цього регіону — інший пул», «для API — інший ліміт», не переписуючи сам spider.

Підхід №1: просте підключення одного проксі (для старту)

Якщо у вас один виділений мобільний проксі (або один endpoint з ротацією IP на стороні провайдера), найпростіше:

• передавати проксі через meta у кожному запиті, або
• зробити невеликий middleware, який автоматично проставляє meta["proxy"] для всіх запитів.

Другий варіант практичніший: ви контролюєте застосування проксі централізовано, можете вмикати/вимикати для окремих доменів, маршрутів або типів запитів (HTML vs API).

Підхід №2: ротація проксі + sticky-сесії під конкретні задачі

Для регулярного краулінгу краще мати пул або хоча б механіку ротації. У мобільних проксі часто є два режими:

• Rotating — IP змінюється часто (інколи на кожен запит або раз на N хвилин).
• Sticky — IP зберігається певний час (наприклад, 5–30 хв), що корисно для сесій, кошика, «персоналізації» та стабільних cookies.

У Scrapy це зазвичай роблять так: для кожного запиту визначають «ключ сесії» (наприклад, регіон+домен, або регіон+категорія), і для цього ключа підбирають проксі/порт/параметр, який тримає IP певний час.

scrapy proxy middleware: що має робити ваш middleware

Які задачі реально варто закласти в scrapy proxy middleware:

• вибір проксі (пул/ротація/стіккі) на основі домену, регіону, типу запиту;
• підстановка авторизації (user/pass) або токена;
• детект банів/лімітів (403/429/503, «blocked» сторінка, капча) і позначення проксі як «поганий»;
• перемикання проксі перед ретраєм (щоб не повторювати помилку з тим самим виходом);
• пріоритизація: наприклад, «критичні SKU» перевіряти частіше й обережніше.

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

Ретраї в Scrapy: як не перетворити «помилку» на DDoS

Scrapy має вбудований RetryMiddleware, який повторює запити при тимчасових збоях (таймаути, 5xx, деякі статус-коди). Але «за замовчуванням» ретраї можуть:

• погіршити бан (ви ще швидше доб’єте ліміт);
• створити чергу повторів і «застрягти» на проблемних сторінках;
• повторювати запит через той самий проксі, якщо ви не змінюєте маршрут.

Практичний підхід: при ретраї міняйте проксі і/або збільшуйте паузу. Якщо отримали 429 — це не «випадкова» помилка, це сигнал, що сайт просить уповільнитись. Для 403 (особливо з «антибот» шаблоном) — часто допомагає зміна мобільної IP та більш «людський» ритм.

Throttling Scrapy: AutoThrottle, DOWNLOAD_DELAY, CONCURRENT_REQUESTS

Щоб робити парсинг без банів, одного проксі недостатньо. Потрібно керувати швидкістю. У Scrapy для цього є кілька важелів:

• DOWNLOAD_DELAY — мінімальна пауза між запитами до одного сайту;
• CONCURRENT_REQUESTS та CONCURRENT_REQUESTS_PER_DOMAIN — паралельність;
• AutoThrottle — автоматичне підлаштування затримок під реакцію сайту (і вашу інфраструктуру);
• AUTOTHROTTLE_DEBUG — корисно для діагностики, щоб бачити, як Scrapy «крутить ручки».

Правило для мобільних проксі: краще повільніше, але стабільно. Якщо задача — довготривалий моніторинг, то вам важлива не пікова швидкість, а передбачувана частота й мінімум відмов.

Ліміти, капчі, редіректи: як «читати» відповідь сайту

У промисловому краулінгу варто розрізняти типи проблем:

• 429 Too Many Requests — класичний rate limit: потрібен backoff і/або менша паралельність.
• 403 Forbidden — може бути IP-блок, антибот, невірні заголовки, «заборонений» маршрут.
• 503/520/521 — тимчасові збої, інколи від CDN/захисту.
• 200, але «не те» — сторінка капчі або заглушка «доступ обмежено» під виглядом звичайної відповіді.

Тому middleware має вміти не лише дивитися на статус-код, а й перевіряти сигнатури у HTML (типові заголовки, ключові фрази, відсутність потрібних блоків). Це можна робити як у middleware (на рівні Response), так і в spider (валідація контенту).

Відбиток запиту: заголовки, cookies, послідовність дій

Навіть з мобільною IP можна швидко отримати блок, якщо «відбиток» запиту виглядає неприродно. У Scrapy варто стабілізувати базові речі:

• User-Agent з реального браузера (а не дефолтний), бажано з пулу 3–10 варіантів;
• Accept, Accept-Language і Accept-Encoding — у логіці, близькій до браузера;
• Cookies — інколи краще вимкнути, а інколи навпаки потрібна «сесія» (особливо в sticky-режимі);
• Послідовність: якщо сайт очікує, що користувач прийде з категорії на картку, інколи варто симулювати цей шлях хоча б для частини SKU.

Це не про «хитрощі», а про стабільність: коли ви повторювано робите запити в одному й тому ж форматі та ритмі, вам простіше діагностувати проблеми і налаштовувати ліміти.

Проксі для краулера: як організувати пул під домени та регіони

Для кейсу «ретейлери по регіонах» найзручніше мислити не «один проксі на все», а «маршрути»:

• Маршрут = регіон + домен (наприклад, Київ + retailerA, Львів + retailerA).
• Для кожного маршруту — своя sticky-сесія (щоб сайт бачив стабільного «користувача» в цьому регіоні).
• Окремий режим для «каталогу» (можна швидше) і для «картки товару» (обережніше).

Якщо ваш провайдер дає вибір локацій, ви можете закласти мапу: місто → endpoint або місто → параметр у логіні/URL (залежить від реалізації провайдера).

Кейс: моніторинг цін/наявності у ретейлерів по регіонах

Задача: регулярно перевіряти ціну і статус наявності для списку SKU у кількох великих онлайн-ретейлерів, причому ціна може відрізнятися залежно від регіону (склад, доставка, локальні акції).

Архітектура рішення

• Джерело SKU: база/таблиця з товаром, URL та пріоритетом (що важливіше — перевіряємо частіше).
• Scrapy spider: генерує запити по SKU, додає в meta регіон і тип запиту.
• Proxy middleware: вибирає мобільний проксі під регіон, проставляє proxy, керує ротацією.
• Retry/backoff: при 429/403 — або збільшуємо паузу, або міняємо проксі, або відкладемо SKU.
• Pipeline: нормалізує дані (ціна, валюта, наявність), пише в базу й лог змін.

Ритм перевірок і «розумні» ліміти

Щоб не ловити бани, краще закласти логіку частоти:

• SKU з високим оборотом: частіше, але невеликими порціями.
• SKU з низькою важливістю: рідше, без високої паралельності.
• Окремо — сторінки категорій/пошуку, щоб виявляти нові позиції або зміни асортименту.

Технічно це реалізується через пріоритети запитів, черги, а інколи — окремі spider-и для «швидких» та «обережних» сценаріїв. Якщо ви робите моніторинг постійно, корисно зберігати стан джобу (щоб продовжувати після перезапуску) та мати окремий лог «чому SKU не зібрався» (бан, капча, змінилась верстка, таймаут, тощо).

Поради, які реально знижують ризик блокувань

• Увімкніть AutoThrottle і дивіться debug-статистику в перші дні — так ви побачите, на яких сторінках сайт «дратується».
• Не женіться за CONCURRENT_REQUESTS. Часто 2–8 паралельних запитів на домен — вже багато для захищених ретейлерів.
• Стабілізуйте заголовки (User-Agent, Accept-Language) і не робіть «хаос» у кожному запиті.
• Валідуйте контент: краще один раз визначити сторінку капчі, ніж записати «ціну = None» і зламати аналітику.
• Розділяйте домени: різні правила швидкості та ретраїв для різних сайтів.
• Логуйте помилки по проксі/регіону/домену — так ви знайдете слабкі місця в конфігурації.

Типові помилки при підключенні мобільних проксі до Scrapy

• Проксі налаштований, але не проставляється meta["proxy"] для частини запитів (наприклад, редіректи, повтори).
• Ретраї йдуть «в лоб» через той самий маршрут, тому бан тільки посилюється.
• Висока паралельність + відсутність delay → короткий «сплеск» трафіку, який тригерить антибот.
• Немає відрізнення 200-капчі від 200-контенту — дані стають сміттям.
• Всі домени мають один режим throttling, хоча сайти різні за політикою та захистом.

Мінімальний чек-лист перед запуском у прод

• Тестовий прогін на 50–200 URL з логами AutoThrottle та статус-кодів.
• Перевірка «антибот» сигнатур у відповіді.
• Політика ретраїв: які коди повторюємо, скільки разів, з яким backoff.
• Окремі ліміти на домен (delay/конкурентність).
• Моніторинг: частка 403/429, середній час відповіді, відсоток успішних парсингів, «падаючі» регіони.

Підсумок

Мобільні проксі для Scrapy — це спосіб зробити краулер «ближчим» до мобільного користувача й отримувати регіональну видачу там, де датацентрові IP швидко блокуються. Але результат дає комбінація: правильно зібраний scrapy proxy middleware, контроль ретраїв, грамотний throttling Scrapy (AutoThrottle/затримки/паралельність) та валідація контенту. Для кейсу моніторингу ретейлерів по регіонах це означає менше банів, більш чисті дані та прогнозовану роботу 24/7.