Strona główna
» PAKIET BIUROWY MICROSOFT OFFICE
»
Napraw błąd „Połączenie z gniazdem zostało nieoczekiwanie zamknięte” w Collabora Online: sprawdzanie protokołu WebSocket i serwera proxy
Napraw błąd „Połączenie z gniazdem zostało nieoczekiwanie zamknięte” w Collabora Online: sprawdzanie protokołu WebSocket i serwera proxy
Platforma Collabora Online może na pierwszy rzut oka wyglądać poprawnie, a mimo to ulegać awarii, gdy tylko edytor próbuje nawiązać połączenie WebSocket. Znanym objawem jest dokument, który zaczyna się ładować, a następnie zgłasza, że połączenie z gniazdem zostało nieoczekiwanie zamknięte, czemu czasami towarzyszy nieudane wss://żądanie w przeglądarce. W 2026 roku istnieje jeden powód, dla którego należy to sprawdzić, zanim cokolwiek zmienisz: gałąź 26.04 wprowadziła bardziej zwarty adres URL WebSocket, a starsze reguły odwrotnego proxy mogą z nim kolidować.
Oficjalne informacje o wydaniu Collabora CODE 26.04 wskazują, że wersja CODE 26.04.1, wydana 8 czerwca 2026 r., wymagała od użytkowników odwrotnego proxy Apache2 zmiany reguły ProxyPass dla nowego, kompaktowego adresu URL WebSocket. Późniejsze informacje o wersji 26.04.2.x wskazują, że CODE może powrócić do starszego adresu URL, gdy nowa trasa nie może być użyta, i generuje ostrzeżenie audytu, które odsyła administratorów do aktualnych zaleceń dotyczących proxy. Wersja korporacyjna Collabora Online 26.04 jest również aktualna w 2026 r., dlatego administratorzy powinni porównać każdą konfigurację proxy skopiowaną ze starszej wersji podręcznika 24.04 lub 25.04 z najnowszą dokumentacją dostawcy, zanim potraktują problem jako losową awarię sieci.
Nieudane żądanie WebSocket w przeglądarce jest najwyraźniejszym sygnałem, że problem dotyczy kanału edytora na żywo, a nie zwykłego ładowania strony.
Co właściwie oznacza ten błąd
Komunikat nie wskazuje pojedynczej przyczyny. Oznacza to, że protokół WebSocket między przeglądarką a Collabora albo nigdy nie został pomyślnie zaktualizowany, albo został ustanowiony, a następnie nieoczekiwanie zakończony. To rozróżnienie jest istotne, ponieważ poprawki różnią się między sobą.
Obserwowane zachowanie
Najbardziej przydatna pierwsza kontrola
Typowe przyczyny
Natychmiast kończy się niepowodzeniem po otwarciu dokumentu
Sieć przeglądarki > Dzienniki dostępu/błędów WS i odwrotnego serwera proxy
Nieprawidłowa /cool/trasa, brak nagłówków aktualizacji, reguła Apache niezgodna z wersją 26.04, niezgodność hosta/źródła
Działa krótko, a następnie rozłącza się w powtarzalnych odstępach czasu
Limity czasu bezczynności serwera proxy, ruchu przychodzącego, modułu równoważenia obciążenia i zapory sieciowej
Zbyt krótki limit czasu dla długotrwałego protokołu WebSocket
Punkty końcowe HTTP są osiągalne, podczas gdy trasa WebSocket nie jest dostępna
Nie działa tylko jedna przeglądarka lub ścieżka sieciowa
Porównaj protokół żądań i zachowanie serwera proxy
Obsługa protokołu HTTP/2 lub HTTP/3, przekazywanie CONNECT, filtrowanie pośrednie
Dziennik serwera wyraźnie odrzuca aktualizację
Przeczytaj dokładny błąd coolwsd
Niezgodność pochodzenia, hosta, portu, hosta WOPI lub konfiguracji serwera proxy
1. Sprawdź, czy awaria wystąpiła po aktualizacji 26.04
Jeśli problem pojawił się natychmiast po przejściu z wersji 25.04 lub starszego obrazu CODE na wersję 26.04, należy traktować odwrotny serwer proxy jako pierwsze podejrzenie. To nie spekulacja: Collabora udokumentowała zmianę kompaktowego adresu URL WebSocket w informacjach o wydaniu wersji 26.04, a oficjalny problem z projektem zgłaszał awarię WebSocket po aktualizacji do wersji 26.04.1, dopóki nie zmieniono reguł serwera proxy Apache.
Nie rozwiązuj tego problemu, bezmyślnie obniżając wersję i pozostawiając stary serwer proxy bez zmian. Przywrócenie poprzedniej wersji może być tymczasowym rozwiązaniem, ale trwałym rozwiązaniem jest dostosowanie serwera proxy do wersji, którą zamierzasz uruchomić. W przypadku Apache użyj aktualnych ustawień serwera proxy Collabora Online, a nie wersji sprzed wersji 26.04. Własny rekord problemu z WebSocket 26.04 firmy Collabora dokumentuje przypadek, w którym aktualizacja reguł Apache przywróciła działanie.
W przypadku wdrożeń Apache uaktualnionych do wersji 26.04 należy porównać starsze reguły ProxyPass z aktualną dokumentacją Collabora, zamiast zakładać, że wcześniej działająca reguła jest nadal prawidłowa.
2. Udowodnij, czy protokół HTTP działa, gdy protokół WebSocket zawodzi
Najpierw przetestuj zwykłe punkty końcowe Collabora:
Pomyślna odpowiedź dowodzi, że DNS, TLS, serwer proxy front-end i przynajmniej część usługi Collabora są dostępne. Nie dowodzi to jednak , że edycja dokumentów będzie działać. Edytor jest zależny od trasy WebSocket w /cool/, która ma inne wymagania dotyczące serwera proxy.
Następnie otwórz narzędzia programistyczne przeglądarki, odtwórz błąd i sprawdź panel Sieć za pomocą filtra WS. Udane uzgadnianie WebSocket zazwyczaj aktualizuje połączenie HTTP; RFC 6455 definiuje odpowiedź serwera jako status HTTP 101, gdy aktualizacja się powiedzie. Jeśli zamiast tego zobaczysz kod 400, 404, 405, 502 lub natychmiastowe nieudane żądanie, skoreluj ten znacznik czasu z logami odwrotnego proxy i coolwsd.
3. Napraw ścieżkę i nagłówki Nginx WebSocket
W przypadku Nginx najważniejsze właściwości są proste: żądanie musi dotrzeć do /cool/ścieżki Collabora, serwer proxy musi używać protokołu HTTP/1.1 w celu przeprowadzenia klasycznego procesu uaktualniania WebSocket, nagłówki Upgradei Connectionmuszą zostać przekazane, oryginalny host musi zostać zachowany, a limit czasu odczytu musi być wystarczająco długi, aby można było przeprowadzić sesję edycji.
Podręcznik Collabora SDK od dawna wskazuje dedykowaną lokalizację WebSocket z Upgrade, Connection, Hosti długim proxy_read_timeout. Oficjalny problem z dokumentacją projektu Collabora również wskazywał na potrzebę stosowania nagłówków WebSocket na szerszej /cooltrasie. Konserwatywny wzorzec zgodny z wersją 26.04 to:
Nie wklejaj tego do działającej konfiguracji produkcyjnej bez dostosowania adresu źródłowego, modelu TLS, obsługi ścieżki i wszelkich istniejących zabezpieczeń. Prawidłowym wyborem jest zachowanie topologii przy jednoczesnym dostosowaniu do bieżących wymagań trasy i nagłówka Collabora.
Serwer proxy WebSocket Collabora wymaga trasy /cool/, obsługi aktualizacji HTTP/1.1, oryginalnego hosta i limitu czasu odpowiedniego dla długich sesji edycji.
Dlaczego wartości limitu czasu są ważne
Sesje edycji WebSocket są długotrwałe. Aktualne wartości Helm projektu Collabora wyraźnie to opisują i stosują długi limit czasu dla dołączonego serwera proxy Nginx. Jeśli Twój system równoważenia obciążenia brzegowego, serwer przychodzący Kubernetes, CDN, zapora sieciowa lub odwrotny serwer proxy zamknie bezczynne połączenia wcześniej, niż oczekuje tego aplikacja, użytkownicy mogą przez jakiś czas normalnie edytować, a następnie są rozłączani w regularnych odstępach czasu.
Jeśli awaria występuje za każdym razem po mniej więcej takiej samej liczbie sekund, sprawdź każdego pośrednika na ścieżce, zamiast zwiększać tylko limit czasu Nginx. Wygrywa najkrótszy limit czasu.
4. Zapewnij spójność zakończenia protokołu TLS
Typowe wdrożenie kończy protokół HTTPS na Nginx, Apache, HAProxy, Traefik lub kontrolerze wejściowym i przekierowuje zwykły protokół HTTP do Collabora na porcie 9980. W tym projekcie oficjalna konfiguracja Collabora wymaga, aby zaplecze wiedziało, że protokół TLS jest zakończony przez serwer proxy. Dokumentacja podręcznika SDK ssl.enable=falsewraz z informacjami ssl.termination=truedotyczącymi tego modelu.
W przypadku wdrożeń Dockera wyraża się to zazwyczaj za pomocą dodatkowych parametrów Collabora:
--o:ssl.enable=false --o:ssl.termination=true
Używaj ich tylko wtedy, gdy TLS jest rzeczywiście zakończony w górę. Jeśli serwer proxy łączy się z Collabora przez HTTPS, skonfiguruj tę topologię spójnie, zamiast mieszać oba modele. Niezgodność może skutkować błędnymi schematami, nieprawidłowymi adresami URL WebSocket, błędami certyfikatów lub przekierowaniami, które uniemożliwią aktualizację.
5. Sprawdź niezgodności hosta i źródła w dziennikach coolwsd
Collabora weryfikuje źródła WebSocket. Jeśli log zawiera sformułowania takie jak Rejecting WebSocket upgrade„pochodzenie” i „oczekiwany host”, popraw relację zewnętrzna nazwa hosta/port zamiast losowo dodawać dozwolone nagłówki. Oficjalny system śledzenia problemów Collabora zawiera udokumentowany przykład, w którym skonfigurowana nazwa serwera, w :443tym „źródło”, nie była zgodna z źródłem przeglądarki bez podania konkretnego portu.
Poszukaj pierwszego błędu w tym samym czasie, co nieudane żądanie WS. Komunikaty o odrzuconych aktualizacjach, błędnej składni URI, nieoczekiwanym hoście lub niedostępnym upstreamie są bardziej przydatne niż ogólne wyskakujące okienko w przeglądarce.
6. Jeśli zawodzą tylko przeglądarki oparte na Chromium, sprawdź obsługę protokołu HTTP/2 lub HTTP/3
To węższy przypadek, ale warto go sprawdzić przed przebudową serwera. Projekt Collabora udokumentował przypadek związany z Chromium, w którym serwer proxy przekazał żądanie HTTP/2 CONNECT WebSocket bezpośrednio do coolwsd i otrzymał błąd 405 Method Not Allowed. Inny problem rejestruje błędy ładowania dokumentów związane z HTTP/3/QUIC na określonej ścieżce serwera proxy. Te zgłoszenia nie oznaczają, że HTTP/2 lub HTTP/3 muszą być zawsze wyłączone; oznaczają one, że pośrednik musi przełożyć zachowanie klienta na połączenie WebSocket obsługiwane przez Collabora.
Jeśli Firefox działa, a Chrome nie działa na tym samym koncie i dokumencie, przechwyć protokół i kod stanu na serwerze proxy. Lepiej poprawić zachowanie serwera proxy/ruchu przychodzącego niż globalnie wyłączyć nowoczesne protokoły, chyba że w Twoim środowisku nie ma kompatybilnej alternatywy.
7. Uruchom ponownie dopiero po sprawdzeniu konfiguracji
Najpierw przetestuj składnię serwera proxy. Następnie przeładuj go, zamiast wielokrotnie restartować bez sprawdzania:
W przypadku kontenerów uruchom ponownie usługę Collabora tylko wtedy, gdy zmienisz jej własne środowisko lub coolwsdustawienia. Zmiana dotycząca wyłącznie serwera proxy zazwyczaj wymaga jedynie przeładowania serwera proxy.
Sprawdź zarówno zwykłe punkty końcowe HTTP Collabora, jak i sesję WebSocket na żywo; samo pomyślne odkrycie nie wystarczy, aby udowodnić, że edycja została naprawiona.
Jak samodzielnie sprawdzić poprawność naprawy
Zamiast polegać na pojedynczym pomyślnie otwartym dokumencie, zastosuj krótką sekwencję weryfikacji:
Potwierdź /hosting/discovery, że /hosting/capabilitiesużytkownicy są dostępni poprzez tę samą publiczną nazwę hosta.
Otwórz dokument i sprawdź, czy żądanie WS przeglądarki zostało pomyślnie zaktualizowane, zamiast zwracać kod 4xx/5xx.
Wprowadź kilka zmian, odczekaj dłużej niż poprzedni interwał awarii i sprawdź, czy połączenie pozostaje stabilne.
Zapisz i zamknij dokument, a następnie otwórz go ponownie, aby sprawdzić, czy komunikacja WOPI przebiega prawidłowo.
Sprawdź logi coolwsd i proxy pod kątem odrzuconych uaktualnień WebSocket, błędów analizy URI lub powtarzających się pętli ponownego łączenia.
Jeśli wdrożenie obejmuje moduł równoważenia obciążenia lub ruch przychodzący, powtórz test za pośrednictwem rzeczywistej ścieżki produkcyjnej, zamiast łączyć się bezpośrednio z portem 9980.
Którą naprawę powinieneś wybrać?
Jeśli dokonałeś aktualizacji do wersji 26.04 i korzystasz z Apache, aktualizacja reguł proxy ma najwyższy priorytet, ponieważ Collabora wyraźnie udokumentowała tę zmianę. Jeśli rozłączenie występuje po ustalonym czasie, skoncentruj się na ustawieniach limitu czasu dla każdego przeskoku sieciowego. Jeśli awaria występuje natychmiast we wszystkich przeglądarkach, sprawdź /cool/routing, uaktualnij nagłówki, spójność hosta/źródła oraz zakończenie TLS. Jeśli awaria dotyczy tylko jednej rodziny przeglądarek, porównaj obsługę protokołu HTTP przed zmianą samej Collabora.
Kluczem jest unikanie traktowania komunikatu „nieoczekiwane zamknięcie połączenia z gniazdem” jako domyślnej awarii aplikacji Collabora. W wielu wdrożeniach edytor, punkt końcowy wykrywania i host WOPI działają prawidłowo, podczas gdy odwrotny serwer proxy nieprawidłowo obsługuje typ połączenia, który jest najważniejszy dla edycji na żywo: długotrwałe połączenie WebSocket.