Мобільні проксі Apify: налаштування, перевірка гео, діагностика

Що таке Apify і як ним користуються для збору даних

Apify — це платформа для веб-автоматизації та збору даних, де ваш скрипт або готовий модуль запускається як Actor (серверлес-мікросервіс із входом та виходом). Actor може працювати за розкладом, приймати параметри (Input), зберігати результати в Dataset/Key‑Value Store/Request Queue і віддавати їх через API або інтеграції. Такий формат зручний для команд маркетингу й аналітики: один раз налаштовуєте сценарій, а далі отримуєте регулярні вивантаження для BI, таблиць, QA локалізації чи A/B‑перевірок.

У термінах SEO це часто описують як actors scraping (запуск готових Actors для парсингу) та apify інтеграції — підключення вебхуків, BI і no‑code інструментів до результатів run.

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

• Пілот (proof‑of‑concept): швидко запустити готовий Actor зі Store або зібрати свій мінімальний прототип.
• Автоматизація збору даних: поставити запуск за розкладом (щодня/щотижня), нормалізувати поля й контролювати помилки.
• Інтеграції: відправити дані у сховище/таблиці або тригерити наступні процеси вебхуками.

Проксі для Apify: коли потрібні індивідуальні mobile proxy

Ключова причина, чому бізнес обирає проксі для Apify, — керований доступ до сайтів із геозалежним контентом і зниження ризику блокувань за IP/частоту запитів, особливо коли ви тестуєте сценарій або масштабуєте збір даних. Індивідуальні mobile proxy додають ще один рівень «природності»: трафік виглядає як з мобільних мереж (3G/4G/5G), що часто корисно для швидких пілотів та перевірок «як бачить мобільний користувач».

Apify Proxy vs власні мобільні проксі

У Apify є власний сервіс Apify Proxy (datacenter/residential/SERP), а також можливість підключати сторонні проксі як Custom proxies. Вибір зазвичай такий:

• Apify Proxy — коли потрібна керована ротація та інтеграція «з коробки» в Actors/SDK, плюс прозорі параметри сесій і країни.
• Індивідуальні mobile proxy — коли вам важливо працювати з конкретними мобільними підмережами/операторами, мати «sticky» IP, або коли постачальник дає гарантований пул під клієнта.

Тип проксі	Типові плюси	Типові мінуси	Коли доречно
Datacenter	Швидкі, стабільні, дешевші	Частіше баняться, інколи «схожі на бота»	Технічні сайти, легкі ліміти, багато сторінок
Residential	Краща «довіра» за рахунок ISP‑мереж	Дорожчі, сесії можуть бути коротші	Каталоги/маркетплейси зі строгими правилами
Mobile	Трафік як з мобільних мереж, часто краща прохідність для PoC	Найдорожчі, сильна залежність від провайдера (ротація/липкість)	Локалізаційні перевірки, мобільні видання сайтів, «швидкі пілоти»

Де в Apify задається проксі: рівень профілю та рівень Actor

1) Рівень профілю (Apify Console → Proxy): доступ, групи, пароль

На рівні акаунта (профілю) в Apify Console є сторінка Proxy, де ви бачите налаштування Apify Proxy: доступні групи, а також Apify Proxy password, який потрібен для підключення. Документація прямо вказує, що пароль відображається на Proxy‑сторінці в консолі.

Важливий нюанс для E‑E‑A‑T та безпеки: підключення до Apify Proxy відбувається через HTTP proxy protocol, і в документації є попередження, що пароль передається незашифрованим через обмеження протоколу. Це означає, що пароль не варто «світити» у відкритих логах, а доступ до нього — обмежити.

2) Рівень Actor (Input and options → Proxy and browser configuration)

Під час запуску Actor (або налаштування Task) проксі задається у налаштуваннях запуску. Для Custom proxies Apify рекомендує: у вкладці Input and options прокрутити до секції Proxy and browser configuration і вставити свої proxy URL.

Саме тут і підключаються індивідуальні mobile proxy: ви не «перепрошиваєте» акаунт, а додаєте список URL‑ів проксі на рівні конкретного запуску/таску — що зручно для тестів, розмежування клієнтів і контрольованих пілотів.

3) SDK рівень (Crawlee / Apify SDK): ProxyConfiguration і сесії

