Петли отключений WebSocket: как починить real‑time‑функции после запуска

Почему функции реального времени ломаются после запуска

«Реальное время» обычно означает, что экран обновляется без перезагрузки. Сообщения чата появляются мгновенно, видимость присутствия показывает, кто онлайн, дашборды обновляются, а оповещения всплывают в момент изменения состояния.

Эти функции могут идеально выглядеть в демонстрации, но развалиться после запуска, потому что продакшен ведёт себя иначе. Больше пользователей — больше одновременных подключений. Между браузером и сервером может стоять прокси или балансировщик. Токены истекают. Телефоны меняют сети, засыпают и просыпаются. Любая из этих причин может превратить стабильное соединение в петлю отключений и переподключений.

Для пользователя петля отключений WebSocket ощущается как «всё работает секундку, потом ломается». Сообщения приходят с задержкой или не приходят вовсе. UI мигнёт «reconnecting…» снова и снова. Присутствие мерцает. Дашборды замерзают, потом скачут. Иногда появляются дублировки, потому что клиент повторно отправляет после переподключения.

Что меняется после запуска

Несколько предсказуемых сдвигов доводят сокеты до предела: больше одновременных подключений, чем вы тестировали локально; прокси, которые таймаутят «неактивные» соединения; WebSocket‑аутентификация, которая ломается при обновлении токенов; мобильные разрывы сети, которые провоцируют агрессивные переподключения; и несколько инстансов сервера без общего состояния (или без sticky‑сессий, если вы полагаетесь на in‑memory state).

Надёжность сокетов — это не «никогда не отключаться». Отключения будут. Надёжность — это когда приложение быстро и безопасно восстанавливается и не теряет важные события. Пропустить индикатор набирания — не страшно. Пропустить «сообщение отправлено», статус заказа или состояние оплаты — уже серьёзно.

Найдите паттерн, прежде чем менять что‑то

Когда real‑time ломается после запуска, самый быстрый путь потратить время — «править» код вслепую. Начните с чёткого описания петли, чтобы вы могли предсказать следующее отключение.

Назовите симптом так, как вы его видите. «Плохо работает» скрывает подсказки. «Переподключается каждые 6 секунд и дублирует уведомления» — это то, что можно проследить.

Прежде чем менять настройки, ответьте на несколько вопросов:

• Какие клиенты затронуты (веб, iOS, Android, один браузер)?
• В каком окружении (локально, staging, только production)?
• Это затрагивает всех или конкретные аккаунты?
• Проявляется ли проблема в пиковые часы или сразу после деплоя?

Потом соберите доказательства во время события. Короткий снимок состояния лучше часов догадок. Как минимум — соберите метки времени (клиент и сервер), идентификатор пользователя или сессии, генерируемый вами per‑connection ID, код закрытия и причину (если есть), и несколько последних событий перед обрывом (connect, auth, subscribe, ping/pong).

Чтобы отделить серверные отключения от клиентских обрывов, сравните таймлайны. Если клиент показывает код 1006 (abnormal closure), а сервер не логирует корректное закрытие — подозревайте сеть, таймауты прокси или засыпание приложения. Если сервер закрывает сразу после «auth» или «subscribe» — вероятно ваша логика (плохой токен, отсутствующие права, исключение).

Практический трюк: попробуйте воспроизвести с одним пользователем в одной вкладке сначала. Если не получается — триггер, возможно, связан с нагрузкой.

Пошагово: как дебажить петлю отключений

Когда вы видите петлю отключений, не спешите менять таймауты. Сделайте петлю видимой: что произошло прямо перед падением сокета и кто планирует переподключение.

Начните с простых логов вокруг жизненного цикла сокета. Вам нужна понятная история от начала до конца: connect, auth, подписка, поток сообщений, потом причина закрытия. Включайте метки времени и короткий connection ID, чтобы множественные вкладки не смешивались.

Логируйте базовые события в порядке: connect started/open, auth отправлен и success/failure, subscribe отправлен и подтверждён, close/error (код и причина), и планирование переподключения (и кем оно инициировано).

Затем воспроизведите с минимальной конфигурацией: один пользователь, одна вкладка, без фоновых задач. Как только поведение повторяется стабильно, добавляйте сложность шаг за шагом (вторая вкладка, второй пользователь, больший объем сообщений). Так вы поймёте, триггер это нагрузки, конкуренции или конкретной подписки.

