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

2026-02-07

Как собрать пул мобильных прокси из 2–3 операторов и построить резервирование: проверки канала, маршрутизация, sticky-сессии и правила переключения без хаоса.

Зачем нужен пул из нескольких операторов

Если вы строите или продаёте мобильные прокси, «один оператор» почти всегда превращается в одну точку отказа. В мобильных сетях бывают локальные проблемы: деградирует конкретная базовая станция, растёт задержка и потери, проваливается IPv4, появляются массовые таймауты. Плюс плановые работы и перегруз соты в часы пик. Это напрямую бьёт по SLA и по клиентам, которые рассчитывают на стабильный доступ к прокси.

Пул из 2–3 операторов даёт реальную устойчивость:

Разное покрытие: в одном районе лучше оператор А, в другом — В.
Запас по ёмкости: распределяете нагрузку и снижаете риск throttling.
Меньше простоев: отказ одного оператора не останавливает весь пул.
Гибкость политики: CGNAT, IPv6, таймауты NAT и «характер» сети у операторов отличается — это влияет на парсинг, арбитраж, SMM и QA‑проверки.

Что именно «падает» при failover

Частая ошибка — называть «сессией» всё подряд. На практике есть три уровня: (1) соединение клиента с вашим прокси‑ендпойнтом, (2) TCP/TLS‑соединение от прокси к целевому сайту, (3) логин‑сессия на уровне cookies/токенов. При переключении оператора почти всегда меняется публичный IP и состояние NAT — активные TCP‑потоки обрываются. Отсюда ощущение «всё упало».

Поэтому сначала ответьте себе: вы хотите сохранить мобильный egress (чтобы цель видела IP оператора) или сохранить бесшовность для клиента (чтобы он не чувствовал аварии)? В большинстве коммерческих сценариев важно, чтобы клиентский доступ к прокси оставался стабильным, а поведение sticky‑сессий было предсказуемым.

4 модели резервирования

Модель 1. Cold failover: сменили маршрут — оборвали активные соединения

Самый простой вариант: основной WAN (оператор А) и резервный WAN (оператор B). Health‑check «красный» — переключили маршрут. Настраивается быстро, но почти гарантированно рвёт активные TCP/TLS, потому что меняется путь/адрес/таблица соединений.

Модель 2. Session-aware failover: не переносим активные sticky, спасаем новые

Наиболее рабочий подход для multi carrier proxy. Суть: существующие sticky‑сессии не «мигрируем» на другой оператор. Если модем умер — часть текущих сессий всё равно отвалится, но вы не усугубляете ситуацию хаотичным перераспределением. Зато новые подключения сразу назначаются на живой оператор. Так вы локализуете ущерб.

Модель 3. Tunnel-anchored failover: стабильный выход для клиента

Если вы «якорите» выход через туннель (VPS/edge), то внутри оверлея можно менять аплинк без заметного эффекта для клиента. Это типичный подход SD‑WAN/bonding: при потере одного WAN трафик переносится на другой с сохранением сессии внутри туннеля. Например, для SpeedFusion “Hot Failover” заявляется перенос трафика на другое соединение с сохранением сессий.

Но важно: если вы продаёте именно мобильный egress, туннель на VPS сделает выход датацентровым. Эта модель — про бесшовность для клиента, не про «мобильный IP до цели».

Модель 4. Multipath: MPTCP и выживание соединений при смене сети

Multipath TCP позволяет одной логической сессии использовать несколько путей и переживать отвал одного из них: соединение может продолжиться по оставшемуся пути. Это часто приводят как ключевую фишку MPTCP для мобильности и отказоустойчивости.

Практический нюанс: MPTCP нужно поддерживать с обеих сторон или терминировать на вашем шлюзе, поэтому в прокси‑фермах его обычно применяют внутри инфраструктуры (между edge и вашим сервером), а не «до любого сайта».

Как построить failover без «убийства» sticky‑сессий

1) Определите, что такое сессия в продукте

В мобильных прокси sticky‑сессия — это обычно не TCP‑соединение, а период, когда клиент хочет держать один выход: 5–30 минут, 2 часа или «пока не нажмёт rotate». Поэтому sticky привязывайте к модему/оператору по session id (в логине или токене) и держите TTL.

Правило: одна sticky‑сессия должна быть привязана к одному модему до конца TTL. Если модем умер — либо честно завершаете сессию (Strict), либо переводите её на другой оператор (Resilient) с изменением IP, если клиент это допускает.

2) Health-check должен быть не только ping

Link: есть ли IP/сеть, не в “no service”.
Network: RTT/loss до нескольких контрольных IP.
Application: DNS+HTTPS GET на ваш health endpoint + 1–2 независимых домена.

Для MikroTik популярна базовая техника с check-gateway и “recursive routes”, хотя простой check-gateway имеет ограничения и иногда требует более умных проверок.

3) При деградации: stop assigning, а не move everyone

Критично: как только оператор перешёл в DEGRADED/DOWN, перестаньте назначать на него новые sticky‑сессии. Но не пересаживайте уже назначенные сессии автоматически — это создаёт лавину переподключений. Потери будут ограничены активными пользователями на проблемном операторе.

4) Распределение: consistent hashing + веса

Чтобы при флапании не «перемешивать» весь пул, используйте consistent hashing (или фиксированную привязку user_id → оператор/модем). Тогда при выпадении оператора меняется только часть маппинга, а остальное остаётся стабильным. Веса учитывают реальную ёмкость и качество.

5) Прокси‑уровень: sticky в авторизации и управляемый rotate

Удобный паттерн — session id в логине (или токене). Прокси смотрит session id, находит привязанный модем и использует его для исходящих соединений. Rotate — смена session id или вызов вашего API.

Если вы строите upstream chaining (локальный прокси → родительский), заранее проверьте, как ваш софт ведёт себя со списками parent proxies и fallback. В 3proxy, например, в репозитории обсуждаются нюансы работы с несколькими parent proxies и include‑файлами, что может неожиданно ломать ожидаемый failover.

CGNAT, IPv6 и «тихие» проблемы

В мобильных сетях CGNAT и таймауты NAT часто короче, чем в фиксированных сетях. Длинные idle‑сессии могут обрываться и без аварии. Поэтому фиксируйте в документации необходимость keep‑alive (регулярный трафик) или делайте keep‑alive на стороне прокси.

По IPv6: часть операторов даёт стабильный dual‑stack, часть — нет; антибот и гео‑логика некоторых сервисов для IPv6 может отличаться. В multi‑carrier пуле полезно иметь режимы IPv4 only / IPv6 prefer / dual‑stack на уровне профиля сессии.

Если хочется «тот же WAN IP» при переключении

Обычно это упирается в BGP и согласование между провайдерами. На практике без участия ISP удержать один и тот же публичный WAN IP при переходе на другого оператора почти невозможно.

Короткий чек-лист

2–3 оператора, лучше разные локации/соты.
Health-check: link + network + application.
Состояния UP/DEGRADED/DOWN и cooldown после восстановления.
Sticky‑TTL, не мигрировать активные привязки без согласия клиента.
Consistent hashing + веса.
Два режима для клиентов: Strict и Resilient.
Мониторинг и регулярные тесты аварий.

Вывод

Пул из нескольких операторов — это инженерная страховка от реальных сбоев. Самое важное — не «переключиться любой ценой», а сделать поведение предсказуемым: здоровые каналы получают новые сессии, активные sticky не перемалываются, а клиент понимает, что произойдёт при аварии. Тогда failover прокси становится не обещанием, а работающим механизмом.