WebSocket в Docker обрывается ровно через 30 секунд: как найти слой таймаута. Практическая проверка: снять время и инициатора close или reset на границах браузер proxy приложение, сравнить один контролируемый idle-сеанс с разрешённым ping pong, выписать явные таймеры каждого слоя; не считать 30 секунд стандартным nginx и остановиться до.
Сначала зафиксируйте именно этот симптом
Соединение стабильно разрывается через 30 секунд простоя или обмена, а разработчик может без доказательств обвинить docker, поднять глобальные таймауты или опубликовать чувствительные логи. Точный запрос пользователя: как найти слой который обрывает websocket ровно через 30 секунд между браузером reverse proxy docker и приложением не увеличивая все таймауты. Свежий публичный сигнал описывает границу так: Публичный вопрос Habr Q&A от 25 августа 2026 года описывает воспроизводимый разрыв WebSocket примерно через 30 секунд в цепочке Docker, Nginx и Go. Это обезличенный сигнал боли, а не доказательство виновного слоя; имена и приложенные логи не используются. Он подтверждает существование сценария «WebSocket в Docker обрывается ровно через 30 секунд: как найти слой таймаута», но не назначает виновный компонент и не показывает масштаб. До проверки запишите только наблюдаемое: версию, поверхность продукта, момент события и воспроизводимый шаг. Личные имена, адреса, содержимое аккаунта и закрытые ссылки для этого не нужны. Если симптом нельзя повторить на безопасном примере, остановитесь на сборе фактов и не меняйте конфигурацию наугад.
Проверка по отдельным контрольным шагам
Снять время и инициатора close или reset на границах браузер proxy приложение, сравнить один контролируемый idle-сеанс с разрешённым ping pong, выписать явные таймеры каждого слоя; не считать 30 секунд стандартным nginx и остановиться до глобальной правки или публикации полных логов. Разложите эту последовательность на отдельные контрольные действия. Шаг 1: Снять время и инициатора close или reset на границах браузер proxy приложение. Шаг 2: Сравнить один контролируемый idle-сеанс с разрешённым ping pong. Шаг 3: Выписать явные таймеры каждого слоя. Шаг 4: Не считать 30 секунд стандартным nginx и остановиться до глобальной правки или публикации полных логов. После каждого шага сохраните ожидаемый и фактический результат, не переходя сразу к следующему. Контрольная переменная для этой статьи — именно «матрица инициатор закрытия × точная граница × наличие трафика × настроенный таймер, обратимый A B тест idle против ping pong и стоп-линия с минимизированным пакетом времён и кодов закрытия». Изменяйте одно условие, затем возвращайте его в исходное состояние. Если различие исчезло после отката и вернулось при повторе, ветка подтверждена наблюдением; если нет, зафиксируйте отрицательный результат и переходите к следующей границе, не расширяя права и не очищая данные.
Границы, которые задают источники
Документ 1: Официальная документация Nginx объясняет туннелирование WebSocket, явную передачу Upgrade и Connection и стандартное закрытие проксируемого соединения при отсутствии данных в течение 60 секунд; поэтому ровно 30 секунд не доказывают стандартный таймер Nginx. Документ 2: RFC 6455 определяет Ping и Pong как управляющие кадры и допускает Ping как keepalive или проверку удалённой стороны; это позволяет построить контролируемое сравнение idle и heartbeat без выдуманного прикладного трафика. Документ 3: Документация Docker описывает публикацию портов как сопоставление порта хоста и контейнера и предупреждает о границе доступности; сама публикация порта не подтверждает прикладной 30-секундный таймаут. Эти документы подтверждают только перечисленные свойства и ограничения. Их нельзя растягивать на другую версию, роль, платформу или сетевую схему без отдельной проверки. Форумный или новостной сигнал не заменяет документацию: он задаёт вопрос «как найти слой который обрывает websocket ровно через 30 секунд между браузером reverse proxy docker и приложением не увеличивая все таймауты», а ответ строится по первичным формулировкам выше. Если интерфейс, версия или результат расходятся с документом, отметьте расхождение как неизвестное и приложите к обращению ссылку и дату проверки, а не предположение о причине.
Развилки решения и стоп-линия
Матрица инициатор закрытия × точная граница × наличие трафика × настроенный таймер, обратимый A B тест idle против ping pong и стоп-линия с минимизированным пакетом времён и кодов закрытия. Практическая развилка начинается с результата последовательности: снять время и инициатора close или reset на границах браузер proxy приложение, сравнить один контролируемый idle-сеанс с разрешённым ping pong, выписать явные таймеры каждого слоя; не считать 30 секунд стандартным nginx и остановиться до глобальной правки или публикации полных логов. Если первый обратимый тест меняет симптом, повторите его на исходном состоянии и сохраните обе строки сравнения. Если результат одинаков, не делайте вывод о поломке всего продукта — переходите к следующему слою, названному в матрице для «WebSocket в Docker обрывается ровно через 30 секунд: как найти слой таймаута». Стоп-линия наступает перед удалением профиля, сбросом, выдачей широких разрешений, ослаблением защиты или изменением чужих данных. Минимальный пакет поддержки: обезличенный симптом, версия клиента и ОС, UTC-время, выбранная ветка, одно изменённое условие, ожидаемый и фактический результат. Пароли, токены, IP-адреса, серийные номера и полные логи исключите.
Материал подготовлен редакцией VOne с применением ИИ для структурирования дерева проверки, но каждый технический тезис вручную сопоставлен с указанными официальными, первичными или исследовательскими источниками; форумный либо новостной сигнал использован только как лид и не считается доказательством причины или популярности.
Источники и проверка
- nginx.org — проверенный источник проверено 2026-08-27
- datatracker.ietf.org — проверенный источник проверено 2026-08-27
- docs.docker.com — проверенный источник проверено 2026-08-27
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.