Verfolgen Sie ein leeres Collabora-Dokument bis zur fehlerhaften Ebene.

Prüfen Sie zunächst, ob der leere Bildschirm nur eine oder alle Dateien betrifft. Untersuchen Sie anschließend die Netzwerk- und Konsoleneinstellungen des Browsers sowie die Protokolle von Collabora und der Speicherplattform. Ein leerer Bildschirm ist ein Symptom, keine Diagnose: Der Editor wurde möglicherweise geladen, während die Dokumentverbindung, die WOPI-Autorisierung oder eingebettete Ressourcen fehlerhaft waren.

1. Ermitteln Sie, ob das Problem an der Datei, dem Browser oder dem Dienst liegt.

Öffnen Sie ein funktionierendes Dokument in derselben Anwendung und testen Sie die betroffene Datei anschließend in einem anderen unterstützten Browser oder in einem privaten Fenster. Bearbeiten Sie das Original während der Diagnose nicht. Eine einzelne fehlerhafte Datei deutet auf ein Problem mit dem Dateiformat, dem Inhalt oder den Berechtigungen hin; ein weit verbreiteter Fehler deutet auf Probleme mit gemeinsam genutzten Diensten oder Netzwerkänderungen hin.

Ein privates Fenster dient als Test, nicht als Lösung. Wenn es dort funktioniert, deaktivieren Sie die Erweiterungen einzeln oder löschen Sie die Websitedaten der betroffenen Herkunft erst, nachdem Sie sichergestellt haben, dass keine nicht synchronisierten Daten vorhanden sind. Das Löschen aller Browserdaten kann Benutzer abmelden und den Status anderer Websites löschen.

2. Ermitteln Sie die Anfrage, die vor der Änderung der Einstellungen fehlgeschlagen ist.

Öffnen Sie in Chrome oder Chromium die Entwicklertools ( F12 oder Strg+Umschalt+I ), wählen Sie „Netzwerk“ aus , aktivieren Sie „Protokoll beibehalten“ und laden Sie die Seite neu. Filtern Sie nach WS (WebSocket) und prüfen Sie die Fehler. Die Referenz zu den Chrome-Entwicklertools erklärt die Anfragefilter und Statusdetails. Überprüfen Sie die Konsole auf CSP-, Zertifikats-, Mixed-Content- oder JavaScript-Fehler.

Interpretieren Sie die Beweise, anstatt eine allgemeine Ersatzlösung anzuwenden:

• 404 bei Editor-Assets oder /browser/-Pfaden: Prüfen Sie, ob der Reverse-Proxy die aktuellen Collabora-Pfade an den richtigen Upstream weiterleitet.
• Bei einem 502-Fehler, einem Timeout oder einer sofort geschlossenen WebSocket-Verbindung sollten Sie die Erreichbarkeit des Upstream-Servers, die Proxy-Logs, die WebSocket-Verarbeitung und den Anfragepfad prüfen. Ein erreichbarer /hosting/discoveryEndpunkt beweist lediglich den grundlegenden HTTP-Zugriff; er beweist nicht, dass die Live-Verbindung des Editors funktioniert.
• 403 oder „Nicht autorisierter WOPI-Host“ in den Protokollen: Überprüfen Sie, ob der in der WOPI-URL angegebene Speicherhost mit den von Collabora zugelassenen WOPI-Hosts übereinstimmt.
• CSP- oder Zertifikatsfehler: Korrigieren Sie den genauen Ursprung der Einbettung oder die Zertifikatskette. Deaktivieren Sie nicht die Browsersicherheit und lockern Sie die Content Security Policy nicht generell, um das Laden der Seite zu ermöglichen.

Bei WebSocket-Anfragen ist ein erfolgreicher Handshake das Ziel; der angezeigte Status hängt von der HTTP-Version und dem Proxy-Pfad ab, daher sollte eine einzelne erwartete Statusnummer nicht als universell betrachtet werden.

3. Ordnen Sie die Korrektur der fehlerhaften Schicht zu.

Prüfen Sie beide Richtungen und das URL-Schema.

Die aktuelle Anleitung zur Fehlerbehebung in Nextcloud-Büros besagt, dass der Browser des Benutzers beide Server über HTTP(S) erreichen muss, Nextcloud Collabora erreichen muss und Collabora Nextcloud erreichen muss. Außerdem wird für beide Dienste dasselbe Protokoll gefordert. Testen Sie die öffentliche Collabora-Adresse von einem Browser unter [URL 1] https://office.example.com/hosting/discoveryund [URL 2] https://office.example.com/hosting/capabilities. Verwenden Sie vom Nextcloud-Host aus:

curl -fsS https://office.example.com/hosting/discovery -o /dev/null

