Індивідуальні мобільні проксі для A-Parser: налаштування, кейс SERP

2026-02-15

Пояснюємо, що таке A-Parser, як влаштовані парсери та модулі, і як індивідуальні мобільні проксі допомагають стабільно збирати SERP і метрики без зайвих блокувань.

Що таке A-Parser і для чого він потрібен

A-Parser — це багатопотоковий парсер/скрейпер, який запускає десятки й сотні паралельних запитів до різних джерел: пошукових систем (SERP), сервісів оцінки сайтів, каталогів, API-подібних вебінтерфейсів, а також інструментів для роботи з контентом. У документації A-Parser прямо позиціонується як multithreaded scraper із великою кількістю вбудованих скрейперів, тобто «модулів» під конкретні джерела.

Практично це означає, що ви завантажуєте список задач (наприклад, ключові слова або URL), обираєте модуль (Google/Бінг/сервіс метрик), задаєте правила збирання та отримуєте структурований результат: позиції, URL у видачі, заголовки, снипети, показники сервісів, списки посилань тощо.

Для яких задач A-Parser використовують у SEO та аналітиці

Збір SERP: перевірка позицій, аналіз конкурентів, відстеження зміни видачі за днями/тижнями, пошук доменів у топ-10/топ-100.
Локальний SERP: видача за конкретними містами/країнами (геозалежні результати), порівняння «Київ vs Львів» або «Польща vs Німеччина».
Масовий збір сторінок сайтів: сніпети, заголовки, статус-коди, редиректи, посилання, мікророзмітка — усе, що можна отримати з HTML.
Метрики з сервісів оцінки/аналізу (де є вебінтерфейс або доступний API): умовно «видимість», «зворотні посилання», «трафік-оцінки» тощо.
Підготовка семантики: підказки, пов’язані запити, «люди також питають» (якщо модуль це підтримує), кластеризація через зовнішні пайплайни.

Ключова цінність A-Parser — швидкість і масштаб. Але будь-який масштаб зіштовхується з антибот-захистом, тому питання проксі — практично базове.

Як влаштовані «парсер», «модуль» і «потоки» в A-Parser

У термінах A-Parser «модуль/скрейпер» — це набір правил і логіки, який знає, куди відправляти запит і як розібрати відповідь (HTML/JSON) у потрібні поля. Звідси й практичний підхід: під кожне джерело — свій модуль і свій профіль налаштувань.

Друга ключова частина — threads (потоки). У налаштуваннях прямо вказується кількість потоків, у яких працює задача, і зазначається, що її потрібно підбирати з урахуванням ресурсів сервера та лімітів тарифу/проксі. Чим більше потоків, тим швидше збір, але тим вищий ризик перевищити ліміти джерела й отримати бан або CAPTCHA.

Третя частина — проксі-лист і перевірка проксі. A-Parser має окремі інструменти для перевірки проксі (proxy checker), що важливо перед довгими задачами: «мертві» або повільні проксі з’їдають час і збільшують відсоток помилок.

Чому SERP та «складні» джерела блокують парсинг

Пошукові системи та великі сайти захищаються від автоматизованих запитів. Типові симптоми:

HTTP 429 Too Many Requests — ви зробили занадто багато запитів за короткий час (rate limiting). У відповіді іноді є заголовок Retry-After, який підказує, скільки чекати перед повтором.
CAPTCHA (зображення/recaptcha/hcaptcha) — джерело підозрює не-людську активність.
403/Access Denied або «Unusual traffic / automated queries» — блокування за IP/підмережу, іноді на рівні мережі, якщо один NAT або VPN «шумить».
Підміна контенту: замість реальної сторінки видачі повертається заглушка, сторінка з попередженням або спрощений HTML.

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

Чому саме мобільні проксі для A-Parser

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

Для SEO-парсингу мобільні проксі корисні, коли:

ви збираєте локальний SERP та хочете менше «шуміти» в очах пошуку;
потрібна стабільність на агресивно захищених джерелах (Google, маркетплейси, соцмережі);
важлива ротація IP за часом або за запитом;
потрібна геоприв’язка (країна/регіон) під конкретні міста/ринок.

Індивідуальні vs спільні мобільні проксі: у чому різниця

