Пул з кількох операторів: failover без падіння сесій у мобільних проксі

2026-02-07

Як зібрати пул мобільних проксі з 2–3 операторів, налаштувати health-check, маршрутизацію та sticky-сесії, щоб збій мережі не «валив» клієнтів і не ламав процеси.

Чому варто будувати пул із кількох операторів

Коли ви продаєте або використовуєте пул мобільних проксі оператори в одному місті чи країні, «один оператор» майже завжди означає одну точку відмови. У мобільних мережах трапляються локальні деградації: падає окрема базова станція, провалюється магістраль, зникає IPv4, з’являється масова затримка або packet loss. Додаємо планові роботи, «перегрів» соти у пікові години, обмеження за трафіком/сесіями та антифрод-реакції сервісів — і стає очевидно, що резерв потрібен не для «колись», а для щоденної стабільності.

Пул із 2–3 операторів дає практичні переваги:

Покриття і якість: в одному районі перемагає оператор А, за містом — оператор B, у приміщенні — оператор C.
Ємність: можна рознести навантаження між сотами та знизити ризик throttling.
Менше простоїв: збій у одного оператора не означає зупинку всіх клієнтів.
Контроль політик: різні оператори по-різному поводяться з CGNAT, IPv6, TTL, портами, що впливає на сценарії парсингу, арбітражу та SMM.

Що саме «падає» під час failover і чому це болить

Важливо розрізняти 3 рівні: (1) сесія клієнта до вашого проксі-ендпойнта, (2) TCP/TLS-з’єднання від проксі до цільового сайту, (3) «логін-сесія» на рівні cookies/токенів у браузері або скрипті. Коли змінюється аплінк (оператор/модем), зазвичай змінюється й публічний IP виходу в інтернет. Для звичайного TCP це означає розрив активних з’єднань і повторний хендшейк; звідси «падіння сесій» у клієнтів.

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

4 моделі резервування: від простого до «майже безшовного»

Модель 1. “Cold failover” (перемкнули маршрут — усі активні з’єднання обірвалися)

Найпростіший варіант: на роутері є основний WAN (оператор А) і резервний WAN (оператор B). Якщо health-check «червоний», маршрут міняється. Це швидко налаштовується, але майже гарантовано обриває активні TCP/TLS потоки, бо змінюється шлях/адреса/стан NAT. Цей варіант підходить лише для сценаріїв, де повторне підключення клієнта допустиме (наприклад, короткі запити з ретраями).

Модель 2. “Session-aware failover” (не мігруємо активні потоки, рятуємо нові)

Практичний стандарт для мобільних проксі. Ідея: активні sticky-сесії не перекидаються на інший оператор; при збої вони завершаться/відваляться, але система не створює додаткового хаосу. Натомість нові підключення одразу спрямовуються на живий оператор. Так ви зменшуєте втрати: не валите все одразу, а «локалізуєте» проблему у тих сесіях, які вже були прив’язані до проблемного модема/оператора.

Модель 3. “Tunnel-anchored failover” (стабільний вихід IP для клієнта)

Тут ви «якорите» вихід через тунель до точки агрегації (VPS/edge), а вже під тунелем міняєте аплінк між операторами. Для клієнта це виглядає як один стабільний проксі, навіть якщо знизу відвалився оператор. Такий підхід широко використовується в SD‑WAN і bonding-рішеннях: при відмові одного WAN трафік переноситься на інший із збереженням сесій у межах тунелю. Наприклад, у SpeedFusion “Hot Failover” заявляється перенос трафіку на інше з’єднання з session persistence.

Важлива ремарка: якщо вам потрібен саме мобільний IP як вихід до цільового сайту, то тунель на VPS зробить вихід «датацентровим». Тому ця модель — про безшовність для клієнта, але не завжди про “mobile egress”.

Модель 4. “Multipath” (MPTCP/подібні техніки для виживання з’єднань при зміні мережі)

Транспортні технології на кшталт Multipath TCP дозволяють одній логічній TCP-сесії мати кілька підпотоків і переживати зникнення одного шляху: якщо один інтерфейс зникає, з’єднання може продовжитися на іншому. Це описується як ключова перевага MPTCP для мобільності та відмовостійкості.

Але є нюанс: MPTCP працює, коли його підтримують обидві сторони з’єднання або є проксі/шлюз, який термінує MPTCP. У практиці мобільних проксі це частіше використовується всередині вашої інфраструктури (між edge‑роутером і вашим тунельним сервером), а не між проксі та довільним сайтом.

Як зробити failover так, щоб «не валити» sticky‑сесії

1) Визначте, що таке “сесія” у вашому продукті

