Zatrzymaj sesje edycji KODU, aby nie kończyły się po 10 minutach

Jeśli dokument CODE niezawodnie rozłącza się po około 10 minutach, należy najpierw sprawdzić ścieżkę WebSocket przez każdy odwrotny serwer proxy lub moduł równoważenia obciążenia. 600-sekundowy limit czasu bezczynności jest częstą wskazówką konfiguracyjną, ale sam czas nie dowodzi, że serwer proxy jest odpowiedzialny za problem; przed zmianą ustawień sprawdź, który komponent zamyka połączenie. W większości wdrożeń praktycznym rozwiązaniem jest zachowanie aktualizacji Collabora WebSocket i ustawienie limitów czasu odczytu i wysyłania serwera proxy na dłużej niż najdłuższa oczekiwana sesja edycji.

Najpierw sprawdź, gdzie nastąpiło rozłączenie

Collabora Online korzysta z połączenia przeglądarki z serwerem CODE, a integracja dokumentów opiera się również na komunikacji WOPI z hostem, takim jak NextCloud. Wskazówki dotyczące odwrotnego proxy Collabora oraz aktualne przykłady pakietu Office NextCloud dokumentują oddzielną ścieżkę WebSocket dla sesji dokumentów. Jeśli ta ścieżka zaginie, zostanie wysłana do niewłaściwego serwera nadrzędnego lub będzie podlegać limitowi czasu bezczynności, edytor może utracić aktywne połączenie, podczas gdy sama strona pozostanie dostępna.

To zweryfikowany wymóg architektoniczny. Nie oznacza to, że każda dziesięciominutowa awaria ma tę samą przyczynę: moduł równoważenia obciążenia w chmurze, kontroler ruchu przychodzącego, zapora sieciowa, sieć VPN lub inny serwer proxy może narzucić własny limit. Potraktuj powtarzalny interwał jako wstępny, a następnie sprawdź logi dostępu i błędów w momencie awarii.

1. Rejestruj dokładny czas zakończenia sesji i czy ma to miejsce podczas aktywnego pisania, czy tylko wtedy, gdy dokument jest nieaktywny.
2. W narzędziach programistycznych przeglądarki otwórz panel Sieć, przefiltruj „WS” i sprawdź połączenie, którego ścieżka kończy się pod /ws. /cool/Zanotuj jego status i zamknij kod, jeśli przeglądarka go zgłosi.
3. W tym samym czasie sprawdź logi odwrotnego proxy lub logi wejściowe, logi serwera CODE oraz logi hosta WOPI. Sprawdź, czy nie wystąpił przekroczenie limitu czasu proxy, zresetowanie upstream, nieprawidłowe zamknięcie WebSocket lub błąd WOPI. Treść logów różni się w zależności od produktu i wersji, więc nie zakładaj, że jeden komunikat jest uniwersalny.

Jeśli WebSocket kończy się po tym samym skonfigurowanym progu 600 sekund, należy naprawić serwer proxy lub pośrednika, który jest właścicielem tego progu. Jeśli kończy się po innym interwale lub logi wskazują błąd WOPI lub serwera, należy postępować zgodnie z tym dowodem. Dokumentacja rozwiązywania problemów Nextcloud wyraźnie zaleca sprawdzenie łączności w obu kierunkach oraz przejrzenie logów Nextcloud i Collabora.

Utrzymuj otwarty protokół WebSocket za pośrednictwem serwera proxy

Przed edycją pliku proxy zidentyfikuj aktywnego hosta wirtualnego oraz rzeczywisty schemat i port upstream dla CODE. Utwórz kopię zapasową konfiguracji i sprawdź poprawność składni przed ponownym załadowaniem. Poniższy przykład ilustruje wymagane zachowanie WebSocket dla odwrotnego proxy NGINX; nie jest to kompletny host wirtualny Collabora. Scal go z oficjalną konfiguracją wdrożenia, zachowując pozostałe bloki lokalizacji, ustawienia TLS, obsługę URI i reguły bezpieczeństwa.

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;
}

Nagłówki Upgradei Connectionpozwalają na przełączenie żądania HTTP na WebSocket. Wyższe limity odczytu i wysyłania zapobiegają zamknięciu przez ten serwer proxy cichego połączenia po krótkim domyślnym interwale; nie są one poleceniem utrzymującym sesję otwartą na zawsze. Dostosuj adres nadrzędny i weryfikację TLS do swojej instalacji i nie wyłączaj sprawdzania certyfikatów tylko po to, aby przykład działał.