Під «індивідуальними» зазвичай мають на увазі формат one-channel / one-device: ви не ділите один мобільний модем/канал з іншими користувачами. На практиці це дає:

Передбачувану швидкість: сусіди не з’їдають ліміти та не провокують блокування.
Контроль ротації: ви можете змінювати IP у потрібний момент (API/посилання/таймер), а не коли «випаде» спільному пулу.
Стабільні сесії (sticky): корисно для джерел, де треба тримати cookies або проходити послідовність сторінок.
Нижчий ризик «колективної відповідальності», коли чужий трафік псує репутацію IP.

Спільні (shared) мобільні проксі можуть бути дешевші, але для SERP-моніторингу й регулярного парсингу «по графіку» індивідуальний канал зазвичай окупається стабільністю й меншим відсотком повторів.

Налаштування проксі в A-Parser: базова логіка

З погляду процесу все зводиться до трьох кроків:

підготувати список проксі (IP:PORT або з логіном/паролем, залежно від типу);
додати його в пресет/налаштування і вибрати режим використання проксі для задач;
перевірити проксі перед запуском (proxy checker), щоб відсіяти «мертві» та повільні.

У документації A-Parser є окремі розділи про proxy settings і proxy checkers, а також нагадування, що кількість потоків потрібно співвідносити з можливостями сервера та обмеженнями тарифу/проксі. Це практичний «якір»: спочатку налаштовуємо проксі й перевірку, і лише потім «накручуємо» потоки.

Ротація IP: як підібрати режим під SERP

Ротація буває різною, і правильний вибір залежить від джерела та обсягу:

Ротація за часом (наприклад, кожні 5–15 хвилин) — підходить, коли задачі йдуть безперервно й важливо «освіжати» IP на довгій дистанції.
Ротація за запитом (change IP per request / per N requests) — підходить для SERP, де небажано робити десятки запитів із одного IP підряд.
Sticky-сесія — корисна, якщо модуль ходить по кількох сторінках або треба зберігати cookies (наприклад, «далі/наступна сторінка»).

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

Практика антибану: що робити з 429, CAPTCHA і «unusual traffic»

Якщо джерело відповідає 429 Too Many Requests, це майже завжди сигнал «сповільнитись». У стандарті HTTP передбачений заголовок Retry-After, який може підказати час очікування. Технічно правильна поведінка — робити паузу та повторювати запит пізніше, а не «лупити» далі.

Повідомлення Google про «unusual traffic / automated queries» часто пов’язане з тим, що багато запитів іде з одного мережевого сегмента (наприклад, NAT, VPN або корпоративна мережа). У таких сценаріях мобільні проксі з різними IP і гео суттєво знижують ризики, бо розносять навантаження і мінімізують «підозрілу концентрацію» запитів.

Зменшуйте потоки та частоту запитів у пікових хвилях.
Додавайте паузи, джиттер (невеликі випадкові затримки), лімітуйте повтори.
Підтримуйте чистий проксі-лист: регулярна перевірка, відсів повільних і банених.
Дивіться на стабільність по містах/країнах: інколи краще мати 2–3 канали на країну, ніж один «забитий».

Кейс: збір SERP по містах України/ЄС для моніторингу позицій

Задача: отримувати релевантну локальну видачу для набору ключових фраз і відстежувати позиції сайтів у різних містах. Наприклад, для українського ринку — Київ, Дніпро, Львів, Одеса, Харків; для ЄС — Варшава, Краків, Бухарест, Прага, Берлін. Такі дані потрібні для:

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

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

Найзручніше мислити пайплайном:

Вхідні дані: список ключових фраз + список міст (або «ключ+місто» як готовий запит). Додатково: країна, мова інтерфейсу, пристрій (desktop/mobile), потрібна глибина (топ-10/топ-100).
Профілі проксі: окремі набори мобільних проксі під країни (UA/PL/RO/DE тощо) або під «складні» міста, де частіше банить.
Налаштування потоків: стартуємо з помірної кількості потоків і поступово піднімаємо, поки не побачимо ріст 429/капч.
Правила повторів: 429 → пауза/ретрай; CAPTCHA → ротація IP + відкладений повтор; 403 → зміна IP/зниження частоти.
Вихід: таблиця позицій (keyword, city, дата, позиція, URL, домен), плюс додаткові поля: тип результату (органіка/локальний пакет/відео), заголовок, снипет.