Дальше — проверьте коды закрытия и ошибки. Закрытия по политике часто указывают на проблемы с аутентификацией или origin‑правилами. Таймауты обычно указывают на heartbeat, прокси или занятость сервера. Аномальные закрытия часто означают крах или исчезновение сети без корректного закрытия.

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

Наконец, протестируйте с другой сети (мобильный хот‑спот vs офисный Wi‑Fi). Если проблема только в одной сети — фокусируйтесь на прокси, VPN, captive portal или агрессивных таймаутах неактивности.

Аутентификация на сокетах: где обычно ошибаются

Многие «сетевые» баги на самом деле — баги аутентификации. Приложение загружается, API‑вызовы проходят, а вот live‑функция зацикливается на переподключениях.

Три распространённые схемы аутентификации

Большинство приложений аутентифицируют сокеты одним из трёх способов: переиспользуют cookie‑сессию, отправляют bearer‑токен в заголовке при подключении, или сначала получают короткоживущий одноразовый «socket token» по HTTPS. Все рабочие, но у каждого есть типичные точки отказа.

Классический рассоглас: обычные HTTP‑запросы аутентифицированы, а WebSocket‑хэндшейк — нет. Cookies могут отправляться к API, но блокироваться для сокета из‑за cross‑origin правил. Или сервер ожидает заголовок Authorization, а клиентская библиотека умеет передавать токен только через query param или subprotocol.

Частые сбои после запуска:

• Cookies не уходят из‑за настроек SameSite, Secure или домена (работает на localhost, ломается на реальном домене).
• Сокет подключается раньше, чем сессия готова.
• Сокет держит устаревший access token после его обновления и постоянно кикается.
• Сервер закрывает соединение как «unauthorized», а клиент мгновенно переподключается — получается громкий спам.

Обрабатывайте отказ в аутентификации иначе, чем сетевые сбои

Относитесь к ошибкам auth иначе, чем к флакy сети. Если сервер закрывает с кодом или сообщением, связанным с аутентификацией, остановите петлю переподключений и сначала восстановите сессию. Обновите токен (или попросите войти), затем откройте новый сокет с новыми учётными данными.

Если нужно ретраить — используйте backoff (1s, 2s, 5s, 10s) и добавьте jitter, чтобы множество клиентов не переподключились одновременно.

Распространённый сценарий: дашборд работает час, токен обновился, но сокет продолжает слать старый токен и получает закрытие каждые несколько секунд. Решение не в «больше попыток», а в перезапуске сокета при смене токена.

Heartbeat, таймауты и логика переподключения

Многое сводится к простому: соединение простаивает, и что‑то посередине его убивает. Это может быть ваш сервер, прокси/балансировщик, CDN, отельный Wi‑Fi или телефон, который приостанавливает фоновые активности.

Обычное решение — heartbeat плюс адекватная логика переподключения. Heartbeat может быть ping/pong (лучше, если библиотека это поддерживает) или мини‑сообщение уровня приложения. Важно иметь достаточно трафика, чтобы промежуточные узлы не пометили соединение как неактивное.

Будьте консервативны в таймингах. Многие прокси закрывают неактивные соединения примерно через 30–60 секунд. Частая стартовая конфигурация — heartbeat каждые 15–25 секунд и тайм‑аут у клиента после 2–3 пропущенных heartbeat. Слишком агрессивно — расход батареи и трафика на мобильных; слишком медленно — тихо умирает.

Логика переподключения — вторая половина решения. Мгновенные reconnect могут создать шторм, особенно после деплоя или кратковременного падения. Используйте jittered exponential backoff с верхним лимитом, сбрасывайте backoff только после того, как соединение стабильно проработало короткое окно, и делайте переподключение идемпотентным: проходите аутентификацию и подписки, но не дублируйте подписки.

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

Прокси и балансировщики: скрытые причины отключений

Если real‑time работал локально, но флапает в продакшене, проверьте сетевой путь, прежде чем переписывать код сокетов. Reverse proxy, CDN и балансировщики могут закрывать idle‑соединения, переключать инстансы или убирать заголовки.

Что прокси меняют в WebSocket

WebSocket начинается как HTTP‑запрос и затем апгрейдится. Всё, что стоит перед вашим приложением, должно поддерживать этот апгрейд и держать соединение открытым. Многие конфигурации также вводят idle‑таймауты или максимальный возраст соединения. Если приложение шлёт данные только при клике пользователя, соединение выглядит неактивным и может быть разорвано.

