Napraw czarny ekran lub pusty dokument Collabora Online podczas ładowania

Zacznij od sprawdzenia połączenia WebSocket i dostępności obu serwerów. Edytor Collabora Online, który otwiera się na czarnym ekranie, białej stronie lub pustym obszarze roboczym dokumentu, często ulega awarii, zanim interfejs użytkownika dokumentu dobiegnie końca. Jeśli problem dotyczy każdego pliku, najpierw sprawdź trasę między przeglądarką a Collabora, odwrotne proxy oraz połączenie Nextcloud z Collabora. Jeśli problem dotyczy tylko jednego pliku, przetestuj inny dokument i sprawdź jego uprawnienia oraz format przed zmianą ustawień serwera.

Użyj tej kolejności: sprawdź przeglądarkę, przetestuj punkty końcowe wykrywania Collabora, odczytaj logi integracji i serwera, a następnie popraw tylko ustawienia proxy lub WOPI, na które wskazują dowody. Resetowanie pamięci podręcznej przeglądarki może pomóc w przypadku nieaktualnych zasobów, ale nie naprawi uszkodzonego WebSocket ani nieosiągalnego hosta WOPI. Poniższe obrazy interfejsu to schematyczne przykłady; dokładne etykiety i ścieżki żądań różnią się w zależności od przeglądarki, platformy chmurowej, proxy i wersji Collabora.

Szybka diagnoza na podstawie objawu

1. Sprawdź, czy problem występuje po stronie przeglądarki czy całego serwera

Najpierw otwórz drugi dokument, o którym wiesz, że jest czytelny, i wypróbuj ten sam plik w innej przeglądarce lub w oknie prywatnym. Jeśli jeden dokument nie otwiera się, podczas gdy inne się otwierają, sprawdź, czy użytkownik nadal może go pobrać lub wyświetlić podgląd na platformie plików. Uszkodzony plik, nieobsługiwany format, wygasłe udostępnianie lub brakujące uprawnienia mogą wyglądać na problem z edytorem, ale zmiana odwrotnego proxy nie rozwiąże problemu związanego z konkretnym plikiem.

Aby sprawdzić działanie w przeglądarce, otwórz Narzędzia programistyczne przed ponownym załadowaniem pustego dokumentu. W przeglądarkach opartych na Chromium naciśnij F12lub Ctrl+Shift+I, wybierz Sieć , włącz Zachowaj dziennik i przeładuj. Filtruj według ws, coollub browser. Sprawdź również kartę Konsola pod kątem zablokowanych skryptów, ostrzeżeń o certyfikatach lub błędów zasad zabezpieczeń treści.

Nieudane żądanie poniżej /cool/…/wswskazuje na problem z uzgadnianiem połączenia WebSocket lub serwerem proxy. 502Zazwyczaj oznacza to, że serwer proxy nie mógł uzyskać użytecznej odpowiedzi od swojego nadrzędnego serwera; a 404może oznaczać, że ścieżka nie jest routowana; a a 403może wskazywać na odrzucony host lub regułę dostępu. Te kody stanu zawężają wyszukiwanie, ale do zidentyfikowania dokładnej przyczyny potrzebne są pasujące logi serwera proxy i Collabora. Jeśli nieudane żądania dotyczą plików JavaScript lub CSS poniżej /browser, sprawdź, czy serwer proxy przekazuje te zasoby statyczne do usługi Collabora.

Jeśli żądania sieciowe w oknie prywatnym zakończą się powodzeniem, tymczasowo wyłącz rozszerzenia przeglądarki blokujące skrypty lub żądania międzywitrynowe, a następnie wyczyść dane witryny tylko dla nazw hostów w chmurze i Collabora. Przetestuj ponownie przed zmianą konfiguracji serwera. Nie traktuj czyszczenia pamięci podręcznej jako głównego rozwiązania, jeśli to samo żądanie nadal nie powiedzie się na karcie Sieć.

2. Potwierdź adres URL Collabora i punkty końcowe wykrywania

W przypadku integracji z Nextcloud należy sprawdzić adres URL serwera Collabora Online w ustawieniach administracyjnych pakietu Office. Należy użyć publicznego adresu URL, do którego dostęp mają przeglądarki, z poprawną nazwą hosta i portem. Aktualne wytyczne Nextcloud mówią, że usługi Collabora i Nextcloud powinny korzystać z tego samego protokołu; zalecany jest protokół HTTPS. Niezgodność, na przykład skonfigurowanie jednej usługi za pomocą protokołu, http://podczas gdy druga jest dostępna za pomocą protokołu HTTPS, https://może spowodować zablokowanie żądań dotyczących mieszanej zawartości lub nieudane wywołania zwrotne.

