Устранение ошибки «Неожиданное закрытие сокетного соединения» в Collabora Online: проверка WebSocket и прокси-сервера.

Collabora Online может выглядеть исправной на первый взгляд, но всё равно давать сбои, как только редактор попытается установить соединение WebSocket. Характерный симптом — документ начинает загружаться, а затем сообщает о неожиданном разрыве соединения, иногда сопровождающемся неудачным wss://запросом в браузере. В версии 2026 есть одна специфическая причина проверить это перед внесением каких-либо изменений: в ветке 26.04 был введен более компактный URL-адрес WebSocket, и старые правила обратного прокси могут с ним конфликтовать.

В официальных примечаниях к выпуску CODE 26.04 от Collabora указано, что в версии CODE 26.04.1, выпущенной 8 июня 2026 года, пользователям обратного прокси Apache2 необходимо изменить правило ProxyPass для нового компактного URL-адреса WebSocket. В более поздних примечаниях к версии 26.04.2.x говорится, что CODE может переключаться на устаревший URL-адрес, если новый маршрут недоступен, и выдает предупреждение аудита, указывающее администраторам на текущие рекомендации по прокси. Ветка Collabora Online 26.04 для корпоративных пользователей также актуальна на 2026 год, поэтому администраторам следует сравнить любую конфигурацию прокси, скопированную из более старых руководств 24.04 или 25.04, с последней документацией поставщика, прежде чем рассматривать проблему как случайную сбой сети.

Что на самом деле означает эта ошибка

В сообщении не указана конкретная первопричина. Это означает, что соединение WebSocket между браузером и Collabora либо так и не было успешно обновлено, либо было установлено, а затем неожиданно разорвано. Это различие важно, поскольку способы устранения проблемы различаются.

1. Проверьте, возникла ли ошибка после обновления до версии 26.04.

Если проблема возникла сразу после перехода с версии 25.04 или более старой версии CODE на 26.04, то в первую очередь следует рассматривать обратный прокси-сервер. Это не предположение: компания Collabora задокументировала изменение URL-адреса компактных WebSocket в примечаниях к выпуску 26.04, а в официальной теме проекта сообщалось о сбоях WebSocket после обновления до версии 26.04.1 до тех пор, пока не были изменены правила прокси-сервера Apache.

Не пытайтесь решить эту проблему, слепо откатывая версию и оставляя старый прокси без изменений. Откат может быть временной мерой восстановления, но надежное решение — привести прокси в соответствие с версией, которую вы собираетесь использовать. Для Apache используйте текущие настройки прокси Collabora Online, а не версию до 26.04. В собственном отчете Collabora о проблеме с WebSocket в версии 26.04 описан случай, когда обновление правил Apache восстановило работоспособность.

2. Докажите, работает ли HTTP, в то время как WebSocket не работает.

Сначала протестируйте обычные конечные точки Collabora:

curl -I https://office.example.com/hosting/discovery
curl -I https://office.example.com/hosting/capabilities

Успешный ответ доказывает доступность DNS, TLS, внешнего прокси-сервера и, по крайней мере, части сервиса Collabora. Он не доказывает работоспособность редактирования документов. Редактор зависит от маршрута WebSocket /cool/, который имеет другие требования к прокси-серверу.

Далее откройте инструменты разработчика браузера, воспроизведите ошибку и проверьте панель «Сеть» с помощью фильтра WS. Успешное рукопожатие WebSocket обычно приводит к обновлению HTTP-соединения; RFC 6455 определяет ответ сервера как HTTP-статус 101, когда обновление прошло успешно. Если вместо этого вы видите 400, 404, 405, 502 или немедленный сбой запроса, сопоставьте эту метку времени с логами обратного прокси и coolwsd.

3. Исправьте путь и заголовки WebSocket в Nginx.

Для Nginx важные свойства просты: запрос должен достигать /cool/пути Collabora, прокси должен использовать HTTP/1.1 для классического процесса обновления WebSocket, Upgradeзаголовки Connectionдолжны быть перенаправлены, исходный хост должен быть сохранен, а время ожидания чтения должно быть достаточно долгим для сеанса редактирования.

В руководстве по SDK Collabora уже давно указано выделенное место для WebSocket с помощью Upgrade, Connection, Host, и длинного proxy_read_timeout. В официальной документации проекта Collabora также отмечалась необходимость заголовков WebSocket на более широком /coolмаршруте. Консервативный шаблон, совместимый с версией 26.04, выглядит следующим образом:

location ^~ /cool/ {
    proxy_pass http://127.0.0.1:9980;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 3600s;
}

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

Почему значения тайм-аута имеют значение

Сеансы редактирования через WebSocket длятся долго. Текущие значения Helm в проекте Collabora явно описывают это и используют большой таймаут прокси для встроенного прокси Nginx. Если ваш балансировщик нагрузки, входящий трафик Kubernetes, CDN, брандмауэр или обратный прокси закрывают неактивные соединения раньше, чем ожидает приложение, пользователи могут редактировать в обычном режиме некоторое время, а затем отключаться с постоянным интервалом.

Если сбой происходит примерно через одинаковое количество секунд каждый раз, проверьте каждый промежуточный узел на пути, а не увеличивайте только таймаут Nginx. Побеждает тот, у кого самый короткий таймаут.

4. Обеспечьте согласованность завершения TLS.