Якщо Actor написаний на JavaScript/TypeScript (Crawlee) або Python (Apify SDK), проксі керуються через ProxyConfiguration: ви передаєте список proxy URL або вмикаєте Apify Proxy і задаєте параметри країни/груп/сесій. Для власних проксі документація радить генерувати URL через newUrl(sessionId) / new_url(session_id), щоб зручно керувати «липкими» сесіями.

Які поля потрібні: host/port/login/password та тип протоколу

Для індивідуальних mobile proxy провайдер зазвичай видає 4 базові поля:

• host — домен або IP проксі‑шлюзу;
• port — порт;
• login (username) — логін/підкористувач;
• password — пароль;
• protocol — найчастіше http або https (інколи SOCKS5, але його підтримка залежить від вашого стеку).

У більшості випадків в Apify вам потрібен proxy URL у форматі:

http://LOGIN:PASSWORD@HOST:PORT

Поле	Як воно виглядає	Де використовується в Apify	Типова помилка
host	m-proxy.example.com	частина proxy URL	плутають із «цільовим сайтом»
port	8000 / 3128 / 1080	частина proxy URL	беруть порт від панелі провайдера, а не від шлюзу
login	subuser-country-ua	частина proxy URL	не кодують спецсимволи в логіні
password	********	частина proxy URL	логують у відкритому вигляді
protocol	http / https	схема URL	вказують https, хоча проксі підтримує лише http

Покроково: як підключити індивідуальні mobile proxy в Apify

Крок 1. Підготуйте список проксі URL

Зберіть 1–10 URL‑ів для старту пілоту (далі масштабуєте). Якщо провайдер видає одну «точку входу» з параметрами країни/оператора в логіні, вам може вистачити 1 URL.

Крок 2. Додайте проксі в Actor run / Task

• В Apify Console відкрийте Actor або Task.
• Перейдіть у Input and options.
• Прокрутіть до Proxy and browser configuration.
• Оберіть Custom proxies і вставте список proxy URL.
• Запустіть тестовий run з малим лімітом сторінок.

Цей шлях відповідає офіційній рекомендації Apify щодо підключення власних проксі в консолі.

Крок 3. Підключіть сесії (session persistence), якщо потрібна «липкість»

У scraping‑сценаріях «липка» сесія потрібна не для «обману», а для коректної бізнес‑логіки: наприклад, щоб сайт не скидав кошик/фільтри/валюту між запитами, або щоб ви коректно пройшли сценарій локалізації в рамках одного користувача.

• Для Apify Proxy «липкість» задається параметром session у username; запити з однаковим session ID будуть маршрутизовані через один IP.
• Для mobile proxy механіка залежить від провайдера (інколи session ID вбудовується в login, інколи — через окремий параметр). Логіка тесту одна: для одного session ID IP не має «стрибати» без вашого запиту на ротацію.

Валідація: як перевірити країну, ASN і стабільність сесії

1) Перевірка IP → Country прямо під час run

Найпростіший метод — зробити контрольний запит через проксі на діагностичний endpoint і зчитати, який IP та код країни бачить сервер. У Apify є публічний endpoint /v2/browser-info, який повертає clientIp і countryCode та навіть показує accept-language з вашого запиту.

Практика для пілоту:

• на старті run зробіть 1–3 контрольні запити через той самий проксі/сесію;
• залогайте clientIp, countryCode і перші 2–3 ключові заголовки (наприклад, user-agent, accept-language);
• якщо країна не збігається — не витрачайте трафік на цільовий сайт, спершу виправте проксі.

2) ASN check: чи це справді «мобільна» мережа

Країна IP ще не гарантує «мобільність». Частина проксі‑провайдерів може віддавати IP з hosting‑провайдера в потрібній країні, що виглядатиме як datacenter. Тому для mobile proxy корисно робити ASN check — перевірити автономну систему (ASN), якій належить IP, і порівняти її з очікуваними операторами/ISP. Для цього можна використати, наприклад, ASN‑дані від IPinfo або RIPEstat (у RIPEstat є ендпоїнти, що працюють з ASN/країнами й маршрутизацією).

Мінімальне правило якості для PoC: «країна збігається + ASN схожий на телеком/ISP, а не на класичний хостинг».

3) Перевірка, що сесія не “пригала” (session persistence)

