Суть проблемы: IP не меняется, а соединение обрывается
В мобильном интернете и мобильных прокси легко перепутать две разные вещи: стабильность IP‑адреса и непрерывность конкретного соединения. Sticky‑IP обычно означает, что оператор какое‑то время держит для устройства один и тот же публичный IP (или один и тот же выходной NAT‑пул). Но это не гарантирует, что TCP/QUIC‑соединение будет жить бесконечно.
Самая частая причина «разрывов без смены IP» — handover (передача абонента между сотами/базовыми станциями) и процессы, которые идут вместе с ним: переключение радиоресурсов, перенос контекста и смена пути пользовательских данных (user‑plane). В момент handover возможны короткая пауза и потери пакетов — и этого иногда достаточно, чтобы приложение, прокси или сервер закрыли соединение.
Что такое handover простыми словами
Handover — это процедура, когда телефон/модем переходит из одной ячейки сети в другую, чтобы связь оставалась приемлемой при движении или изменении условий радиоэфира. В LTE (4G) базовая станция — eNodeB, в 5G — gNodeB. Переход может быть:
- внутри одного узла (частота/сектор),
- между базовыми станциями (inter‑eNB/inter‑gNB),
- между технологиями (4G↔5G и т.п.).
В LTE часто говорят про X2‑handover и S1‑handover — это способы организовать сигнализацию и «перенос» пользователя. Для практики важно одно: радио‑часть переключается, а ядро сети перенаправляет ваш трафик через новую соту. При этом IP‑адрес часто остается прежним, потому что он привязан к сессии в ядре (PDN/шлюз), а не к конкретной базовой станции.
В 5G SA (Standalone) непрерывность формализована через режимы Session and Service Continuity (SSC), которые описывают, сохраняются ли параметры привязки (включая IP) при мобильности и релокации функций user‑plane.
Почему «липкая» сессия рвется без смены IP
1) Пауза/потери пакетов, которые не выдерживает транспорт или приложение
Во время handover в LTE/5G возможен interruption пользовательских данных: пока сеть переносит контекст и переключает маршрут/туннели, часть пакетов теряется или задерживается. Для обычного серфинга это почти незаметно, а для длинных подключений (WebSocket, API‑стрим, удаленный доступ, долгие TLS‑сессии) — критично.
2) Меняется путь данных в ядре, а stateful‑узлы реагируют «жестко»
В LTE при межсотовом переходе выполняется path switch: ядро перенаправляет user‑plane на новую eNodeB. На практике это может сопровождаться буферизацией, очередями и редкими «провалами», из‑за которых тайм‑ауты в прокси/балансере/сервере срабатывают быстрее, чем успевает восстановиться поток.
Отдельный слой риска — CGNAT. Даже при том же публичном IP оператор может изменить NAT‑отображение (например, исходный порт), и системы, которые держат состояние по 5‑tuple, могут трактовать это как новую сессию.
3) Handover failure или RLF (radio link failure)
Не каждый handover проходит идеально. Если сигнал проседает, есть помехи или устройство быстро «прыгает» между соседними сотами (ping‑pong), может случиться handover failure или radio link failure (RLF). Тогда соединение восстанавливается через повторные процедуры — и для приложений это выглядит как полный разрыв.
4) 4G↔5G (NSA/SA) и Dual Connectivity добавляют сложность
В 5G NSA 5G‑радио часто работает в связке с LTE, поэтому мобильность может включать сразу несколько переключений (LTE‑handover + изменения NR‑контекста). В 5G SA мобильность проще с точки зрения радиосоставляющей, но остаются релокации user‑plane и SSC‑режимы.
5) В прокси «липкость» часто привязана к коннекту или времени, а не только к IP
Многие прокси реализуют sticky как «не менять upstream N минут» или «держать пользователя на одном модеме». Но если TCP‑коннект умер, новый коннект может получить другой порт/маршрут/состояние на балансере. Поэтому важно различать:
- sticky‑IP — про адресацию и привязку в ядре/NAT,
- sticky‑session — про живучесть конкретного потока.
Как проверить, что причина именно в handover
- IP до/после одинаковый, но в логах есть timeout/RST/reconnect.
- Есть короткий провал ping/packet loss в момент обрыва.
- Меняются параметры радио: Cell ID/PCI/eNB ID/TAC, бенд, SINR/RSRP.
- Нет «длинного» восстановления 10–60 секунд, но коннекты падают.
Что делать провайдеру мобильных прокси
- Тюнинг тайм‑аутов и keepalive: TCP keepalive, heartbeat для WebSocket, разумные upstream/read timeouts.
- Sticky не только по TCP: привязка пользователя к модему/маршруту, чтобы реконнект возвращал тот же канал.
- Мягкий reconnect: токены/логин вместо привязки к адресу/порту; ретраи с backoff; сохранение прогресса в парсерах.
- Мониторинг: хранить RSRP/RSRQ/SINR, Cell ID и события разрывов, чтобы отличать handover от RLF и от реального detach.
Что может сделать пользователь
- Не ставить слишком агрессивные тайм‑ауты (1–2 с) для мобильного канала.
- Держать легкий keep‑alive раз в 20–40 с, чтобы NAT‑таблицы не «засыпали».
- Использовать клиенты с корректными ретраями и идемпотентностью запросов.
- Для долгих сессий рассмотреть туннель (например, WireGuard/VPN) с авто‑восстановлением: handover не исчезнет, но реконнект станет более прозрачным.
Миф: «Если IP не меняется — значит сеть ничего не переключала»
В 4G/5G IP — лишь верхний уровень. Ниже работают туннели user‑plane и множество stateful‑узлов. При мобильности могут меняться точки терминации туннелей и маршруты, а таймеры NAT/балансеров способны «убить» коннект даже при том же IP.
Мини‑FAQ
Можно ли сделать «как у проводного»? Полностью — нет: радио всегда дает риск микропровалов. На практике помогает сочетание нормального сигнала + правильные тайм‑ауты + грамотный reconnect.
Почему чаще рвется на пиках? Больше задержек/потерь в сети и больше очередей/лимитов на прокси и у сервера — и короткая пауза превращается в тайм‑аут.
Вывод
Sticky‑IP в мобильном интернете не равен «вечной» сессии. Handover между базовыми станциями может дать короткое прерывание или RLF, и этого достаточно, чтобы TCP/QUIC‑соединение оборвалось без смены IP. Устойчивость достигается инженерно: тайм‑ауты, keepalive, привязка к маршруту/модему и корректный reconnect.