Sticky‑сессии — ещё одна ловушка. Если важное состояние в памяти (подписки, комнаты, контекст пользователя), и балансировщик отправляет переподключение на другой инстанс, пользователь «подключается», но пропускает события или не проходит проверки. Общее состояние (Redis, БД, message broker) снижает потребность в stickiness.

TLS‑терминация и сюрпризы с заголовками auth

Когда TLS завершается на прокси, ваше приложение может видеть запрос как HTTP, если не прокинуты корректные forwarded‑заголовки. Это ломает проверки вроде «только secure cookies» или строгие origin‑правила. Некоторые прокси также удаляют или переименовывают заголовки, что ломает аутентификацию по токену.

Чтобы понять, кто закрывает соединение, сравните коды закрытия с обеих сторон, ищите в логах прокси сообщения вроде «upstream timeout» или «idle timeout», временно увеличьте idle‑таймауты, чтобы проверить, прекращается ли проблема, и убедитесь, что заголовки апгрейда и forwarded реально доходят до приложения.

Масштабирование real‑time без потери событий

Real‑time часто работает в staging, потому что там один сервер. После запуска появляется второй инстанс (или платформа начинает перемещать трафик), и сообщения теряются. Broadcastы доходят только до пользователей на той же машине. Комнаты и presence становятся непоследовательными. Переподключения могут попасть на сервер, который не знает состояния клиента.

Первое правило: не храните важное состояние сокета только в памяти. Это включает статус подписок, отображение user→socket, presence и последний принятый ID события. In‑memory state исчезает при деплое и отличается на разных серверах.

Большинство приложений используют один из паттернов: общий pub/sub, чтобы любой сервер мог публиковать, а все — доставлять; выделенный real‑time сервис, который держит соединения, тогда как API‑серверы остаются стателес; или очередь для событий, которые нельзя потерять, чтобы их можно было безопасно ретраить.

Дубликаты появляются при переподключениях. Используйте event ID (или sequence number) на канал и ставьте клиенту возможность отправить «last received». На сервере делайте обработчики идемпотентными, чтобы повторная обработка не создавала дублей или не дублировала платёж.

Деплои тоже требуют плана. Если вы рестартуете сервера без предупреждения, вы форсируете массовые переподключения и гонки. Добавьте drain‑шаг: перестаньте принимать новые соединения на старом инстансе, дайте текущим завершиться, затем завершайте процесс.

Резервы, которые сохраняют работоспособность приложения

Real‑time хорош, пока он работает. Когда пользователи попадают в петли отключений, нужно два результата: стабильные сокеты и приложение, которое работает, когда сокеты нестабильны.

WebSocket идеален для двунаправленного взаимодействия (чат, мультиплеер, курсоры). Если клиент в основном получает обновления (статусы, уведомления, дашборды), Server‑Sent Events (SSE) проще и часто надежнее, потому что это стандартный HTTP‑поток и он обычно лучше проходит через прокси.

Практический fallback — контролируемая деградация: пробуйте WebSocket, переключайтесь на SSE, если сокет не открылся или падает слишком часто, переходите к короткому polling при необходимости, и если переподключение всё равно не удаётся, переводите приложение в ограниченный режим (только для чтения или «отправить позже»), пока вы тихо ретраите.

Держите UI честным. Показывайте состояние соединения (Connected, Reconnecting, Offline) и время последнего обновления. Кнопка «Retry now» помогает при смене сети.

На сервере делайте стримы так, чтобы клиент мог продолжить после переподключения. Отправляйте события с ID или метками времени и разрешайте запрос «всё с X». Для SSE используйте Last‑Event‑ID. Для WebSocket — resume cursor или токен при подключении.

Частые ошибки, которые делают сокеты хрупкими

Не каждое отключение — баг. Мобильные сети рвутся. Лэптопы засыпают. Браузеры приостанавливают фоновые вкладки. Хрупкость возникает, когда приложение трактует нормальные отключения как катастрофу и переподключается так агрессивно, что создаёт самоиндуцированный outage.

Одна предотвратимая ошибка безопасности — хранение секретов в URL. Query string попадает в логи, аналитику, отчёты об ошибках и скриншоты. Если ваш socket‑token в URL, считайте, что он утечёт. Легко также нечаянно залогировать токены при дампе handshake‑данных во время отладки.

Локальная разработка может ввести в заблуждение. На localhost нет корпоративных прокси, балансировщика и политик таймаутов. В продакшене прокси могут закрывать idle‑сессии, убирать заголовки или блокировать апгрейд‑запросы.

