Предотвратите завершение сеансов редактирования кода через 10 минут.

Если соединение с документом CODE стабильно обрывается примерно через 10 минут, сначала проверьте путь WebSocket через каждый обратный прокси-сервер или балансировщик нагрузки. Таймаут простоя в 600 секунд — распространенный признак неисправности конфигурации, но само по себе время разрыва не доказывает, что виноват прокси-сервер; проверьте, какой компонент закрывает соединение, прежде чем менять настройки. В большинстве случаев практическое решение — сохранить обновление Collabora WebSocket и установить таймауты чтения и отправки прокси-сервера на более длительный срок, чем ожидаемая продолжительность сеанса редактирования.

Сначала выясните, где происходит обрыв связи.

Collabora Online использует браузерное соединение с сервером CODE, а интеграция с документами также основана на обмене данными по протоколу WOPI с хостом, например, Nextcloud. В рекомендациях Collabora по использованию обратного прокси и в текущих примерах Office от Nextcloud описан отдельный маршрут WebSocket для сеансов работы с документами. Если этот маршрут отсутствует, отправляется не тому вышестоящему серверу или регулируется таймаутом простоя, редактор может потерять активное соединение, в то время как сама страница останется доступной.

Это подтвержденное архитектурное требование. Это не означает, что каждая десятиминутная ошибка имеет одну и ту же причину: балансировщик нагрузки облака, контроллер входящего трафика, межсетевой экран, VPN или другой прокси-сервер могут устанавливать свои собственные ограничения. Рассматривайте повторяющийся интервал как задел, а затем проверяйте журналы доступа и ошибок в момент сбоя.

1. Зафиксируйте точное время прерывания сеанса и укажите, произошло ли это во время активного набора текста или только в режиме ожидания документа.
2. В инструментах разработчика браузера откройте панель «Сеть», отфильтруйте по «WS» и проверьте соединение, путь которого заканчивается в /wsразделе /cool/. Запишите его статус и закройте код, если браузер его сообщит.
3. В тот же момент времени проверьте журналы обратного прокси или входящего трафика, журналы сервера CODE и журналы хоста WOPI. Ищите сообщения о таймауте прокси, сбросе вышестоящего сервера, ненормальном закрытии WebSocket или ошибке WOPI. Формулировки в журналах различаются в зависимости от продукта и версии, поэтому не следует предполагать, что одно сообщение является универсальным.

Если соединение WebSocket завершается при достижении заданного порога в 600 секунд, устраните проблему с прокси-сервером или посредником, которому принадлежит этот порог. Если соединение завершается при другом интервале или в журналах отображается ошибка WOPI или сервера, используйте эти данные. В документации Nextcloud по устранению неполадок специально рекомендуется проверять соединение в обоих направлениях и просматривать журналы Nextcloud и Collabora.

Поддерживайте соединение WebSocket открытым через прокси-сервер.

Перед редактированием файла прокси определите активный виртуальный хост, а также фактическую схему и порт для CODE. Создайте резервную копию конфигурации и проверьте синтаксис перед перезагрузкой. Приведенный ниже пример иллюстрирует необходимое поведение WebSocket для обратного прокси NGINX; это не полный виртуальный хост Collabora. Объедините его с официальной конфигурацией для вашего развертывания, сохранив другие блоки местоположения, настройки TLS, обработку URI и правила безопасности.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

Заголовки позволяют HTTP-запросу переключиться на WebSocket. Более длительные лимиты на чтение и отправку предотвращают закрытие этим прокси Upgrade- Connectionсервером «тихого» соединения после короткого интервала по умолчанию; они не являются командой для поддержания сессии открытой навсегда. Настройте адрес вышестоящего сервера и проверку TLS в соответствии с вашей установкой и не отключайте проверку сертификатов просто для того, чтобы пример заработал.

Официальные примеры прокси-сервера от Collabora являются авторитетным источником полной конфигурации маршрутизации, соответствующей версии. В их текущих рекомендациях указаны длительные тайм-ауты прокси-сервера; в текущем примере Docker от Nextcloud также есть специальное /cool/(.*)/wsсопоставление WebSocket. Используйте эти полные примеры, а не заменяйте весь виртуальный хост этим небольшим фрагментом:

• Настройки обратного прокси-сервера Collabora Online
• Пример установки Nextcloud 35 в Docker

Для NGINX запускайте nginx -tи перезагружайте только после успешного завершения теста. Для Apache используйте его конфигурационный тест перед перезагрузкой. Если CODE работает за Kubernetes Ingress или облачным балансировщиком нагрузки, изменение NGINX на хосте CODE не устранит проблему с сокращением времени ожидания на Ingress или граничном провайдере; обновите компонент, указанный в логах.

Проверяйте каждый узел сети, а не только КОД.

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

Не следует путать параметр idle-unload документа с сетевым таймаутом прокси-сервера. Первый определяет, когда может быть выгружен неиспользуемый процесс обработки документа; он не восстанавливает WebSocket, который уже был закрыт промежуточным узлом. Аналогично, установка очень длительного таймаута не исправит некорректный маршрут обновления, заблокированный трафик, несоответствие конфигурации HTTP/HTTPS или сбой процесса CODE. После каждого изменения убедитесь, что время закрытия изменилось или что зарегистрированная причина исчезла; это сужает круг ответственных уровней без внесения несвязанных изменений.

Убедитесь, что и браузер пользователя, и хост WOPI могут связаться со службой CODE по протоколу HTTPS, а служба CODE может связаться с хостом WOPI. Для интеграции с Nextcloud в руководстве по устранению неполадок рекомендуется проверить общедоступные /hosting/capabilitiesи /hosting/discoveryконечные точки из браузера curl, а затем проверить конечную точку состояния Nextcloud на сервере CODE. Эти проверки подтверждают базовую доступность; сами по себе они не доказывают, что установленное соединение WebSocket работает в течение десяти минут.

Проверьте работоспособность ремонта с помощью сеанса с заданным временем.

1. Перезагрузите конфигурацию прокси или входящего трафика, используя поддерживаемый этап проверки, затем откройте новую сессию документа.
2. Держите документ открытым дольше, чем в предыдущий период возникновения ошибки. Проверьте работу документа один раз во время редактирования, и, если проблема возникает в режиме ожидания, проверьте работу документа еще раз, когда документ находится в режиме ожидания.
3. Убедитесь, что /cool/.../wsсоединение остается открытым в панели «Сеть» браузера и что документ продолжает сохраняться через хост WOPI.
4. Просмотрите журналы за тот же временной интервал. Успешный тест означает отсутствие совпадений по таймауту прокси-сервера или неожиданному закрытию WebSocket, а также сохранение изменений после повторного открытия документа.

Если разрыв соединения по-прежнему происходит, восстановите записанное время сбоя и сравните его с логами на каждом узле. Закрытие соединения через 600 секунд на входе указывает на этот вход; другое время закрытия или ошибка на стороне сервера указывают на другое место. Точную причину невозможно установить, основываясь только на «10 минутах», а названия тайм-аутов и значения по умолчанию различаются в зависимости от прокси-сервера и его версии. Сохраняйте рабочую конфигурацию с указанием версии кода и прокси-сервера в документации, чтобы в будущем можно было сравнивать текущие официальные примеры при обновлении.