Обычно развертывание завершает HTTPS-соединение на Nginx, Apache, HAProxy, Traefik или контроллере входящего трафика и перенаправляет обычный HTTP-трафик в Collabora на порт 9980. В этой конфигурации официальная конфигурация Collabora требует, чтобы бэкэнд знал, что TLS-соединение завершается прокси-сервером. В руководстве SDK это описано ssl.enable=falseвместе с ssl.termination=trueописанием данной модели.

В случае развертывания Docker это обычно выражается с помощью дополнительных параметров Collabora:

--o:ssl.enable=false --o:ssl.termination=true

Используйте эти параметры только в том случае, если протокол TLS действительно завершается на вышестоящем сервере. Если прокси-сервер подключается к Collabora по HTTPS, настройте эту топологию согласованно, а не смешивайте две модели. Несоответствие может привести к неправильным схемам, некорректным URL-адресам WebSocket, сбоям сертификатов или перенаправлениям, которые нарушат обновление.

5. Проверьте несоответствия хоста и источника в логах coolwsd.

Collabora проверяет источники WebSocket. Если в журнале содержится формулировка, например, " Rejecting WebSocket upgradeза которым следует источник и ожидаемый хост", исправьте связь внешнего имени хоста/порта, а не добавляйте разрешительные заголовки случайным образом. В официальном трекере проблем Collabora есть документированный пример, когда настроенное имя сервера, включающее в себя, :443не соответствовало источнику браузера без указания этого порта.

Полезные команды зависят от вашей установленной системы:

docker logs collabora --tail 200
journalctl -u coolwsd --since "10 minutes ago"
nginx -t
apachectl configtest

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

6. Если сбои происходят только в браузерах на основе Chromium, проверьте обработку HTTP/2 или HTTP/3.

Это более узкий случай, но его стоит проверить перед пересборкой сервера. В проекте Collabora задокументирован случай, связанный с Chromium, когда прокси-сервер передал запрос HTTP/2 CONNECT WebSocket напрямую в coolwsd и получил ошибку 405 Method Not Allowed. В другом сообщении зафиксированы сбои загрузки документов, связанные с HTTP/3/QUIC, в определенном пути прокси-сервера. Эти сообщения не означают, что HTTP/2 или HTTP/3 всегда должны быть отключены; они означают, что посредник должен преобразовывать поведение клиента в соединение WebSocket, поддерживаемое Collabora.

Если Firefox работает, а Chrome не работает с той же учетной записью и документом, зафиксируйте протокол и код состояния на прокси-сервере. Лучше исправить поведение прокси/входящего трафика, чем глобально отключать современные протоколы, если в вашей среде нет совместимой альтернативы.

7. Перезапускайте систему только после проверки конфигурации.

Сначала проверьте синтаксис прокси-сервера. Затем перезагрузите его, вместо того чтобы многократно перезапускать вслепую:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Для контейнеров перезапускайте службу Collabora только в том случае, если вы изменили ее собственную среду или coolwsdнастройки. Изменение только прокси-сервера обычно требует только перезагрузки прокси.

Как самостоятельно проверить работоспособность решения проблемы

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

• Подтвердите /hosting/discovery, что /hosting/capabilitiesони доступны по одному и тому же общедоступному имени хоста, к которому имеют доступ пользователи.
• Откройте документ и убедитесь, что запрос браузера WS успешно обновляется, а не возвращает 4xx/5xx.
• Внесите несколько правок, подождите дольше, чем старый интервал между сбоями, и убедитесь, что соединение остается стабильным.
• Сохраните и закройте документ, затем снова откройте его, чтобы убедиться в исправности обмена данными WOPI.
• Проверьте журналы coolwsd и proxy на наличие отклоненных обновлений WebSocket, ошибок анализа URI или повторяющихся циклов переподключения.
• Если в вашей системе используется балансировщик нагрузки или входящий трафик, повторите тест, используя реальный производственный маршрут, а не подключаясь напрямую к порту 9980.

Какой способ ремонта вам следует выбрать?

Если вы обновились до версии 26.04 и используете Apache, обновление правил прокси-сервера является первоочередной задачей, поскольку Collabora явно задокументировала это изменение. Если разрыв соединения происходит через определенный промежуток времени, сосредоточьтесь на настройках тайм-аута на каждом сетевом узле. Если сбой происходит немедленно во всех браузерах, проверьте /cool/маршрутизацию, заголовки Upgrade, согласованность Host/Origin и завершение TLS. Если сбой происходит только в одном семействе браузеров, сравните обработку протоколов HTTP, прежде чем вносить изменения в саму Collabora.

Главное — избегать обработки сообщения «соединение сокета неожиданно закрылось» как сбоя приложения Collabora по умолчанию. Во многих развертываниях редактор, конечная точка обнаружения и хост WOPI работают исправно, в то время как обратный прокси-сервер некорректно обрабатывает тот тип соединения, который наиболее важен для редактирования в реальном времени: долгоживущий WebSocket.

Официальные ссылки

• Примечания к выпуску Collabora CODE 26.04
• Примечания к выпуску Collabora Online 26.04
• Настройки прокси Collabora Online SDK
• Проблема CollaboraOnline/online #15918: Сбой WebSocket после обновления до версии 26.04
• Проблема CollaboraOnline/online #13751: Заголовки WebSocket в документации прокси.
• По умолчанию для таймаута прокси-сервера Helm в Collabora Online
• RFC 6455: Протокол WebSocket