Навіщо взагалі моніторити мобільні проксі
Мобільні 4G/5G проксі дають «живий» операторський IP і часто проходять антибот‑фільтри краще за датацентрові адреси. Але в них є інша ціна: якість сильно плаває. Одна й та сама SIM/сота може бути ідеальною зранку та «вмирати» ввечері через навантаження, зміни маршрутизації, деградацію радіоканалу або ліміти оператора.
Якщо пул не контролювати, проблеми проявляються хаотично: десь зростає час відповіді, десь сиплються таймаути, десь раптово стрибає CAPTCHA. Для клієнта це виглядає як «проксі погані», а для вас — як нескінченний ручний дебаг.
Мета моніторингу проста: перетворити “хаос мобільної мережі” на керований сервіс. Для цього потрібні (1) зрозумілі метрики, (2) автоматична відбраковка слабких вузлів, (3) система алертів без «спаму», (4) прозорі звіти для клієнтів.
Базові метрики якості: що вимірюємо
Нижче — набір, який зазвичай дає 80% користі. Важливо: метрики мають рахуватися для конкретного вузла (SIM/модем/порт/endpoint) і для цільових сценаріїв (парсинг, логін, API, пошук).
- Latency — затримка запиту (ms). Міряємо p50/p95/p99, бо «середнє» маскує хвости.
- Jitter — розкид затримки у часі (варіативність). Для мобільних мереж це часто критичніше за саму latency.
- Drop rate — частка провалених спроб (таймаути, розриви, TCP reset). Це ваш «пакетний біль» у прикладному вимірі.
- Success rate — частка успішних бізнес‑операцій (отримали потрібну сторінку/JSON без помилки).
- Captcha rate — частка запитів/сесій, що завершились CAPTCHA або підозрілою перевіркою.
- Uptime проксі — доступність як сервісу: чи відповідає порт, чи проходить health‑check у заданому SLO.
- Контроль ротації IP — як часто змінюється IP, чи «застрягає» він, чи повторюється надто часто.
Як правильно міряти latency та jitter у 4G/5G
У мобільній мережі затримка складається з декількох шарів: радіоінтерфейс, транспорт оператора, вихід у інтернет, маршрут до цілі, обробка на сайті. Ваше завдання — вимірювати з точки користування (там, де стоїть проксі/модем або там, де піднімається SOCKS/HTTP) і окремо — до типових цілей.
- Швидкий “ping-like” тест: ICMP не завжди доступний. Альтернатива — TCP connect time або HTTP HEAD на “легку” ціль.
- Реальний HTTP сценарій: GET сторінки/endpoint, який схожий на клієнтський трафік (з User-Agent, заголовками, TLS).
- Вікна вимірювання: jitter краще рахувати як розкид (наприклад, стандартне відхилення або p95-p50) у вікні 5–10 хв.
Практичне правило: якщо p95 різко росте, а p50 майже не змінюється — проблема у «хвостах» (перевантаження або нестабільність). Якщо росте і p50, і p95 — деградація загальна (слабкий сигнал, поганий маршрут, throttling).
Drop rate: що вважати “падінням”
Drop rate має бути операційним: що реально ламає роботу клієнта. У логах це зазвичай:
- таймаут DNS/TCP/TLS/HTTP;
- HTTP 502/503/504 з боку проксі‑шару або upstream;
- розрив з’єднання під час передачі (incomplete read);
- різке зростання повторних спроб (retry) до того самого запиту.
Важливо відрізняти помилки мережі від помилок цілі. Якщо сайт стабільно віддає 500 для всіх проксі — це не дефект пулу. Тому добре мати «контрольний» вузол (еталонний інтернет без проксі) і порівнювати.
Captcha rate і success rate: метрики антибот‑реальності
Для мобільних проксі саме ці дві метрики найкраще відображають бізнес‑якість. Їх варто рахувати по сценаріях:
- Парсинг: успішно отримали HTML/JSON і пройшли перевірки (без блок‑сторінки, без “verify you are human”).
- Логін: успішний вхід без додаткових викликів або з прогнозованим рівнем верифікації.
- Пошук/карта: отримали релевантну відповідь без soft‑блоків.
Captcha rate рахуйте не лише по явній CAPTCHA. Додавайте «сурогати»: незвичні редіректи, сторінки з підозрілими ключовими словами, різке падіння розміру відповіді, статичні шаблонні HTML з “Access denied”.
Health-check пулу: від “сирих” метрик до одного скору
Окремі графіки корисні інженерам, але для автоматизації та звітів потрібен health score — число 0–100 або 0–1, яке показує «наскільки цей вузол придатний зараз».
Один з простих підходів:
- Нормалізуйте метрики у діапазон 0..1 (чим краще — тим ближче до 1).
- Дайте ваги: наприклад, success rate 0.35, captcha rate 0.25, drop rate 0.2, latency p95 0.15, jitter 0.05.
- Порахуйте зважену суму і застосуйте “стелю” для критичних умов (наприклад, якщо drop rate > 20% — score не вище 0.2).
Чому ваги важливі: для парсингу інколи можна пережити +200 ms latency, але не можна пережити 30% CAPTCHA.
Автоматична відбраковка: quarantine, backoff і “другий шанс”
Авто‑відбраковка має бути обережною: мобільна мережа шумна, і вузол може «просісти» на 10 хвилин, а потім відновитися. Тому замість “бан назавжди” використовуйте стани:
- Healthy — працює, доступний для видачі клієнтам.
- Degraded — якість гірша за норму; обмежуємо навантаження (менше потоків, менше RPS).
- Quarantine — тимчасово виключаємо з пулу на 15–60 хв, запускаємо посилені тести.
- Blacklisted — виключення на довгий строк (підозра на бан, токсичний IP, постійні капчі).
Технічні тригери для quarantine (приклад):
- success rate < 85% у вікні 10 хв;
- captcha rate > 20% у вікні 30 хв;
- p95 latency > 2500 ms і jitter різко виріс;
- drop rate > 10% при контрольному вузлі “зелено”.
Після карантину — “другий шанс”: якщо 3 послідовні health‑check пройдені, повертаємо у Degraded, а потім у Healthy.
Контроль ротації IP і боротьба з “залипанням”
Для багатьох клієнтів мобільні проксі купують саме заради ротації. Тому моніторинг має відповідати на питання: як часто змінюється IP і чи змінюється взагалі.
- IP age — скільки хвилин/годин поточний IP живе без зміни.
- Rotation success — чи відбулась зміна після команди/тригера (disconnect/reconnect, reset modem, смена профілю).
- IP повтори — як часто повертається той самий IP у межах 24 год.
Якщо IP “залипає”, це може бути нормою для конкретного оператора/регіону, а може бути симптомом: модем не перереєстровується, зависла сесія, або SIM в “пріоритетній” соті з малим пулом адрес.
Алерти: як не зробити систему, яка кричить завжди
Найпоширеніша помилка — алерт на кожен таймаут. Для мобільних проксі це означає нескінченний шум. Працює інший підхід:
- Алерти по тренду: погіршення у вікні (5–30 хв), а не одиничний інцидент.
- Симптоми, а не причини: success rate / captcha rate важливіші за “CPU модема”.
- Рівні: warning (Degraded) і critical (Quarantine/Blacklisted).
- Анти‑флаппінг: затримка на підтвердження (for: 5m), cooldown після спрацювання.
Окремо варто налаштувати алерти на “масові” події: якщо одночасно деградує 30% вузлів — це майже завжди проблема оператора, магістралі або вашого шлюзу.
Дашборди і звіти для клієнтів: що показувати, щоб не було питань
Клієнт не хоче читати 20 графіків. Йому потрібна відповідь: «пул стабільний чи ні, і чому». Хороший звіт має три рівні:
- Executive: uptime, середній success rate, captcha rate, топ‑проблеми тижня.
- Технічний: p95 latency, drop rate, розподіл health score, кількість ротацій, частка quarantined.
- Розслідування: список інцидентів (час, тривалість, причина, що зроблено).
Практика: додавайте “порівняння з минулим періодом” та “пояснення простими словами”. Наприклад: «з 18:00 до 23:00 у вашому регіоні виріс jitter, тому частіше випадали таймаути; ми автоматично зменшили навантаження і відправили 12 модемів у карантин».
Як організувати вимірювання: мінімальний стек
Реалізація може бути різною, але ідея одна: є пробер, який виконує тести, є сховище метрик, є візуалізація та алертинг.
- Пробери: HTTP/TCP/DNS checks, сценарні запити (логін, парсинг), контроль ротації.
- Метрики: часові ряди (latency, success) + логи подій (ротація, quarantine).
- Дашборди: по вузлах, по регіонах, по клієнтах, по сценаріях.
- Алерти: правила на health score і на масові деградації.
Для мобільних проксі корисно робити multi‑geo: тести з різних точок (наприклад, Молдова/Румунія/Україна) — так ви бачите, чи проблема локальна, чи глобальна.
Практичні пороги: з чого почати
Пороги залежать від цілей, але стартові “безпечні” налаштування для веб‑парсингу такі:
- p95 latency: warning 2000 ms, critical 3500 ms;
- jitter: warning 400 ms, critical 800 ms (у 10‑хв вікні);
- drop rate: warning 5%, critical 12%;
- captcha rate: warning 10%, critical 25%;
- success rate: warning < 92%, critical < 85%.
Порада: не “вгадайте” пороги з першого разу. Зберіть тиждень даних, подивіться розподіли, і підженете під ваші реальні кейси.
Деталі, які часто забувають: DNS, TLS і “час до першого байта”
Коли клієнт бачить “повільно”, корисно розкласти latency на компоненти. Навіть простий вимір може дати окремі метрики:
- DNS lookup time — чи не гальмує резолвер/операторський DNS.
- TCP connect time — швидкість встановлення з’єднання (часто страждає при перевантаженні мережі).
- TLS handshake — важливо для HTTPS сайтів; інколи падає через MITM/фільтрацію або проблеми часу на модемі.
- TTFB (time to first byte) — коли сервер почав відповідати; добре показує, де “застрягає” запит.
Для парсингу і SMM ці деталі допомагають пояснити клієнту, що саме сталося: «мережа жива, але DNS оператора повільний» або «TCP стабільний, але сайт відповідає повільно (навіть без проксі)».
Розріз “IP / SIM / сота”: як ідентифікувати джерело проблеми
У мобільних проксі «вузол» — це не лише IP. Мінімум потрібно знати:
- ідентифікатор модема/порту;
- SIM (або eSIM профіль);
- оператора/тариф;
- регіон і, якщо можливо, Cell ID (сота).
Чому це важливо: інколи проблемним є не конкретний IP, а ціла сота (вечірнє перевантаження), або конкретна SIM (після великого трафіку її “прикрутили”), або маршрут конкретного оператора.
Практичний підхід: тримайте “мапу пулу” — таблицю, де кожен проксі‑endpoint має атрибути (оператор, регіон, cell). Тоді ви зможете швидко відповісти: «captcha rate виріс тільки у групі “Operator A / Region X”».
“Токсичні” IP і чорний список: як робити правильно
Чорний список IP потрібен, але з ним легко перестаратися. У мобільних пулів адреси часто “плавають”, і бан може бути тимчасовим або залежати від цілі. Рекомендації:
- Ведіть blacklist по цілях (домени/категорії), а не один глобальний.
- Додавайте IP у blacklist лише після повторюваних симптомів: стабільна CAPTCHA/403 у кількох спробах.
- Ставте TTL: наприклад, 24–72 години, а потім “перевірка на повернення”.
- Відділяйте “ban” від “низька якість”: інколи IP чистий, але мережа повільна — це quarantine, не blacklist.
Квоти, навантаження і fair-use: моніторинг як захист інфраструктури
Якість пулу падає не лише через оператора — її можна «вбити» надмірним навантаженням. Тому моніторинг має включати прикладні ліміти:
- RPS/потоки на вузол (concurrency);
- обсяг трафіку на SIM за добу;
- частота ротацій (занадто часті reset можуть робити гірше);
- частка ретраїв (як індикатор проблеми, а не рішення).
Практичний механізм: якщо вузол у стані Degraded — автоматично зменшуйте concurrency, а запити розподіляйте на здорові вузли. Це знижує drop rate і продовжує життя пулу.
Метрики для різних кейсів: парсинг, SMM, арбітраж
Одна і та сама інфраструктура може обслуговувати різні сценарії, але “хороший проксі” для парсингу не завжди “хороший” для логіну в соцмережу. Тому корисно мати профілі:
- Scraping: пріоритет success rate і captcha rate; latency — другорядна.
- SMM / мультиакаунт: важлива стабільність сесій, низький drop rate, прогнозована ротація.
- Ads: критичні “провали” під час логіну/верифікації; важлива якість IP репутації (через captcha/soft-block).
У звітах для клієнтів показуйте метрики саме по їх профілю, інакше виникають зайві суперечки: «у вас latency 2 секунди» — але для парсингу це може бути нормально, якщо success 98% і CAPTCHA 3%.
FAQ: короткі відповіді на типові питання
- Чи можна мати 0% CAPTCHA? На практиці — майже ніколи. Важливіше тримати стабільний рівень і швидко відсікати сплески.
- Чому інколи “здоровий” вузол дає таймаут? У мобільній мережі є мікропровали. Тому рішення — не карати за один збій, а дивитись на вікна і тренди.
- Що краще: часта ротація чи стабільна сесія? Залежить від задачі. Для мультиакаунтингу — стабільність важливіша; для парсингу — ротація допомагає розподілити ризик.
- Як зрозуміти, що проблема у провайдері проксі, а не в сайті? Порівнюйте з контрольним вузлом без проксі і дивіться, чи деградація корелює між різними цілями.
Висновок
Моніторинг мобільних проксі — це не про красиві графіки, а про керований сервіс: ви бачите деградацію до того, як клієнт її відчує, автоматично відсікаєте слабкі IP/соти, контролюєте ротацію і показуєте прозорні звіти. Почніть з базових метрик (latency/jitter/drop/success/captcha), введіть health score і quarantine‑логіку — і пул стане прогнозованим навіть у “шумній” 4G/5G реальності.