Главная
» Как сделать
»
Восстановите WebSocket-соединение Collabora через прокси-сервер.
Восстановите WebSocket-соединение Collabora через прокси-сервер.
Когда Collabora Online сообщает о неожиданном разрыве сокетного соединения, сначала проверьте, проходит ли запрос WebSocket из браузера coolwsdчерез обратный прокси-сервер. Сопоставьте маршрут прокси с версией Collabora, сохраните обновление WebSocket и путь URL, затем протестируйте один документ, наблюдая за панелью «Сеть» браузера и журналами сервера. Если проблема возникла после обновления CODE 26.04 за Apache, ProxyPassсначала проверьте правила Apache: в примечаниях к выпуску Collabora 26.04 указано изменение компактного URL WebSocket.
WebSocket — это долговременное двустороннее соединение, которое Collabora использует между браузером и своим сервером, пока открыт документ. Обратный прокси — это служба, которая принимает публичный запрос и перенаправляет его в Collabora. Сообщение об ошибке указывает на это соединение, но не доказывает, что причиной является прокси; отклоненный хост WOPI, некорректный публичный URL, несоответствие TLS или неправильный бэкэнд также могут остановить сессию.
В диалоговом окне отображается сообщение о закрытии сокета, которое запускает проверку на наличие неполадок.
Прежде чем что-либо менять, определите свой маршрут.
Запишите версию или тег образа Collabora, программное обеспечение прокси, общедоступное имя хоста Collabora и то, заканчивается ли TLS на прокси или на Collabora. Проверьте имя службы и текущий образ, не изменяя развертывание:
Замените collaboraна имя сервиса в вашем файле Compose. Для контейнера, не использующего Compose, используйте docker psи docker inspectдля идентификации контейнера и образа. Не предполагайте, что latestтег по-прежнему указывает на ту же версию, которую вы тестировали на прошлой неделе.
1. Посмотрите, где заканчивается процесс установления соединения WebSocket.
В браузере откройте инструменты разработчика, выберите «Сеть» , отфильтруйте по типу протокола (WS или WebSocket) и попробуйте открыть один документ. URL-адрес запроса должен использоваться, wss://если общедоступная страница использует HTTPS. Выберите неудачный запрос и запишите его статус, путь URL и заголовки ответа. Успешное рукопожатие обычно завершается успешно 101 Switching Protocolsи остается открытым, пока активна сессия с документом.
Используйте статус и путь запроса WebSocket, чтобы определить неисправный узел; эта панель является наглядным примером.
Запрос WebSocket не отображается: перед редактированием правил сервера проверьте URL-адрес Collabora в приложении интеграции, консоль браузера, DNS и любые ошибки перенаправления или смешанного контента.
Запрос возвращает код 400 или 404: сравните запрошенный путь с маршрутом, который перенаправляет ваш прокси-сервер, и маршрутом, поддерживаемым установленной версией Collabora. Код 400, coolwsdозначающий «Недействительный или неизвестный запрос», может означать, что запрос достиг Collabora с путем, который она не принимает.
Запрос возвращает коды 502 или 504: проверьте, может ли прокси-сервер связаться с настроенным вышестоящим сервером Collabora, и указывают ли адрес и порт на правильный контейнер или хост.
Запрос возвращает код 101, а затем закрывается: проверьте таймауты прокси, балансировщика нагрузки, брандмауэра и простоя клиентской сети. WebSocket — это долгоживущее соединение, поэтому посредник, который закрывает неактивные соединения слишком рано, может прервать успешное открытие.
2. Сравните правило прокси с вашей версией Collabora.
Используйте текущие настройки обратного прокси Collabora для используемого вами программного обеспечения и версии прокси. Убедитесь, что маршрут WebSocket обрабатывается как WebSocket, что прокси пересылает заголовки обновления и сохраняет путь и закодированную строку запроса, а не перенаправляет или перезаписывает их. Прокси также должен отправлять общедоступный хост и схему в соответствии с настроенным в Collabora именем внешнего сервера и параметрами завершения TLS.
Для Nginx проверьте расположение параметров WebSocket и директив HTTP/1.1, Upgradeа также Connectionпереадресацию в текущем примере Collabora. Для Apache сравните ProxyPassправило и порядок с текущим примером; не вставляйте старый /cool/…/wsрезультат без изменений, не проверив, что запрашивает ваша установленная версия.
Проверка версии важна для CODE 26.04. В примечаниях к выпуску Collabora, опубликованных 8 июня 2026 года, описывается более компактный URL-адрес WebSocket и указывается, что пользователям обратного прокси Apache необходимо внести соответствующие корректировки ProxyPass. В более поздней версии 26.04 было добавлено резервное поведение для устаревших URL-адресов, поэтому старое правило может по-прежнему работать в некоторых сборках; в отчете Collabora о проблемах с WebSocket в версии 26.04 задокументированы эти изменения. Резервное поведение не заменяет сопоставление текущей конфигурации прокси с установленной версией. Ознакомьтесь с примечаниями к выпуску CODE 26.04 и обновленным примером SDK вместе.
В этом отредактированном примере показан пример пути недействительного запроса, который следует сравнить с маршрутом, перенаправляемым вашим прокси-сервером; это не запись логов в реальном времени.
3. Выявите одну ошибку и внесите одно целенаправленное изменение.
Перед повторной попыткой отправки документа запустите короткий поток логов. Опция Docker --sinceограничивает первоначальный вывод, а --followновые строки отправляются потоком; см. справочник по логам Docker Compose .
docker compose logs --since=2m --follow collabora
Запишите время выполнения теста и найдите тот же запрос в журналах Collabora и прокси-сервера. Если браузер запрашивает путь, который прокси-сервер перенаправляет на неправильный бэкэнд, обновите только этот маршрут WebSocket, используя пример Collabora, соответствующий версии. Если запрос достигает Collabora, но хост, источник или схема отклоняются, сравните общедоступное имя хоста и порт с настроенным именем сервера и перенаправленными заголовками. Если в журнале вместо этого отображается отклонение хоста WOPI или неудачный запрос информации о файле, проверьте разрешенный хост интеграционного сервера и его доступность из контейнера Collabora; это отдельный шаг от рукопожатия WebSocket в браузере.
Перезагрузите прокси-сервер после проверки его конфигурации с помощью собственной команды проверки синтаксиса этого прокси. Избегайте одновременного изменения параметров завершения TLS, списков разрешенных хостов и перезаписи URL-адресов: изменение одной причины для каждой проверки делает следующий результат интерпретируемым. Не отключайте проверку TLS и не разрешайте доступ ко всем хостам WOPI в качестве ярлыка.
4. Проверьте правильность исправления в браузере, отобразив его в документе.
Попробуйте открыть тот же документ. В инструментах разработчика убедитесь, что запрос WebSocket возвращается 101 Switching Protocolsи остается открытым. Убедитесь, что документ полностью загружается, остается подключенным и принимает небольшие правки, которые успешно сохраняются. Одного лишь стабильного соединения недостаточно, если доступ к файлу WOPI или его сохранение по-прежнему не удается.
Ответ 101 и открытое соединение — это признаки того, что рукопожатие WebSocket прошло успешно на стороне браузера.
Если рукопожатие по-прежнему не удается, сравните путь запроса в браузере, строку доступа/ошибки прокси-сервера и соответствующую coolwsdзапись в журнале с той же меткой времени. Это трехточечное сравнение покажет, где следует искать проблему: в браузере, прокси-сервере, маршруте Collabora или хосте WOPI. При обращении за помощью удалите токены доступа, идентификаторы документов, имена пользователей и частные имена хостов как из сведений о браузере, так и из журналов.