Для мобільних проксі в комерційному сенсі сесія — це не TCP‑з’єднання, а період, коли клієнт хоче зберігати один і той самий вихід: 5 хв, 30 хв, 2 год, «до ручного rotate». Саме це й треба робити sticky.

Практичне правило: одна sticky‑сесія повинна бути прив’язана до одного модема/оператора до завершення TTL. Якщо модем «помер», ви або (а) зриваєте сесію та віддаєте помилку (чесно), або (б) переводите сесію у “degraded mode” з іншим IP (якщо клієнт погодився). Друга опція для багатьох задач прийнятна: скрипт просто продовжує роботу, але з новим IP.

2) Health-check має бути багаторівневим

Ping до 8.8.8.8 — недостатній. У мобільних мережах бувають ситуації «ping ок, а HTTPS не працює» (проблеми MTU, DNS, фільтри, broken TCP). Тому робіть 3 рівні:

Link: чи є IP, чи піднятий інтерфейс, чи не в «no service».
Network: RTT/loss до 2–3 контрольних IP.
Application: DNS+HTTPS GET до ваших контрольних доменів (наприклад, власний health endpoint + 1–2 незалежних).

У MikroTik спільнота часто використовує “recursive routes” та check‑gateway як базову техніку контролю доступності маршруту (із застереженням, що простий check‑gateway має обмеження і може потребувати складніших підходів).

3) Failover-логіка: “stop assigning” замість “move everyone”

Ключ, щоб не ламати клієнтів: коли оператор деградує — перестаньте призначати нові сесії на цей аплінк, але не перетрушуйте уже призначені sticky‑мапінги. У вас з’являться “unhappy sessions”, але їх кількість обмежена активними користувачами на цьому операторі в момент збою, а не всім пулом.

Реалізаційно це виглядає так:

Стан оператора: UP, DEGRADED, DOWN.
У DEGRADED — не видаємо нові sticky‑сесії, але допускаємо існуючі (за бажанням).
У DOWN — блокуємо нові, існуючі або завершуємо, або переводимо в “degraded mode” (опційно).

4) Алгоритм розподілу: зважене consistent hashing

Щоб під час коливань не «перемішувати» всіх користувачів, використовуйте consistent hashing або фіксоване правило прив’язки (наприклад, user_id → operator/modem). Тоді при випадінні одного оператора зміниться лише частина мапінгу (ті, хто був на ньому), а решта залишиться стабільною.

Вага (weight) потрібна, щоб враховувати реальну ємність. Наприклад, якщо у оператора A 10 модемів, у B — 5, то розподіл має бути 2:1. При цьому важливо враховувати не лише кількість, а й якість каналу в реальному часі (RTT/loss).

5) Проксі-рівень: sticky в авторизації + контроль “rotate”

Найзручніше робити sticky через параметр сесії в логіні (наприклад, user-session-123) або окремим токеном. Проксі-сервер приймає запит, дивиться на сесію і знаходить у сховищі «який модем» для неї виділений. Для “rotate” клієнт або міняє session id, або викликає ваш API (якщо він є).

Якщо ви використовуєте chaining/parent proxies (коли локальний проксі перекидає трафік на upstream), перевірте, як ваш софт поводиться зі списками батьківських проксі, include-файлами та fallback. У 3proxy, наприклад, у репозиторії є обговорення поведінки з кількома parent proxies і нюансів із include, що може впливати на очікуваний failover.

6) MTU і “тихі” деградації

Під час перемикань і тунелів часто вилізають MTU‑проблеми: частина сайтів відкривається, частина — ні; зростає число timeouts. Тому в health-check корисно мати тест HTTPS на реальний контент і збирати статистику помилок за типами: connect timeout, TLS handshake timeout, 407/403, DNS timeout тощо.

Як побудувати «резерв без падіння» у двох найпоширеніших сценаріях

Сценарій A: ви продаєте саме мобільний egress (ціль бачить IP оператора)

Тут неможливо зробити ідеальну «безшовність» для вже відкритих TCP‑з’єднань, бо при переході на іншого оператора зміниться IP. Реалістична мета:

Не валити клієнтський доступ до проксі (ваш endpoint працює завжди).
Мінімізувати втрати — не мігрувати активні sticky‑мапінги, а тільки припиняти видачу нових на проблемний оператор.
Дати клієнту керування: “rotate now”, “fallback allowed”, “strict mobile IP”.

Рекомендація по продукту: зробіть 2 режими для клієнта — Strict (при падінні модема сесія завершується) і Resilient (дозволено перейти на інший оператор/модем навіть якщо зміниться IP). У багатьох задачах (парсинг, прогрів акаунтів, QA‑перевірки) “Resilient” дає кращий SLA.

