Ротация IP без разрыва сессии: технические ограничения и обходные пути

Суть проблемы

IP-адрес меняется — TCP-соединение рвётся. Это аксиома. Любой прокси, VPN или NAT переподключает вас с новым IP, и старый сокет умирает. Сервер видит: пришёл пакет с адреса A, через секунду — с адреса B. Для TCP это разные сессии. Для HTTP/1.1 — разные запросы.

Но есть нюансы. Не все протоколы одинаково хрупки. И не все задачи требуют держать одно соединение вечно.

Почему TCP не прощает смену IP

TCP — stateful протокол. Он хранит в памяти: `src_ip:src_port — dst_ip:dst_port`. Если меняется src_ip — это уже другой поток. Сервер отправляет RST или просто игнорирует пакеты.

Пример: вы крутите прокси каждые 30 секунд. На 25-й секунде отправляете POST с телом 10 МБ. На 26-й секунде прокси меняет IP. Сервер получает половину данных, видит новый IP — и закрывает соединение. Запрос улетает в пустоту.

Задержка на переотправку: минимум RTT + время на повторный хендшейк. Для Европы — 30-50 мс. Для Азии — 150-200 мс. Если у вас 5000 запросов в минуту, каждый второй теряется — вы тонете в retry.

HTTP/1.1 и keep-alive: ложная надежда

Keep-alive держит TCP-сокет открытым для нескольких HTTP-запросов. Но только пока IP не меняется. Сменили адрес — сокет умирает. Браузер или curl создают новое соединение.

Проверка: откройте страницу через прокси, включите ротацию каждые 10 секунд. В Chromium откройте `chrome://net-export/`. Вы увидите: `SOCKET_POOL_CLOSE_ON_IP_CHANGE`. Браузер сам рвёт все пулы при смене IP. Это не баг — это защита от утечки данных между сессиями.

QUIC и HTTP/3: свет в конце туннеля

QUIC работает поверх UDP. У него нет жёсткой привязки к IP-адресу. Внутри — Connection ID. Меняйте IP сколько угодно — QUIC переживёт.

Как это выглядит: клиент шлёт пакет с новым src_ip, но с тем же Connection ID. Сервер видит: "А, это старый друг, просто сменил адрес". Продолжаем обмен.

Но есть подвох. QUIC поддерживают не все серверы. Cloudflare — да. Nginx с модулем `ngx_http_v3_module` — да, но это экспериментальная сборка. Старые балансировщики — нет.

WebSocket и ротация: боль

WebSocket держит долгоживущее TCP-соединение. Если IP меняется — WebSocket рвётся. Клиент получает `1006` (Abnormal Closure). Переподключение требует нового хендшейка.

Решение: на клиенте — авто-реконнект с экспоненциальной задержкой. На сервере — идемпотентность сообщений. Если сообщение ушло, но подтверждения нет — шлём снова.

Пример: биржевой стример. Каждые 100 мс — котировка. Разрыв на 2 секунды — потеря 20 тиков. Не критично для анализа, критично для HFT.

Смена IP через NAT: почти без разрыва

NAT не меняет IP на клиенте. Он меняет внешний адрес на шлюзе. Если вы сидите за NAT, смена внешнего IP может пройти незаметно для TCP-соединений — при условии, что шлюз не перезагружает таблицу трансляции.

Но это хрупко. NAT-таблица живёт 30-60 секунд для UDP, 5-15 минут для TCP. Если шлюз меняет IP, он может сбросить все таблицы. Тогда — RST.

Множественные интерфейсы: MPTCP

Multipath TCP (MPTCP) — расширение протокола, позволяющее держать одно TCP-соединение через несколько IP-адресов. Клиент имеет IP A и IP B. Сервер видит оба. Если A умирает — трафик идёт через B.

Реализация: ядро Linux 5.6+ с опцией `mptcp`. На сервере — тоже MPTCP. На практике — редкость. Большинство CDN и прокси не поддерживают.