Тут мобільні проксі дають одразу дві переваги: (1) геоприв’язка, (2) стабільність на пошуку при масовій перевірці.

Налаштування, які реально впливають на стабільність

Поза проксі, на стабільність сильно впливають «дрібниці»:

Таймаути: занадто короткі таймаути створюють багато помилок і повторів; занадто довгі — «підвішують» потоки.
Ретраї: лімітуйте кількість повторів, інакше один банений запит може «вбити» продуктивність.
Backoff: після 429/капч робіть паузу, бажано з випадковим розкидом.
Розподіл навантаження: краще 2–3 паралельні задачі з різними пулами проксі, ніж одна «м’ясорубка» на 300 потоків.
Перевірка проксі перед кожним великим запуском і «чорний список» IP, які стабільно ловлять бани.

Короткий чек-лист перед запуском задачі в A-Parser

Підготувати актуальний proxy list і прогнати через proxy checker.
Задати консервативні threads і протестувати на невеликій вибірці ключів.
Визначити ротацію: per request / per N requests / per time, плюс sticky для серій.
Налаштувати обробку 429 (пауза, Retry-After якщо є) та обмеження ретраїв.
Зібрати результат у зручний формат (CSV/JSON) і зберігати історію по датах.

Висновок

Для задач на кшталт «SERP по містах України/ЄС» A-Parser дає масштаб і гнучкість, а індивідуальні мобільні проксі — стабільність і контроль. Комбінація «чистий проксі-лист + адекватні потоки + ротація + правильні паузи» дозволяє збирати публічні дані регулярно й прогнозовано, з мінімальними простоями через блокування.

HTTP(S) чи SOCKS5: який протокол проксі вибрати

У парсингу важливо не лише «мати IP», а й мати зручний протокол під ваші інструменти. Для A-Parser найчастіше використовують HTTP(S) або SOCKS5 — обидва варіанти підходять для більшості задач, але є нюанси:

HTTP(S) проксі простіші у налаштуванні та добре працюють із типовими веб-запитами. Якщо ви збираєте SERP або HTML-сторінки — цього зазвичай достатньо.
SOCKS5 більш універсальний на рівні мережі й інколи краще проходить через нестандартні сценарії (наприклад, коли модуль робить нестандартні з’єднання). Також SOCKS5 часто використовують у зв’язці з іншими автоматизаційними інструментами.
Авторизація: зверніть увагу, що частина провайдерів дає доступ по логіну/паролю, а частина — по IP whitelist. Для серверних парсерів зручний whitelist (менше шансів «засвітити» пароль у логах), але для мобільного середовища інколи практичніший логін/пароль.

Перед довгим запуском зробіть короткий тест: 50–100 запитів із тими ж налаштуваннями, що будуть у продакшені. Це швидко показує, чи є проблеми з протоколом, таймаутами або DNS.

Як зберігати та використовувати результати: від CSV до бази даних

Позиції в SERP мають цінність лише тоді, коли ви можете порівнювати їх у часі. Мінімальний практичний підхід — зберігати результат за датою в CSV, а далі будувати графіки/звіти. Більш надійний підхід — складати все у базу даних і зберігати історію як «знімки» (keyword, city, дата, пошуковик, пристрій, позиція, URL).

Дедуплікація: один і той самий URL може траплятися з різними параметрами. Нормалізуйте URL перед порівняннями.
Канонізація доменів: вирішіть заздалегідь, чи вважаєте ви subdomain окремим сайтом, чи агрегуєте до кореневого домену.
Версіонування налаштувань: зберігайте разом із результатами версію конфігу (threads, ротація, пул проксі). Це допомагає пояснювати «чому раптом стало більше капч».

Етика і «публічні дані»: як зменшити ризики

Парсинг публічно доступних сторінок не означає, що можна ігнорувати обмеження. Реалістична стратегія — працювати обережно: не створювати надмірного навантаження, поважати rate limiting і планувати збір так, щоб він був схожий на реальну поведінку користувача. Це не тільки «правильно», а й прагматично: менше блокувань — менше простоїв.