Przywróć połączenie WebSocket Collabora przez serwer proxy

Gdy Collabora Online zgłasza nieoczekiwane zamknięcie połączenia z gniazdem, najpierw sprawdź, czy żądanie WebSocket przeglądarki dociera coolwsdprzez odwrotny serwer proxy. Dopasuj trasę serwera proxy do wersji Collabora, zachowaj uaktualnienie WebSocket i ścieżkę URL, a następnie przetestuj jeden dokument, obserwując panel sieciowy przeglądarki i logi serwera. Jeśli problem pojawił się po aktualizacji CODE 26.04 w oparciu o Apache, sprawdź ProxyPassnajpierw reguły Apache: informacje o wydaniu Collabora 26.04 wskazują na zmianę dotyczącą kompaktowego adresu URL WebSocket.

WebSocket to długotrwałe, dwukierunkowe połączenie, z którego korzysta Collabora między przeglądarką a serwerem, gdy dokument jest otwarty. Odwrotny serwer proxy to usługa, która akceptuje żądanie publiczne i przekazuje je do Collabora. Komunikat o błędzie wskazuje na to połączenie, ale nie dowodzi, że przyczyną jest serwer proxy; odrzucony host WOPI, nieprawidłowy publiczny adres URL, niezgodność TLS lub niewłaściwy serwer zaplecza również mogą przerwać sesję.

Zanim cokolwiek zmienisz, określ swoją trasę

Zapisz wersję Collabora lub tag obrazu, oprogramowanie proxy, publiczną nazwę hosta Collabora oraz informację, czy TLS kończy się na serwerze proxy, czy na Collabora. Sprawdź nazwę usługi i bieżący obraz bez zmiany wdrożenia:

docker compose ps collabora
docker compose images collabora

Zastąp collaboranazwą usługi z pliku Compose. W przypadku kontenera innego niż Compose użyj docker psi docker inspectdo identyfikacji kontenera i obrazu. Nie zakładaj, że latesttag nadal wskazuje na tę samą wersję, którą testowałeś w zeszłym tygodniu.

1. Zobacz, gdzie kończy się uzgadnianie WebSocket

W przeglądarce otwórz Narzędzia programistyczne, wybierz Sieć , filtruj według WS lub WebSocket i spróbuj ponownie otworzyć jeden dokument. Adres URL żądania powinien być używany, wss://gdy strona publiczna jest połączona z HTTPS. Wybierz nieudane żądanie i zanotuj jego status, ścieżkę URL oraz nagłówki odpowiedzi. Pomyślne uzgadnianie zazwyczaj zwraca komunikat 101 Switching Protocolsi pozostaje otwarte, dopóki sesja dokumentu jest aktywna.

• Nie pojawia się żadne żądanie WebSocket: przed edycją reguł serwera sprawdź adres URL Collabora aplikacji integracyjnej, konsolę przeglądarki, serwer DNS oraz wszelkie błędy przekierowania lub mieszanej zawartości.
• Żądanie zwraca kod 400 lub 404: porównaj żądaną ścieżkę z trasą przekierowywaną przez serwer proxy i trasą obsługiwaną przez zainstalowaną wersję Collabora. Kod 400 z coolwsdinformacją „Nieprawidłowe lub nieznane żądanie” może oznaczać, że żądanie dotarło do Collabora ścieżką, której nie akceptuje.
• Żądanie zwraca kod 502 lub 504: sprawdza, czy serwer proxy może nawiązać połączenie ze skonfigurowanym serwerem Collabora oraz czy adres i port wskazują na właściwy kontener lub hosta.
• Żądanie zwraca 101, a następnie zamyka się później: sprawdź limity czasu bezczynności serwera proxy, modułu równoważenia obciążenia, zapory sieciowej i klienta. Protokół WebSocket ma długi czas życia, więc pośrednik, który zbyt wcześnie zamknie bezczynne połączenia, może przerwać pomyślne otwarcie.

2. Porównaj regułę proxy z wersją Collabora

Użyj aktualnych ustawień odwrotnego proxy Collabora dla używanego oprogramowania proxy i jego wersji. Sprawdź, czy trasa WebSocket jest obsługiwana jako WebSocket, czy serwer proxy przekazuje nagłówki aktualizacji oraz czy zachowuje ścieżkę i zakodowany ciąg zapytania, zamiast je przekierowywać lub przepisywać. Serwer proxy musi również wysyłać publiczny host i schemat spójnie ze skonfigurowaną nazwą serwera zewnętrznego Collabora i ustawieniami zakończenia TLS.

