Если WebSocket работает по домашнему Wi-Fi, но не подключается или быстро обрывается через мобильного оператора, нужно проверить защищенный WSS, порт, IPv6, TLS/SNI, reverse proxy и устойчивость к NAT timeout. Обычная сеть не гарантирует вечное TCP-соединение.

Для публичного приложения используйте WSS на порту 443 с валидным сертификатом и корректным Upgrade через proxy. Клиент должен иметь ping/pong или heartbeat, ограниченный reconnect с backoff, повторную авторизацию и обработку смены сети без дублей сообщений.

Что проверить в первую очередь

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

  • Сравните URL, DNS A/AAAA, сертификат и порт в Wi-Fi и мобильной сети.
  • Снимите код/причину close и время до обрыва.
  • Проверьте proxy Upgrade/Connection, HTTP version и idle timeout.
  • Уточните поведение при смене LTE↔Wi-Fi, background и возобновлении приложения.

Почему возникает проблема

Внешний симптом обычно появляется на границе нескольких компонентов: интерфейса, backend, базы, фоновой очереди или внешнего сервиса. Поэтому важно найти первое место, где состояние становится неверным, а не исправлять последнее сообщение об ошибке.

  • Используется ws:// или нестандартный порт, фильтруемый сетью/прокси.
  • AAAA ведет на сервер, где WebSocket не настроен.
  • Reverse proxy не передает Upgrade или закрывает idle-соединение.
  • NAT оператора удаляет неактивную запись без heartbeat.
  • Токен истекает, а reconnect повторяет старые credentials.

Пошаговая диагностика

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

  • Проверьте WSS handshake через мобильную сеть и лог proxy/backend по request id.
  • Сравните IPv4/IPv6 и SNI-сертификат.
  • Отправляйте тестовый ping с интервалом меньше наблюдаемого idle timeout.
  • Сымитируйте потерю сети и проверьте close/reconnect state machine.
  • Сравните WebSocket с fallback transport только для локализации, не как скрытое исправление.

Устойчивое соединение в меняющейся сети

Мобильный клиент меняет IP, radio state и маршрут. Приложение должно считать WebSocket восстанавливаемым каналом, а не вечной сессией.

  • WSS/443 повышает совместимость и защищает канал.
  • Heartbeat подтверждает живость приложения, но не должен создавать лишнюю нагрузку.
  • Reconnect использует exponential backoff с jitter и ограничением попыток.
  • После reconnect клиент восстанавливает подписки и запрашивает пропущенные данные по cursor/sequence.
  • Сообщения имеют ID, чтобы повтор после неопределенного разрыва не создавал дубль.

Как исправить проблему

Исправление лучше разбить на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовую обработку данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем.

  • Исправьте DNS/IPv6, TLS и WSS endpoint на 443.
  • Настройте proxy Upgrade и согласованные read/send timeouts.
  • Добавьте heartbeat, close reason и reconnect state machine.
  • Обновляйте/перевыпускайте токен перед новым handshake.
  • Реализуйте resume по sequence или безопасную повторную синхронизацию.

Безопасный порядок внедрения

  • Сохраните затрагиваемые данные, конфигурацию и текущие журналы, заранее проверив способ отката.
  • Повторите проблему на тестовом объекте без реальных списаний, рассылок и изменений клиентских данных.
  • Внесите одно логическое изменение и зафиксируйте его в системе контроля версий или журнале работ.
  • Не отключайте авторизацию, валидацию, шифрование и другие защитные механизмы ради быстрого исчезновения ошибки.
  • После выкладки контролируйте логи, метрики и полный пользовательский сценарий, а не только один успешный запрос.

Как проверить результат

Разовый успешный тест недостаточен. Повторите операцию, проверьте крайние значения, параллельные действия и восстановление после перезапуска или временного сбоя. Для важного сценария сохраните автоматический тест либо короткий регрессионный чек-лист.

  • Подключение работает через нескольких операторов, IPv4/IPv6 и Wi-Fi.
  • Idle-сессия живет ожидаемое время без чрезмерных ping.
  • Смена сети и background завершаются восстановлением подписок.
  • Пропущенные/повторные сообщения не нарушают состояние приложения.

Типичные ошибки при исправлении

  • Бесконечно reconnect без backoff и создавать шторм.
  • Увеличивать proxy timeout, не добавляя heartbeat/resume.
  • Отключать проверку TLS для «совместимости».
  • Считать соединение успешным только по open без проверки обмена.

Как предотвратить повторение

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

  • Мониторьте handshake failures, close codes, reconnect rate и latency по типу сети.
  • Тестируйте network switching и background в мобильных e2e-сценариях.
  • Поддерживайте message sequence/idempotency.
  • Проверяйте A/AAAA и сертификаты после изменений инфраструктуры.

Что подготовить для технического разбора

  • Описание ожидаемого и фактического поведения, а также точную последовательность действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде или способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Почему помогает порт 443?

Мобильные сети и корпоративные proxy обычно лучше пропускают стандартный HTTPS/WSS на 443, но это не исправляет неверный Upgrade, TLS или reconnect.

Нужен ли ping каждую секунду?

Нет. Слишком частый heartbeat расходует батарею и ресурсы. Интервал выбирают по proxy/NAT timeout и требованиям к обнаружению разрыва.

Когда нужна помощь специалиста

Если WebSocket падает только в мобильной сети, я могу проверить DNS, IPv6, WSS, proxy и клиентский reconnect, а также добавить безопасное восстановление пропущенных сообщений.