Oficjalne przykłady proxy Collabora są autorytetem w zakresie kompletnej, odpowiedniej dla danej wersji konfiguracji routingu. Ich aktualne wytyczne obejmują długie limity czasu proxy; obecny przykład Dockera od NextCloud zawiera również dedykowane /cool/(.*)/wsmapowanie WebSocket. Skorzystaj z tych kompletnych przykładów, zamiast zastępować cały host wirtualny tym krótkim fragmentem:

• Ustawienia odwrotnego serwera proxy Collabora Online
• Przykład instalacji Dockera NextCloud 35

W przypadku NGINX uruchom nginx -ti przeładuj dopiero po pomyślnym zakończeniu testu. W przypadku Apache'a przed przeładowaniem użyj testu konfiguracji. Jeśli CODE działa za ingressem Kubernetes lub modułem równoważenia obciążenia w chmurze, zmiana NGINX na hoście CODE nie naprawi krótszego limitu czasu na ingress lub krawędzi dostawcy; zaktualizuj komponent zidentyfikowany w logach.

Sprawdź każdy przeskok sieciowy, nie tylko KOD

Ruch WebSocket może przechodzić przez więcej niż jednego pośrednika: przeglądarkę, CDN lub zaporę sieciową, zewnętrzny moduł równoważenia obciążenia, ruch przychodzący, serwer proxy hosta, a następnie CODE. Długi limit czasu na jednej warstwie nie może zastąpić krótszego limitu czasu na następnej. Porównaj limity czasu bezczynności lub połączenia każdej warstwy i ustaw limit trasy WebSocket na dłuższy niż oczekiwany okres bezczynności, zgodnie z ograniczeniami i zasadami danej platformy.

Nie należy mylić ustawienia bezczynności dokumentu z limitem czasu sieci serwera proxy. To pierwsze kontroluje, kiedy nieużywany proces dokumentu może zostać rozładowany; nie naprawia ono WebSocket, który został już zamknięty przez pośrednika. Podobnie, ustawienie bardzo długiego limitu czasu nie naprawia błędnej trasy aktualizacji, zablokowanego ruchu, niezgodnej konfiguracji HTTP/HTTPS ani awarii procesu CODE. Po każdej zmianie należy sprawdzić, czy czas zamknięcia uległ zmianie lub czy zarejestrowana przyczyna zniknęła; zawęża to warstwę odpowiedzialną bez wprowadzania niepowiązanych zmian.

Sprawdź, czy zarówno przeglądarka użytkownika, jak i host WOPI mogą nawiązać połączenie z usługą CODE przez HTTPS, a także czy CODE może nawiązać połączenie z hostem WOPI. W przypadku integracji z Nextcloud, podręcznik rozwiązywania problemów zaleca sprawdzenie punktów publicznych /hosting/capabilitiesi /hosting/discoverykońcowych z poziomu przeglądarki i za pomocą [usługa] curl, a następnie sprawdzenie stanu punktu końcowego Nextcloud z poziomu serwera CODE. Te sprawdzenia potwierdzają podstawową dostępność; same w sobie nie dowodzą, że ustanowiony protokół WebSocket przetrwa dziesięć minut.

Sprawdź naprawę za pomocą sesji czasowej

1. Załaduj ponownie konfigurację serwera proxy lub ruchu przychodzącego, korzystając z obsługiwanego kroku walidacji, a następnie otwórz nową sesję dokumentu.
2. Pozostaw dokument otwarty dłużej niż poprzednie okno błędu. Przetestuj raz podczas edycji, a jeśli zgłoszony problem wystąpi podczas braku aktywności, raz, gdy dokument jest nieaktywny.
3. Sprawdź, czy /cool/.../wspołączenie pozostaje otwarte w panelu Sieć przeglądarki i czy dokument jest nadal zapisywany za pośrednictwem hosta WOPI.
4. Przejrzyj logi z tego samego przedziału czasowego. Pomyślny test oznacza, że ​​nie wystąpi żadne przekroczenie limitu czasu serwera proxy ani nieoczekiwane zamknięcie protokołu WebSocket, a zmiany zostaną zachowane po ponownym otwarciu dokumentu.

Jeśli nadal występuje rozłączenie, przywróć zarejestrowany czas awarii i porównaj go z logami dla każdego przeskoku. Zamknięcie po 600 sekundach na wejściu wskazuje na to wejście; inny czas zamknięcia lub błąd po stronie serwera wskazuje na inne miejsce. Dokładnej przyczyny nie da się ustalić na podstawie samych „10 minut”, a nazwy limitów czasu i wartości domyślne różnią się w zależności od produktu proxy i jego wersji. Zachowaj roboczą konfigurację z udokumentowaną wersją CODE i produktem proxy, aby przyszłe aktualizacje można było porównać z aktualnymi, oficjalnymi przykładami.