Сценарій B: вам важлива безшовність для клієнта (вихід може бути не мобільний)

Якщо основна ціль — щоб клієнт не відчував перемикань (наприклад, API‑інтеграції, довгі завантаження, стріми), то «якір» у вигляді тунелю/SD‑WAN дає максимальний ефект. Ідея така сама, як у whitepaper/описах SD‑WAN: при втраті WAN трафік переноситься на інший канал, зберігаючи сесію в межах оверлею.

Окремо: спроби «зберегти той самий WAN IP» при переході між провайдерами зазвичай упираються в BGP та домовленості між провайдерами; в реальному житті це майже завжди складно або неможливо без участі ISP.

Операційні практики: щоб failover працював не лише на діаграмі

Моніторинг і алерти

RTT/loss/jitter по кожному модему та оператору.
Відсоток помилок проксі по оператору (5xx/timeout/TLS fail).
Кількість активних sticky‑сесій на кожному модемі.
Час відновлення після падіння (MTTR) і частота деградацій.

Планові “chaos” тести

Раз на тиждень симулюйте відмову: вимкніть один модем або від’єднайте антену на 2–3 хв. Перевірте, що:

нові сесії не призначаються на проблемний аплінк;
клієнти отримують прогнозовану поведінку (або помилку, або fallback у “Resilient”);
після відновлення аплінк повертається у пул із затримкою (cooldown), щоб уникнути «флапання».

Чек-лист налаштування (коротко)

Мінімум 2 оператори, краще 3; різні локації/соти.
Health-check: link + network + application.
Стани UP/DEGRADED/DOWN + cooldown після recovery.
Sticky‑сесії з TTL, не мігрувати активні мапінги без явної згоди клієнта.
Розподіл навантаження через consistent hashing + ваги.
Прозора політика для клієнта: Strict vs Resilient, керований rotate.
Моніторинг і регулярні failover‑тести.

Висновок

Пул із кількох операторів — це не лише «ще одна SIM‑карта», а інженерний підхід до SLA. Найкращий результат дає комбінація: правильні health‑checks, session‑aware розподіл, чітка політика sticky‑сесій і дисципліна тестів. Тоді “failover проксі” працює передбачувано, а “мобільні проксі Україна” стають продуктом, який витримує реальні збої мережі, а не лише ідеальні умови лабораторії.

Особливості мобільних мереж: CGNAT, IPv6 і «липкі» NAT-таймаути

У мобільному інтернеті ви майже завжди працюєте з CGNAT і коротшими таймаутами таблиці з’єднань. Це впливає на довгі “idle” сесії: навіть без failover вони можуть обриватися, якщо немає трафіку. Тому для клієнтів з довгими паузами варто документувати вимогу “keep-alive” (регулярний запит/пінг) або робити серверний keep-alive на рівні проксі.

Окремий нюанс — IPv6. Частина операторів охоче роздає IPv6 /64, частина — ні; у частини клієнтські інструменти або цільові сервіси поводяться з IPv6 інакше (гео, антибот, логіка “new device”). Якщо ви продаєте multi-carrier proxy, корисно мати режим “IPv4 only / IPv6 prefer / dual-stack” і фіксувати це в профілі сесії.

Ще одна типова причина «псевдо‑падінь» — коли лінк формально UP, але пакетна втрата або jitter роблять TLS нестабільним. Тому стан DEGRADED потрібен навіть тоді, коли інтерфейс не впав: у цьому стані ви не роздаєте нові sticky‑сесії на канал, але даєте йому шанс “вилікуватися” без жорсткого відключення.

Як підбирати операторів і SIM-профілі для пулу “мобільні проксі Україна”

Для України (і сусідніх ринків) на практиці працює правило: беріть 2 «масових» оператори з найкращим покриттям і один альтернативний (інша магістраль/інша поведінка мережі). Далі перевіряйте не рекламну швидкість, а стабільність: час до першого байта, відсоток timeouts, поведінку при нічних/денних піках, частоту зміни IP, наявність “глухих” портів.

Для проксі‑ферм важлива і «побутова» сторона: чи є обмеження на роздачу інтернету (tethering), чи не ріже оператор тривалі TCP‑потоки, як реагує на великі об’єми трафіку. Інколи дешевший тариф дає гірший SLA, і тоді економія з’їдається простоями. У пулі з кількох операторів ви можете винести «важкі» задачі (наприклад, парсинг) на стабільніші SIM‑профілі, а менш критичні — на дешевші.