curl -fsS https://office.example.com/hosting/capabilities -o /dev/null

Ersetzen Sie den Beispiel-Hostnamen durch Ihre tatsächliche Collabora-URL. Diese Prüfungen stellen die HTTP-Erreichbarkeit sicher, nicht die erfolgreiche Bearbeitung. Wenn der Server erfolgreich ist, der Browser jedoch nicht, überprüfen Sie die öffentlichen DNS-Einstellungen, TLS, Firewalls oder Proxys. Die Nextcloud Office-Fehlerbehebungsanleitung beschreibt diese Verbindungsprüfungen und empfiehlt, die Anwendungsprotokolle zu überprüfen.

Repariere das Proxy-Routing nur, wenn die Anfragen es erfordern.

Wenn statische Editorressourcen den Fehlercode 404 oder die Live-Verbindung den Fehlercode 502 zurückgibt, vergleichen Sie Ihre Reverse-Proxy-Routen mit den offiziellen Proxy-Einstellungen von Collabora . Stellen Sie sicher, dass der Proxy die erforderlichen Collabora-Pfade an den korrekten Upstream-Server sendet und die vom Browser verwendete WebSocket-Verbindung unterstützt. Beachten Sie die von Ihrer Bereitstellung erwarteten externen Host- und HTTPS-Informationen. Kopieren Sie keine Konfiguration für einen anderen Proxy, ein anderes URL-Präfix oder eine andere Collabora-Version, ohne deren Annahmen zu überprüfen. Ein dedizierter Collabora-Hostname erleichtert oft die Fehlersuche; pfadbasiertes Routing erfordert eine konsistente Präfixbehandlung.

Korrekte WOPI-Zulassungslisten, ohne sie zu öffnen

WOPI ist das Protokoll, das Collabora zum Abrufen und Speichern von Dokumenten über die Speicherplattform verwendet. Der WOPI-Host ist üblicherweise der Hostname von Nextcloud oder eines anderen Speichermediums, nicht der Hostname von Collabora. Falls in den Protokollen ein Fehler auftritt No acceptable WOPI hosts found, fügen Sie den genauen Speicherhost in der WOPI-Hostkonfiguration von Collabora hinzu oder korrigieren Sie ihn. Stellen Sie anschließend sicher, dass die Whitelist für WOPI-Anfragen der Speicherplattform die Adresse des Collabora-Servers enthält. Nextcloud empfiehlt in seinen Office-Konfigurationsrichtlinien, WOPI-Anfragen auf erwartete Collabora-IP-Adressen zu beschränken und Collabora so zu konfigurieren, dass es den erwarteten Hosts vertraut .

Das Hinzufügen eines bestimmten vertrauenswürdigen Hosts ist sicherer als das Deaktivieren der Host-Validierung oder das Zulassen allgemeiner Domänen. Notieren Sie sich die aktuelle Einstellung, ändern Sie nur den relevanten Eintrag und starten oder laden Sie Dienste nur bei Bedarf neu. Wenn Sie Docker verwenden, überprüfen Sie die letzten Collabora-Ausgaben mit dem Befehl `collabora.csl` docker logs --since=10m <collabora-container>; ersetzen Sie den Platzhalter durch den tatsächlichen Containernamen. Verwenden Sie für Paket- oder Kubernetes-Installationen stattdessen deren Service- oder Pod-Logs.

4. Überprüfen Sie den Editor, nicht nur den Health-Endpunkt.

Laden Sie dasselbe Dokument erneut. Prüfen Sie, ob die Assets geladen werden, die Live-Verbindung bestehen bleibt, der Inhalt angezeigt wird und keine Konsolenfehler mehr auftreten. Testen Sie ein zweites Dokument und einen anderen Benutzer, falls das Problem bei allen Benutzern auftritt. Speichern Sie eine harmlose Teständerung und öffnen Sie das Dokument erneut, um das Lesen und Speichern zu überprüfen.

Wenn die leere Seite weiterhin angezeigt wird, Anfragen aber nun erfolgreich sind, prüfen Sie die Serverprotokolle auf Dokumentkonvertierungs- oder dateispezifische Fehler und vergleichen Sie eine andere Datei im gleichen Format. Falls das Problem unmittelbar nach einem Collabora-, Browser- oder Proxy-Update auftrat, testen Sie in einem Wartungsfenster ein kontrolliertes Rollback oder eine versionsspezifische Proxy-Änderung, anstatt mehrere Variablen gleichzeitig zu ändern. Das Leeren des Browser-Caches ist nur dann sinnvoll, wenn Hinweise auf veraltete Client-Ressourcen vorliegen; blockierte Routen oder abgelehnte WOPI-Anfragen können dadurch nicht behoben werden.