Почему падают WebSocket-соединения через 30 секунд в Docker?

Question

[vanek-dev]

Недавно мы в команде пилили обновленный микросервис chat-gateway для нашего виджета онлайн-чатов. Всё работало идеально на локалке, но как только мы развернули стейджинг в Docker-контейнерах, всплыл неприятный баг: ровно через 30 секунд простоя WebSocket-соединение с клиентом наглухо рвется с ошибкой Connection reset by peer.

Тимлид сказал: «Ваня, ты джун, вот и тренируйся на багах, иди копай Nginx и таймауты».

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

Чтобы не забивать пост простынями текста, я выложил полный дебаг-лог с сервера и свой тестовый шаблон подключения к сокетам в отдельный репозиторий у себя на GitHub vanek-devv-2026.

Собственно, вопрос к сообществу:
Кто сталкивался с подобным при проксировании вебсокетов через Nginx в связке с Go-бэкендом? Это proxy_read_timeout тупит, или всё-таки Docker network режет длинные TCP-сессии?

Comments

[VoidVolker]

Вообще, nginx не очень хорошо подходит для проксирования WS. За подробностями - в гугл. Для начала — настройки nginx в студию, будьте любезны. И что говорит гугл на счёт вашей проблемы? Какие решения вы уж попробовали и что именно не получилось?

[Довольный Айтишникъ]

отдельный репозиторий у себя на GitHub vanek-devv-2026

Ну да, ссылки давать джун еще не научился)))

[Aetae]

Докер прям сырой или чем-то обёрнут? Во всяких там кубах своя прокси прослойка обычно, в которой как раз зачастую такие таймауты и сидят.

P.S. Если решение предполагается масштабируемым через дублирование контейнеров, то с сокетами вам ещё много боли светит:).

Answer 1

[Игорь Голиков]

Разрыв соединения ровно через фиксированное время простоя при ошибке Connection reset by peer практически всегда указывает на таймаут неактивности (idle timeout) на одном из уровней проксирования или внутри самого Go-сервера.