W przeglądarce na komputerze z problemem otwórz https://office.example.com/hosting/discoveryi https://office.example.com/hosting/capabilities, zastępując przykładową nazwę hosta własną. Punkt końcowy wykrywania powinien zwrócić kod XML opisujący obsługiwane akcje dokumentu; funkcja capabilities powinna zwrócić odpowiedź z serwera Collabora. Błąd przeglądarki, strona logowania, błąd 404 z oznaczeniem proxy lub błąd bramy oznaczają, że trasa publiczna nie dociera do oczekiwanego punktu końcowego Collabora.

Następnie przeprowadź test z hosta Nextcloud, ponieważ sam test przeglądarki nie dowodzi, że serwery mogą się ze sobą komunikować:

curl -sS -o /dev/null -w "%{http_code}\n" https://office.example.com/hosting/discovery
curl -sS -o /dev/null -w "%{http_code}\n" https://office.example.com/hosting/capabilities

Zastąp office.example.comskonfigurowaną nazwą hosta Collabora. Pomyślna odpowiedź HTTP to przydatne sprawdzenie dostępności, natomiast przekroczenie limitu czasu, błąd DNS, błąd TLS lub odpowiedź 5xx muszą zostać rozwiązane na poziomie odpowiedniej sieci, certyfikatu, DNS lub serwera proxy. W przypadku instalacji, w których serwer Collabora musi oddzwonić do Nextcloud, należy również przetestować adres URL stanu Nextcloud z hosta Collabora:

curl -fsS https://cloud.example.com/status.php

Użyj swojej rzeczywistej nazwy hosta Nextcloud. Wbudowane instalacje CODE mogą korzystać z wewnętrznego adresu URL serwera proxy zamiast oddzielnej publicznej nazwy hosta Collabora, dlatego postępuj zgodnie z instrukcjami dla tego wdrożenia, zamiast dosłownie stosować przykład z serwerem autonomicznym.

3. Sprawdź trasę WebSocket i odwrotny serwer proxy

Collabora obsługuje zasoby przeglądarki i sesje dokumentów kilkoma ścieżkami. Odwrotny serwer proxy musi przekazywać ścieżki wymagane przez zainstalowaną wersję, w tym zasoby edytora, punkty końcowe wykrywania i możliwości oraz ścieżkę WebSocket dokumentu. Aktualna dokumentacja Collabora używa /cool/…/ws; starsze wdrożenia mogą nadal zawierać konfigurację dla starszych /loolścieżek. Dokumentacja migracji Nextcloud wyraźnie wskazuje historyczne zmiany ścieżek z loleafletna browseri z loolna cool.

W konfiguracji serwera proxy sprawdź, czy lokalizacja WebSocket jest zgodna z szerszymi regułami typu catch-all, czy serwer proxy przekazuje wymagane nagłówki aktualizacji dla oprogramowania proxy oraz czy sygnał upstream wskazuje na rzeczywistą usługę i port Collabora. Sprawdź również, czy serwer proxy zachowuje oczekiwane informacje o hoście i schemacie oraz zezwala na długotrwałe połączenia. Jeśli protokół TLS kończy się na serwerze proxy, upewnij się, że ustawienia zakończenia protokołu SSL w Collabora są zgodne z tym projektem.

Powyższy krótki fragment kodu pokazuje rodzaj nagłówków WebSocket, których może potrzebować serwer proxy w stylu Nginx; nie jest to kompletna konfiguracja serwera proxy. Nie wklejaj go samodzielnie ani nie łącz dyrektyw z różnych wersji. Porównaj pełną konfigurację z oficjalnym przewodnikiem po odwrotnym serwerze proxy Collabora dla serwera proxy i wersji Collabora, którą uruchamiasz. Po edycji pliku proxy sprawdź jego składnię za pomocą polecenia configuration-test tego serwera, a następnie przeładuj go.

4. Sprawdź walidację hosta WOPI i logi serwera

Collabora używa WOPI (Web Application Open Platform Interface), aby zażądać dokumentu z połączonej usługi pamięci masowej, takiej jak NextCloud. Serwer Collabora musi zaakceptować hosta WOPI, a serwer pamięci masowej musi mieć możliwość połączenia z usługą Collabora. W NextCloud sprawdź ustawienia pakietu Office i listę dozwolonych żądań WOPI. Dodaj tylko oczekiwany adres serwera Collabora; nie wyłączaj walidacji hosta ani nie zezwalaj na znikanie pustego ekranu z powodu dowolnych hostów.