W przypadku Nginx sprawdź lokalizację specyficzną dla WebSocket oraz dyrektywy HTTP/1.1, HTTP/1.1 Upgradei ConnectionHTTP/1.1 przekierowania w bieżącym przykładzie Collabora. W przypadku Apache porównaj regułę ProxyPassi kolejność z bieżącym przykładem; nie wklejaj starego /cool/…/wsdopasowania bez sprawdzenia, czego żąda zainstalowana wersja.

To sprawdzenie wersji ma znaczenie dla CODE 26.04. Informacje o wydaniu Collabora, opublikowane 8 czerwca 2026 r., opisują bardziej zwarty adres URL WebSocket i wskazują, że użytkownicy odwrotnego proxy Apache muszą się ProxyPassdo niego dostosować. Późniejsze prace nad wersją 26.04 wprowadziły mechanizm awaryjny dla starszych adresów URL, więc starsza reguła może nadal działać w niektórych kompilacjach; raport Collabora dotyczący rozwiązania problemu WebSocket w wersji 26.04 dokumentuje dalsze działania. Mechanizm awaryjny nie zastępuje dopasowania bieżącej konfiguracji proxy do zainstalowanej wersji. Przeczytaj informacje o wydaniu CODE 26.04 i zaktualizowany przykład SDK razem.

3. Wykryj jedną awarię i wprowadź jedną ukierunkowaną zmianę

Rozpocznij krótki strumień logów przed ponowną próbą odczytania dokumentu. --sinceOpcja Dockera ogranicza początkowy wynik, podczas gdy --followstrumieniuje nowe wiersze; patrz referencje dotyczące logów Docker Compose .

docker compose logs --since=2m --follow collabora

Zapisz czas testu i poszukaj tego samego żądania w logach Collabora i proxy. Jeśli przeglądarka żąda ścieżki, którą proxy kieruje do niewłaściwego zaplecza, zaktualizuj tylko tę ścieżkę WebSocket, korzystając z przykładu dopasowania wersji w Collabora. Jeśli żądanie dociera do Collabora, ale host, źródło lub schemat zostaje odrzucony, porównaj publiczną nazwę hosta i port ze skonfigurowaną nazwą serwera i przekazanymi nagłówkami. Jeśli log pokazuje odrzucenie hosta WOPI lub nieudane żądanie informacji o pliku, sprawdź dozwolonego hosta serwera integracyjnego i jego dostępność z kontenera Collabora; jest to oddzielny krok od uzgadniania WebSocket w przeglądarce.

Przeładuj serwer proxy po sprawdzeniu jego konfiguracji za pomocą polecenia syntax-check tego serwera. Unikaj jednoczesnej zmiany zakończenia protokołu TLS, list dozwolonych hostów i przepisywania adresów URL: zmiana jednej przyczyny w każdym teście sprawia, że ​​kolejny wynik jest interpretowalny. Nie wyłączaj weryfikacji TLS ani nie zezwalaj na używanie każdego hosta WOPI jako skrótu.

4. Sprawdź poprawność poprawki z przeglądarki do dokumentu

Spróbuj ponownie otworzyć ten sam dokument. W Narzędziach programistycznych sprawdź, czy żądanie WebSocket powraca 101 Switching Protocolsi pozostaje otwarte. Sprawdź, czy dokument został załadowany, pozostaje połączony i akceptuje niewielką edycję, która została pomyślnie zapisana. Sam stan prawidłowego połączenia nie wystarczy, jeśli dostęp do pliku WOPI lub zapisywanie nadal się nie powiedzie.

Jeśli uzgadnianie nadal się nie powiedzie, porównaj ścieżkę żądania przeglądarki, wiersz błędu/dostępu do serwera proxy oraz odpowiadający mu coolwsdwpis w dzienniku z tym samym znacznikiem czasu. To trzypunktowe porównanie pokazuje, czy kolejnym miejscem do sprawdzenia jest przeglądarka, serwer proxy, trasa Collabora czy host WOPI. Prosząc o pomoc, usuń tokeny dostępu, identyfikatory dokumentów, nazwy użytkowników i prywatne nazwy hostów zarówno ze szczegółów przeglądarki, jak i z dzienników.