Пример: мобильное приложение. Телефон переключается с Wi-Fi на 4G. MPTCP сохраняет сессию без разрыва. Но только если и сервер, и клиент настроены. Если сервер — обычный nginx — соединение рвётся.

Практические обходы: без прокси

Если вы не контролируете сеть, ротация IP без разрыва — миф. Но можно минимизировать потери.

**Подход 1: HTTP/2 multiplexing.** Одно TCP-соединение — много потоков. При смене IP все потоки падают. Быстро пересоздаём — и retry.

**Подход 2: UDP-туннель.** Заворачиваете TCP в UDP (WireGuard, OpenVPN). UDP терпит смену IP. При смене адреса туннель переживает, TCP внутри — тоже.

Проверка: WireGuard. Меняете endpoint на лету — `wg set wg0 peer ... endpoint new.ip:51820`. Соединение не рвётся. TCP-сессии внутри живут.

Кейс: парсинг с ротацией через QUIC

Проблема: парсер собирает данные с сайта, который банит по IP после 50 запросов. Ротация каждые 10 запросов. На HTTP/1.1 — 30% запросов уходят в retry из-за разрыва keep-alive.

Решение: перешли на HTTP/3 (QUIC). Клиент — curl 8.0+ с `--http3`. Сервер Cloudflare — поддерживает. Ротация через смену исходящего интерфейса.

Результат: retry упали до 2%. Сессии не рвутся. Время на один запрос — 120 мс вместо 180 мс.

Кейс: биржевой терминал через MPTCP

Проблема: трейдер использует два канала — основной (оптика) и резервный (4G). При падении оптики — разрыв TCP, потеря ордеров.

Решение: настроили MPTCP на обоих концах. Ядро 6.2, модуль `mptcp`. Сервер — Linux с MPTCP.

Результат: переключение каналов за 50 мс. Ни одного разрыва. Ордера не теряются.

Кейс: WebSocket для чата с авто-реконнектом

Проблема: чат-бот под прокси с ротацией каждые 5 минут. WebSocket рвётся. Пользователи видят "disconnected".

Решение: на клиенте — реконнект с exponential backoff. На сервере — буферизация сообщений на 10 секунд. Клиент отправляет last_message_id при переподключении. Сервер досылает пропущенное.

Результат: пользователи не замечают разрыва. Максимальная задержка — 2 секунды.

Сравнение протоколов для ротации IP

| Протокол | Разрыв при смене IP | Задержка восстановления | Поддержка на серверах |

|----------|---------------------|-------------------------|----------------------|

| TCP/HTTP/1.1 | Да | 1-2 RTT | 99% |

| HTTP/2 | Да | 1-2 RTT | 80% |

| HTTP/3 (QUIC) | Нет | 0 | 30% |

| WebSocket | Да | 2-3 RTT + хендшейк | 90% |

| MPTCP | Нет | 0-50 мс | 5% |

| WireGuard (UDP) | Нет | 0-1 пакет | 100% (клиент) |

Когда ротация без разрыва не нужна

Если вы парсите статические страницы — плевать на разрывы. retry занимает 50 мс. Потеря 1% запросов не критична.

Если вы стримите видео — буфер на 5-10 секунд спасает. Разрыв TCP — просто пауза.

Если вы работаете с API банка — не ротируйте IP вообще. Используйте статический адрес. Банки не любят смену.

Выводы

Ротация IP без разрыва сессии — технически возможна. Но только на QUIC или MPTCP. Всё остальное — компромиссы.

Для большинства задач достаточно авто-реконнекта. Для критичных — стройте инфраструктуру на QUIC. Для экзотики — MPTCP.

Если вы используете [lexic.ml](https://lexic.ml) для парсинга — настройте HTTP/3 на клиенте. Это снизит потери. Но помните: сервер тоже должен поддерживать QUIC.

И последнее: не пытайтесь обмануть физику. TCP — про надежность, а не про мобильность. QUIC — про мобильность, но не про совместимость. Выбирайте под задачу.