Перевірка проста: для одного session ID зробіть 3–5 контрольних запитів з паузою (наприклад, 10–30 секунд) і порівняйте clientIp. Якщо IP змінюється без вашої ініціативи — у вас немає «липкої» сесії, або провайдер робить короткі ротації.

Для Apify Proxy документація описує, що сесії підтримуються та мають різну «тривалість життя» залежно від типу проксі (наприклад, для datacenter — довше, для residential — коротше). Це пояснює, чому інколи «вчора трималося, а сьогодні ні» при зміні типу пулу.

Що перевіряємо	Як перевіряємо	Ознака “ок”	Що робити, якщо “не ок”
Країна	browser-info через проксі	countryCode = потрібний	перевірити налаштування країни в логіні/пулі провайдера
ASN	lookup clientIp у сервісі ASN	ASN схожий на ISP/оператора	попросити “mobile/ISP” пул, змінити постачальника
Стабільність IP	3–5 запитів з одним session	IP не змінюється	увімкнути sticky в провайдера або перейти на session‑режим

Чому “країна та, а локаль не та”: що впливає на локалізацію

На практиці локалізація сторінки визначається не лише IP‑гео. Типові причини, чому ви бачите «країна правильна, але мова/валюта/контент — ні»:

• Accept-Language: браузери відправляють заголовок, який підказує бажану мову/локаль; сервер може робити контент‑неготіацію на його основі.
• Timezone / locale в браузері: багато сайтів читають таймзону та локаль із JS‑оточення, і якщо вони «випадають» із країни IP, може спрацювати альтернативний сценарій (редірект, “global” версія).
• Cookies і “пам’ять” вибору: якщо під час тестів ви один раз вибрали країну/мову, сайт може тримати це в cookie або LocalStorage й ігнорувати IP.
• CDN edge і server‑side geo: CDN (наприклад, Cloudflare) може додавати заголовок країни на основі своєї бази геолокації; інколи це відрізняється від «того, що показує ваш сервіс перевірки IP».
• Гео на рівні акаунта/додатку: мобільні додатки та деякі сайти підтягують країну з профілю користувача, а не з IP.

Як “стабілізувати” локалізацію для коректної аналітики

Безпечний підхід (без “хакінгу”): зробіть узгодженими IP‑гео, Accept‑Language, timezone і cookies у межах одного тесту. Тобто якщо ви тестуєте UA‑ринок, логічно мати UA‑IP, українську/російську як пріоритет у Accept‑Language, таймзону Europe/Kyiv і чистий профіль/сесію для кожного сценарію. Для browser‑crawler‑ів це часто означає роботу з browser profiles та принципом fingerprint consistency: щоб дрібні сигнали (Canvas/WebGL, мова, таймзона) не суперечили одне одному.

Чому “ламаються” віджети, пікселі та сторонні скрипти

Під час збору публічних даних часто ламається не основний HTML, а 3rd‑party частина: віджети “наявність у магазинах”, карти, рекомендації, рекламні пікселі. Типові причини:

• Політики доступу третіх сторін: окремі провайдери (аналітика/карти/платежі) можуть обмежувати показ у певних країнах або блокувати підмережі.
• Блокування підмереж (ASN/подсети): якщо ваш proxy ASN відомий як «анонімайзер», сторонній скрипт може не завантажитись.
• Rate limiting: навіть якщо головний сайт терпить, CDN або API віджета може різати частоту.

Для аналітики асортименту це важливо: якщо ціни/наявність рендеряться через API віджета, вам потрібен або browser‑режим, або окремий збір із цього API (якщо він публічний і дозволений). У будь-якому разі варто робити локалізаційний QA (перевірка мови/валюти/редіректів) окремо від “масового” парсингу.

Як відрізнити проблему проксі від проблеми сайту: розширений алгоритм діагностики

Коли «все падає», найчастіша помилка — одразу міняти проксі або одразу звинувачувати сайт. Натомість використайте мінімальний алгоритм діагностики (10–15 хвилин), який зекономить бюджет на трафік.

Кроки діагностики