Przeczytaj logi w momencie odtworzenia problemu. W przypadku wdrożenia Dockera, przewodnik rozwiązywania problemów NextCloud dokumentuje sprawdzenie logu kontenera; użyj rzeczywistej nazwy lub identyfikatora kontenera:

docker logs --tail 100 collabora

W przypadku instalacji opartej na pakietach nazwy usług i miejsca docelowe logów zależą od systemu operacyjnego i wersji pakietu. Typowe sprawdzenie systemd to:

sudo journalctl -u coolwsd -n 100 --no-pager

Poszukaj pasującego znacznika czasu i błędów dotyczących nieautoryzowanego hosta WOPI, nieudanego CheckFileInfożądania, weryfikacji TLS, niedostępnej pamięci masowej lub nieudanego WebSocket. Komunikat o braku pasującego, akceptowalnego hosta WOPI zazwyczaj oznacza, że ​​nazwa hosta pamięci masowej skonfigurowana dla integracji nie jest zgodna z hostem dozwolonym przez Collabora. Popraw nazwę hosta lub wpis na liście dozwolonych, zamiast dodawać niepowiązane domeny.

Sprawdź również dziennik platformy plików pod kątem tego samego czasu żądania. Jeśli Collabora nie może nawiązać połączenia z NextCloud, sprawdź rozpoznawanie nazw DNS z hosta Collabora, reguły zapory sieciowej, trasę publiczną lub wewnętrzną oraz czy usługa próbuje nawiązać połączenie z samą sobą przez nazwę hosta, która jest inaczej rozpoznawana w sieci kontenera. Podręcznik rozwiązywania problemów NextCloud zaleca sprawdzenie łączności w obu kierunkach i wykorzystanie dzienników serwera do zidentyfikowania strony, która uległa awarii.

5. Przetestuj ponownie dokument i wprowadź tylko wybrane zmiany

Po naprawieniu trasy, adresu URL, certyfikatu lub wpisu na liście dozwolonych, przeładuj serwer proxy i usługi, których dotyczy problem, tylko wtedy, gdy wymaga tego wdrożenie. Otwórz ponownie Narzędzia programistyczne, przeładuj plik i sprawdź, czy poprzednie nieudane żądanie zostało ukończone. Dokument powinien wyrenderować swoje strony lub arkusze, zaakceptować niewielką zmianę i pomyślnie ją zapisać. Pusta strona, która znika, ale nie można jej zapisać, nadal wskazuje na nierozwiązane połączenie WOPI lub magazynu.

• Odkrywanie działa, ale WebSocket zawodzi: skup się na trasie WebSocket serwera proxy, obsłudze aktualizacji, adresie nadrzędnym i przekroczeniu limitu czasu połączenia.
• Przeglądarka może połączyć się z Collabora, ale Nextcloud nie może: testować DNS, zapory sieciowej, zaufania TLS i routingu z hosta Nextcloud.
• Collabora zgłasza nieautoryzowany host WOPI: porównaj dokładną nazwę hosta pamięci masowej w ustawieniach integracji z listą dozwolonych hostów WOPI.
• Po uaktualnieniu nie powiodą się tylko stare instalacje: porównaj ścieżki proxy z dokumentacją zainstalowanej wersji i zaktualizuj starsze wersje /loollub /loleaflettrasy, jeśli jest to wymagane.
• Tylko jeden plik zostaje odrzucony po pomyślnym przejściu kontroli łączności: zweryfikuj dostęp do pliku i przetestuj kopię lub inny obsługiwany format przed zmianą ustawień globalnych.

Jak wygląda udana naprawa

Wiarygodny wynik to coś więcej niż tylko pojawienie się paska narzędzi edytora. Treść dokumentu jest renderowana, nie występują ciągłe nieudane żądania edytora ani WebSocket, a nieszkodliwa edycja testowa jest zapisywana i pozostaje po odświeżeniu. Jeśli problem nadal występuje, należy zachować krótki, zredagowany fragment sieci/konsoli przeglądarki oraz odpowiadające mu wiersze logów Nextcloud, proxy i Collabora. Logi mogą zawierać nazwy hostów, nazwy użytkowników, identyfikatory plików lub tokeny, dlatego przed ich udostępnieniem należy usunąć poufne wartości.

Aby zapoznać się z aktualnymi krokami wdrożenia, zapoznaj się z przewodnikiem rozwiązywania problemów Nextcloud Office , dokumentacją konfiguracji Nextcloud Office oraz notatkami dotyczącymi migracji Collabora . Dokładne sprawdzenie dla ownCloud, innego hosta WOPI, wbudowanej usługi CODE lub platformy kontenerowej może różnić się od przykładów z Nextcloud.