Паттерны, которые обычно делают сокеты хрупкими:

• Циклы ретраев без backoff или jitter.
• Аутентификация в query string или логирование, которое случайно захватывает токены.
• Отсутствие лимитов на переподключения на сервере по пользователю/IP.
• Логика переподключения, которая бездумно ресабскрайбит и создаёт дублирующие слушатели.
• Пропуск тестов за прокси или балансировщиком.

Дублирующие подписки особенно коварны. После переподключения клиент может снова присоединиться к той же комнате или зарегистрировать тот же обработчик, в то время как сервер не убрал старый. Исправляйте это, делая подписки идемпотентными для соединения и отслеживая connection IDs, чтобы новый сокет мог чисто заменить старый.

Быстрая проверка перед релизом фикса

Прежде чем выкатывать изменение WebSocket, пройдитесь быстро по клиенту, серверу и инфраструктуре. Большинство петель отключений — не одна ошибка. Это две‑три мелочи, которые выплывают вместе.

Клиентские проверки

Клиент должен оставаться спокойным при ошибках. Используйте reconnect backoff с jitter и лимитом, показывайте состояние подключения в UI, добавьте resume‑логику (last event ID или версия), чтобы короткие обрывы не теряли данные, дедуплицируйте события, чтобы reconnect не применял обновления дважды, и корректно закрывайте сокеты при logout или смене аккаунта.

Сервер и инфраструктура

Делайте отключения понятными. Если сервер закрывает соединение — делайте это по явной причине и записывайте её в одну строку лога. Используйте понятные коды закрытия, проверяйте auth при подключении и по важным сообщениям, настраивайте heartbeat и таймауты так, чтобы здоровые клиенты не кикались, ставьте лимиты на подключения по user/IP и проверяйте настройки прокси/балансировщика WebSocket (idle timeout, необходимость stickiness).

Правило: если вы не можете объяснить одно отключение одной строкой в логе — вы не готовы к релизу.

Быстрые тесты, которые ловят регрессии

Прогоните сценарии, которые часто воспроизводят петли: один пользователь с множеством вкладок при логине/логауте, много пользователей, подключающихся одновременно (даже небольшой нагрузочный тест), деплой при подключённых пользователях и наблюдение за поведением переподключений, симуляция флаки сети (переключение Wi‑Fi/сотовой, сон ноутбука) чтобы убедиться, что приложение восстанавливается.

Готовность: соединения держатся предсказуемо, переподключения замедляются вместо ускорения, и при обрыве вы можете указать на одну понятную причину.

Реалистичный пример и дальнейшие шаги

Основатель запускает live‑дашборд продаж. В staging всё идеально. В день запуска приходят заявки в поддержку: страница мигнёт «Reconnecting…» каждые несколько секунд, и некоторые пользователи вообще не получают live‑обновлений.

Первая подсказка в логах сервера: многие соединения заканчиваются сразу после истечения access token. На клиенте приложение переподключается быстро, но продолжает использовать тот же просроченный токен и снова кикается. Исправление — делать handshake сокета с актуальным токеном (или выдавать короткоживущий socket token) и форсировать обновление перед переподключением.

Затем появляется второй паттерн: пользователи с открытой страницей отключаются почти ровно через 60 секунд. Это указывает на таймаут инфраструктуры. Балансировщик убивал idle‑соединения, а приложение не отправляло heartbeat. Пинг каждые 25 секунд плюс разумный idle‑таймаут останавливает флап.

Документируйте, что вы поменяли, чтобы проблема не вернулась: ожидаемые коды закрытия, правила токенов для сокетов (откуда берётся, когда обновляется, что делать при 401), настройки heartbeat (интервал пинга, pong‑таймаут) и таймаут прокси, а также правила переподключения (тайминги backoff, максимальные попытки, когда остановиться и показать кнопку «Обновить»).

Иногда патч медленнее рефактора. Если ваш хэндлер сокета смешивает connection/auth, бизнес‑логику, запись в базу и проверки прав в одном месте, мелкие изменения создают новые точки отказа. Разделите ответственности: слой для подключения и auth, слой для событий, слой для данных.

Если вы имеете дело с AI‑сгенерированным прототипом, который работал в демо, но ломается в продакшене, FixMyMess (fixmymess.ai) может помочь проследить поток сокета, починить auth и логику переподключений и укрепить приложение под реальный трафик после бесплатного аудита кода.