1. Базова контрольна точка: перевірте проксі на нейтральному ендпоїнті (наприклад, Apify browser-info) і зафіксуйте IP/країну/заголовки.
2. Порівняння без проксі: зробіть той самий запит без проксі з Apify‑інфраструктури. Якщо без проксі теж помилка — проблема не в проксі.
3. Один URL → різні мережі: перевірте цільовий сайт двома різними проксі (наприклад, mobile і residential). Якщо ламається лише один — підозра на блокування підмережі/ASN.
4. Перевірте редіректи: чи не відбувається geo redirect на інший домен/мову/валюту (важливо для парсерів).
5. Перевірте частоту: додайте паузи, зменшіть паралельність. Rate limiting часто маскується під 403/429/капчу.
6. Для Apify Proxy: якщо бачите нестандартні 59x коди (590–599), це підказки щодо upstream‑помилки (DNS, auth, reset тощо).
7. Перевірте профіль браузера (для browser‑crawler): чи збігаються locale/timezone/Accept‑Language з гео‑ціллю.

Симптом	Ймовірно	Швидка перевірка	Що зробити
browser-info показує «не ту країну»	проксі пул/гео налаштовані неправильно	перевірити 3 різні запити з різних сесій	виправити країну в провайдера або змінити пул
403/капча тільки на mobile ASN	блок підмережі або політика сайту	порівняти з residential/datacenter	змінити ASN/постачальника, знизити швидкість
Контент є, але валюта/мова не ті	Accept-Language/таймзона/cookies	дивитись accept-language у browser-info	узгодити locale/timezone, очистити cookies, стабілізувати профіль
Віджет/ціни не підвантажуються	3rd-party geo, блок підмереж, CORS	дивитись мережеві запити у browser‑режимі	збирати з публічного API або рендерити сторінку в браузері

Практичний кейс: маркетингова аналітика асортименту конкурентів

Ціль і межі

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

Пайплайн в Apify (спрощено)

• Actor отримує список категорій/URL і параметри локалізації (країна, мова, валюта).
• Запуски йдуть як Task за розкладом (наприклад, о 03:00 щодня).
• Результат пишеться в Dataset зі стабільною схемою полів.
• Інтеграції: вебхук після завершення шле дані/посилання в BI або тригерить сценарій у Make/n8n/Zapier.

Де тут mobile proxy дає максимум цінності

• Пілот: швидко перевірити, що конкурент віддає коректну мобільну/локалізовану версію, і що парсер стабільний.
• Localization QA: перевірити geo redirect, мову, валюту й контентні відмінності між країнами.
• Контроль “fingerprint consistency”: якщо збір у браузері, тримати узгодженість locale/timezone/Accept‑Language/WebGL/Canvas між запуском і сесією.

FAQ

Чи можна в Apify використовувати власні проксі замість Apify Proxy?

Так. Apify підтримує Custom proxies у консолі (через секцію Proxy and browser configuration) і в SDK через ProxyConfiguration.

Як перевірити, що проксі реально в потрібній країні?

Зробіть контрольний запит через проксі на Apify /v2/browser-info і подивіться countryCode. Для більшої надійності повторіть 3 рази з різними сесіями.

Навіщо перевіряти ASN для mobile proxy?

Бо «країна правильна» не гарантує, що IP належить мобільному оператору або ISP. ASN check допомагає відсіяти hosting‑пули, які можуть блокуватися частіше.

Чому країна одна, а мова сторінки інша?

Найчастіше через Accept-Language, таймзону, cookies або server-side geo від CDN. Перевіряйте ці сигнали й робіть їх узгодженими для конкретного тесту.

Як зрозуміти, що проблема саме в проксі, а не в сайті?

Порівняйте поведінку на нейтральному ендпоїнті (browser-info), без проксі та з альтернативною мережею. Якщо помилка зникає при зміні ASN/типу проксі — це сильний сигнал, що проблема в проксі або блокуванні підмережі.

Короткий чеклист перед масштабуванням

• Зібрані host/port/login/password і правильний протокол (http/https).
• Перевірені IP → Country і ASN для кожного пулу.
• Налаштована session persistence там, де потрібна “липкість”.
• Узгоджені locale/timezone/Accept‑Language і чисті cookies для локалізаційних тестів.
• Є таблиця симптомів/перевірок і логування ключових сигналів.

Джерела

• Apify Documentation: Proxy usage; Using your own proxies; Running Actors; Webhooks.
• MDN Web Docs: Accept-Language header.
• Cloudflare Docs: IP geolocation (CF-IPCountry).
• RIPE NCC RIPEstat: Country ASNs endpoint; довідка про ASN.