Коли ви збираєте дані з сучасних JS‑сайтів (каталоги, маркетплейси, конфігуратори), «просто зробити запит» часто не працює: ціни й наявність залежать від регіону, сторінка догружається скриптами, а захист від ботів швидко обрізає трафік. У таких задачах виручає Crawlee — бібліотека для надійних краулерів — і правильно підібрані проксі, зокрема mobile proxy.
Проксі для Crawlee: що саме налаштовуємо і навіщо
Фраза проксі для Crawlee у практиці означає два рівні налаштувань: (1) як обрати проксі‑IP для кожного запиту/сесії (ротація, «приклеювання» до сесії), і (2) де саме проксі підставляється в браузерний профіль (Playwright/Puppeteer) або HTTP‑клієнт. У Crawlee це робиться через клас ProxyConfiguration та (за потреби) SessionPool, який допомагає не повторювати запити через уже заблоковані проксі.
Чому саме Crawlee
- Стабільність: черги, повторні спроби, паралельність, контроль помилок.
- Браузерні краулери: інтеграція з Playwright для JS‑рендерингу.
- Проксі та сесії: вбудовані механіки ротації IP і «реалістичних» сесій.
Mobile proxy: коли вони реально дають перевагу
Mobile proxy — це проксі з IP‑адресами мобільних операторів, які зазвичай працюють через carrier‑grade NAT (CGNAT): багато абонентів «ділять» один публічний IP, а сама мережа природно перерозподіляє адреси. Саме тому мобільні IP часто мають вищу «довіру» у антибот‑систем, а ротація IP може відбуватися частіше, ніж у датацентрах.
Типові сценарії, де мобільні проксі відчутно допомагають:
- Гео‑QA: перевірка, як сайт показує ціни/доставку/валюту в різних регіонах.
- JS‑каталоги з блокуваннями: коли сторінка завантажує дані через XHR/GraphQL і швидко «банить» IP за частоту.
- Пошук «м’яких» блоків: коли сайт не віддає 403, а підсовує порожні картки, інший контент або капчу.
Порівняння проксі: коротка таблиця для вибору
| Тип | Плюси | Мінуси | Коли брати |
|---|---|---|---|
| Datacenter | Дешево, швидко, передбачувано | Легко детектуються, часті блоки | Внутрішні сервіси, прості сайти, тестове навантаження |
| Residential | Краще проходять антибот, є гео‑таргет | Дорожче, інколи нестабільний пінг | Каталоги/маркетплейси з середнім захистом |
| Mobile (індивідуальні) | Вища «довіра», природна ротація, добре для гео‑QA | Повільніше, дорожче, «плаваюче» точне місто/ASN | Складні JS‑сайти, регіональні ціни, часті блоки |
Де в Crawlee задається проксі «на рівні профілю»
У браузерних краулерах (PlaywrightCrawler) ключова ідея така: Crawlee обирає проксі‑URL (через ProxyConfiguration), а потім передає його в профіль запуску браузера (launch context / browser context). У JS‑документації прямо зазначено, що проксі‑URL може включати логін/пароль, наприклад http://user:pass@host:port.
Які поля потрібні: host/port/login/password і протокол
Практично це зводиться до таких параметрів:
- host — домен або IP проксі‑вузла;
- port — порт;
- login/password — для аутентифікації (якщо потрібна);
- protocol — схема у URL:
http,httpsабоsocks5(Playwright підтримує HTTP(S) та SOCKSv5, і дозволяє вказати username/password та список винятків bypass).
Налаштування в Crawlee (Node.js): ProxyConfiguration + PlaywrightCrawler
У Node‑версії типова інтеграція виглядає так: створюєте ProxyConfiguration, передаєте його в краулер, а далі Crawlee підставляє проксі для кожної сесії/запиту. Якщо не задавати sessionId, проксі‑URL у списку ротується по колу; якщо задавати — один і той самий sessionId буде прив’язаний до одного проксі‑URL, що допомагає імітувати «реального» користувача.
// Node.js (Crawlee + Playwright)
import { PlaywrightCrawler, ProxyConfiguration } from 'crawlee';
const proxyConfiguration = new ProxyConfiguration({
proxyUrls: [
'http://login:password@host1:port',
'http://login:password@host2:port',
],
});
const crawler = new PlaywrightCrawler({
proxyConfiguration,
// інші опції: maxConcurrency, requestHandlerTimeoutSecs тощо
async requestHandler({ page, request, session, log }) {
// якщо використовуєте SessionPool, session.id допоможе «приклеїти» IP
log.info(`URL: ${request.url}, session: ${session?.id ?? 'none'}`);
// ... збір даних
},
});
await crawler.run(['https://example.com']);
Порада для мобільних проксі: для задач із регіональними цінами часто краще не крутити IP на кожному запиті, а тримати «липку» сесію на групу сторінок (наприклад, один регіон = один sessionId), і міняти проксі лише при сигналах блокування або після N сторінок.
Налаштування в Crawlee (Python): ProxyConfiguration, ProxyInfo та SessionPool
У Python‑версії Crawlee логіка схожа: задаєте ProxyConfiguration з власними proxyUrls, і бібліотека автоматично ротуватиме їх. Під час обробки сторінки можна подивитися, який проксі реально використано, через ProxyInfo.
# Python (Crawlee + Playwright)
from crawlee.playwright_crawler import PlaywrightCrawler
from crawlee.configuration import ProxyConfiguration
proxy_config = ProxyConfiguration(proxy_urls=[
"http://login:password@host1:port",
"http://login:password@host2:port",
])
crawler = PlaywrightCrawler(proxy_configuration=proxy_config)
@crawler.router.default_handler
async def handle(ctx):
proxy_info = ctx.proxy_info # ProxyInfo: url та метадані
ctx.log.info(f"Using proxy: {proxy_info.url if proxy_info else 'none'}")
# ... збір даних
await crawler.run(["https://example.com"])
Як валідувати проксі перед «бойовим» запуском
Валідація — це не лише «бачу інший IP». Для гео‑QA важливо перевірити: (1) IP/ASN, (2) країну/регіон, (3) стабільність (помилки/таймаути), (4) чи весь трафік іде через проксі. У практичних гайдах часто використовують прості endpoints на кшталт HTTPBin, щоб подивитися, який IP бачить сервер.
| Перевірка | Як зробити | Що вважаємо «ОК» |
|---|---|---|
| IP змінився | Відкрити сторінку “what is my IP” / HTTPBin IP | Публічний IP не ваш датацентр/офіс |
| Гео відповідає плану | Порівняти IP‑гео в 2–3 сервісах | Країна збігається; місто може «плавати» на mobile |
| Аутентифікація | Запуск із login/password у URL або через поля proxy | Немає 407 Proxy Auth Required |
| Стабільність | 100–300 коротких запитів з обмеженою паралельністю | Низький % таймаутів, прогнозований TTFB |
Кейс: збір карток товарів з JS‑каталогів із різними цінами по регіонах
Задача: зібрати «картки» (назва, ціна, знижка, валюта, наявність) з каталогу, який:
- рендерить список через JS (XHR/GraphQL),
- показує різні ціни залежно від регіону доставки,
- вмикає м’які блоки після серії запитів з одного IP.
Архітектура рішення
- PlaywrightCrawler для коректного JS‑рендеру.
- Сесії (SessionPool) як контейнер cookies/локального стану і «липкого» проксі.
- Проксі‑стратегія: 1 сесія = 1 регіон, ротація при блокуванні.
- Збір даних: читати DOM карток або мережеві відповіді (якщо стабільні).
Кроки без «магії», які реально підвищують успіх
- Зафіксуйте регіон не лише IP: встановіть локаль/таймзону/валюту там, де це можливо (наприклад, через налаштування сайту або cookie/параметр доставки).
- Прив’яжіть IP до сесії: одна сесія «тягне» кілька сторінок, щоб не виглядати як 50 користувачів за хвилину. У Crawlee це робиться через зв’язку SessionPool +
ProxyConfiguration.newUrl(sessionId). - Окремо обробляйте блоки: 403/429, капча, порожній список, різка зміна HTML — це привід позначити сесію як погану і замінити проксі.
- Контролюйте паралельність: mobile proxy повільніші, тому краще більше сесій із меншою
maxConcurrency, ніж навпаки. - Логуйте ProxyInfo і ключові ознаки сторінки: так ви швидко зрозумієте, де «ламається» регіон чи контент.
Чому «ламаються» віджети та пікселі при гео‑парсингу через проксі
Коли ви заходите з іншого IP‑гео, сайт часто вмикає іншу гілку логіки: показує інший cookie‑банер, інший набір рекламних/аналітичних скриптів, або блокує third‑party контент до отримання згоди. Багато платформ прямо описують, що сторонній контент може не завантажуватися до consent‑події.
Додатковий нюанс — гео‑таргетинг банерів: деякі CMP активують/деактивують скрипти залежно від країни відвідувача, яку визначають по IP. Якщо ваш проксі «стрибає» між країнами або повертає неточне гео, отримаєте «биті» сценарії: піксель не ініціалізувався, віджет карти не завантажився, форма оплати відмовила.
| Симптом | Типова причина | Що робити |
|---|---|---|
| Порожні картки товарів | М’який блок або інша регіональна версія | Перевірити HTML‑маркер блокування; змінити сесію/проксі |
| Не вантажиться карта/відео | Third‑party заблоковано до consent | Взаємодія з банером, або працювати з API/бекендом |
| Ціни «стрибають» у межах одного регіону | IP ротувався посеред сесії; AB‑тест | Закріпити sessionId → проксі; зменшити ротацію |
| 407 Proxy Auth Required | Невірні логін/пароль або не той протокол | Перевірити схему URL та креденшіали |
Ризики, обмеження та типові помилки
- Плаваюча геолокація mobile IP: країна зазвичай стабільна, але місто/провайдер може не збігатися з очікуванням — закладайте допуски і валідуйте.
- Швидкість і таймаути: mobile proxy часто повільніші; збільшуйте таймаути, зменшуйте паралельність.
- Неправильна схема:
httpvshttpsvssocks5(Playwright підтримує HTTP(S)/SOCKSv5). - Ротація «надто часто»: якщо міняти IP на кожен запит, сайт бачить аномалію. Краще: ротація за сигналом блокування або за лімітом сторінок.
- Розсинхрон регіону: IP один, а cookie/локаль/валюта інші — отримуєте не ті ціни.
- Юридичні й етичні межі: поважайте правила сайту, robots, rate limits, не збирайте персональні дані без підстав і згоди.
Чекліст перед запуском у прод
- Є план по регіонах: країни/міста, валюта, мова, доставка.
- Проксі валідовані: IP, гео, стабільність, % помилок.
- Сесії увімкнені і логуються: sessionId, ProxyInfo, ознаки блокування.
- Стратегія ротації визначена: коли міняємо IP, коли «липимо» сесію.
- Дані зберігаються структуровано (таблиці/поля), щоб простіше контролювати якість і робити SEO‑звітність.
FAQ
Чи можна обійтися без проксі для Crawlee?
Іноді так: якщо сайт простий і без жорстких лімітів. Але для гео‑QA та JS‑каталогів проксі зазвичай потрібні, щоб розподілити трафік і стабілізувати сесії.
Як працює crawlee proxy rotation і чому важливий sessionId?
Якщо не передавати sessionId, проксі зі списку можуть ротуватися round‑robin. Якщо передавати, Crawlee може «приклеїти» один проксі‑URL до конкретної сесії, і повторні запити з тим самим sessionId підуть через той самий IP.
Що вибрати: crawlee playwright чи HTTP‑краулер?
Для JS‑каталогів і важких SPA частіше потрібен PlaywrightCrawler (рендер + робота з DOM/мережею). Для простих сторінок і API інколи вистачає HTTP‑краулера і дешевших проксі.
Чому «гео парсинг» дає різні ціни навіть із проксі?
Бо регіон визначається не лише IP: сайт може дивитися на cookie, обраний склад/місто доставки, валюту, мову інтерфейсу і навіть історію сесії. Тому важливо узгодити IP‑гео і параметри сесії.
Джерела
- Документація Crawlee (JS): Proxy Management, ProxyConfiguration та ротація за sessionId.
- Документація Crawlee (JS/Python): SessionPool та його роль у фільтрації заблокованих проксі.
- Документація Crawlee (Python): ProxyConfiguration і ProxyInfo.
- Документація Playwright: підтримка HTTP(S)/SOCKSv5 проксі, username/password та bypass.
- Пояснення mobile proxy та CGNAT (оглядові матеріали провайдерів).
- Про consent і блокування third‑party контенту/пікселів (приклади з CMP/платформ).