Verhindern, dass Code-Bearbeitungssitzungen nach 10 Minuten enden.

Wenn ein CODE-Dokument nach etwa 10 Minuten zuverlässig die Verbindung trennt, überprüfen Sie zunächst den WebSocket-Pfad über alle Reverse-Proxys und Load Balancer. Ein Leerlauf-Timeout von 600 Sekunden ist ein häufiger Hinweis auf eine fehlerhafte Konfiguration, aber allein die Zeitangabe beweist nicht, dass der Proxy die Ursache ist. Prüfen Sie, welche Komponente die Verbindung schließt, bevor Sie Einstellungen ändern. In den meisten Fällen ist es ratsam, das Collabora-WebSocket-Upgrade beizubehalten und die Lese- und Sende-Timeouts des Proxys länger als die längste erwartete Bearbeitungssitzung einzustellen.

Zunächst muss bestätigt werden, wo die Unterbrechung auftritt.

Collabora Online nutzt eine Browserverbindung zum CODE-Server, während die Dokumentenintegration zusätzlich auf WOPI-Kommunikation mit dem Host, beispielsweise Nextcloud, basiert. Die Reverse-Proxy-Anleitung von Collabora und die aktuellen Office-Beispiele von Nextcloud beschreiben eine separate WebSocket-Route für Dokumentsitzungen. Fehlt diese Route, wird sie an den falschen Upstream-Server gesendet oder unterliegt sie einem Leerlauf-Timeout, kann der Editor die Verbindung verlieren, obwohl die Seite selbst weiterhin erreichbar ist.

Dies ist eine bestätigte Architekturanforderung. Das bedeutet jedoch nicht, dass jeder zehnminütige Ausfall dieselbe Ursache hat: Ein Cloud-Load-Balancer, Ingress-Controller, eine Firewall, ein VPN oder ein anderer Proxy kann eigene Beschränkungen festlegen. Betrachten Sie das wiederkehrende Intervall als Anhaltspunkt und überprüfen Sie die Zugriffs- und Fehlerprotokolle zum Zeitpunkt des Ausfalls.

1. Notieren Sie den genauen Zeitpunkt des Sitzungsabbruchs und ob dieser während der aktiven Texteingabe oder nur im Leerlauf des Dokuments erfolgt.
2. Öffnen Sie in den Entwicklertools Ihres Browsers das Netzwerk-Panel, filtern Sie nach „WS“ und untersuchen Sie die Verbindung, deren Pfad mit „<“ endet /ws. /cool/Notieren Sie sich den Status und den Schließcode, falls der Browser einen solchen meldet.
3. Prüfen Sie zum gleichen Zeitpunkt die Reverse-Proxy- oder Ingress-Logs, die CODE-Server-Logs und die WOPI-Host-Logs. Achten Sie auf Proxy-Timeouts, Upstream-Resets, abnormale WebSocket-Verbindungsabbrüche oder WOPI-Fehler. Die Formulierungen in den Logs variieren je nach Produkt und Version; gehen Sie daher nicht davon aus, dass eine Meldung universell gültig ist.

Wenn die WebSocket-Verbindung nach dem konfigurierten 600-Sekunden-Schwellenwert abbricht, beheben Sie das Problem mit dem Proxy oder dem zwischengeschalteten Dienst, der für diesen Schwellenwert verantwortlich ist. Falls die Verbindung nach einem anderen Intervall abbricht oder die Protokolle einen WOPI- oder Serverfehler anzeigen, gehen Sie stattdessen diesen Hinweisen nach. Die Nextcloud-Dokumentation zur Fehlerbehebung empfiehlt ausdrücklich, die Konnektivität in beide Richtungen zu überprüfen und sowohl die Nextcloud- als auch die Collabora-Protokolle einzusehen.

Halten Sie die WebSocket-Verbindung über den Proxy offen.

Bevor Sie eine Proxy-Datei bearbeiten, ermitteln Sie den aktiven virtuellen Host sowie das tatsächliche Upstream-Schema und den Port für CODE. Sichern Sie die Konfiguration und überprüfen Sie die Syntax vor dem Neuladen. Das folgende Beispiel veranschaulicht das erforderliche WebSocket-Verhalten für einen NGINX-Reverse-Proxy; es handelt sich nicht um einen vollständigen virtuellen Collabora-Host. Integrieren Sie ihn in die offizielle Konfiguration Ihrer Bereitstellung und behalten Sie dabei die anderen Location-Blöcke, TLS-Einstellungen, die URI-Verarbeitung und die Sicherheitsregeln bei.

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

Die Header `--websocket` Upgradeund Connection`--websocket` ermöglichen es der HTTP-Anfrage, auf WebSocket umzuschalten. Die längeren Lese- und Sendelimits verhindern, dass dieser Proxy eine inaktive Verbindung nach einem kurzen Standardintervall schließt; sie dienen nicht dazu, eine Sitzung dauerhaft offen zu halten. Passen Sie die Upstream-Adresse und die TLS-Verifizierung an Ihre Installation an und deaktivieren Sie die Zertifikatsprüfung nicht, nur damit das Beispiel funktioniert.

Die offiziellen Proxy-Beispiele von Collabora sind die maßgebliche Quelle für die vollständige, versionsspezifische Routing-Konfiguration. Ihre aktuelle Anleitung beinhaltet lange Proxy-Timeouts; das aktuelle Docker-Beispiel von Nextcloud verfügt zudem über ein dediziertes /cool/(.*)/wsWebSocket-Mapping. Verwenden Sie diese vollständigen Beispiele, anstatt Ihren gesamten virtuellen Host durch diesen kleinen Ausschnitt zu ersetzen.

• Collabora Online Reverse-Proxy-Einstellungen
• Nextcloud 35 Docker-Installationsbeispiel

Führen Sie bei NGINX den Test nginx -tund das anschließende Neuladen erst nach erfolgreichem Test durch. Verwenden Sie bei Apache vor dem Neuladen den Konfigurationstest. Wenn CODE hinter einem Kubernetes-Ingress oder einem Cloud-Load-Balancer läuft, behebt eine Änderung der NGINX-Konfiguration auf dem CODE-Host kein kürzeres Timeout am Ingress oder Provider-Edge; aktualisieren Sie stattdessen die Komponente, die in den Protokollen identifiziert wird.

Prüfen Sie jeden Netzwerk-Hop, nicht nur den Code.

WebSocket-Datenverkehr kann mehrere Zwischenstationen durchlaufen: Browser, CDN oder Firewall, externer Load Balancer, Ingress, Host-Proxy und schließlich CODE. Ein langes Timeout auf einer Ebene kann ein kürzeres Timeout auf der nächsten Ebene nicht überschreiben. Vergleichen Sie das Leerlauf- oder Verbindungs-Timeout jeder Ebene und legen Sie das Limit der WebSocket-Route länger als die erwartete Leerlauf-Bearbeitungszeit fest, innerhalb der Grenzen und Richtlinien der jeweiligen Plattform.

Verwechseln Sie nicht die Einstellung für das automatische Entladen eines Dokuments mit dem Netzwerk-Timeout des Proxys. Erstere steuert, wann ein ungenutzter Dokumentprozess entladen werden darf; sie behebt jedoch keine WebSocket-Verbindung, die bereits von einem Zwischenserver geschlossen wurde. Ebenso wenig behebt ein sehr langes Timeout eine fehlerhafte Aktualisierungsroute, blockierten Datenverkehr, eine inkompatible HTTP/HTTPS-Konfiguration oder einen Absturz eines CODE-Prozesses. Prüfen Sie nach jeder Änderung, ob sich die Schließzeit ändert oder der protokollierte Fehler verschwindet. Dadurch lässt sich die verantwortliche Ebene eingrenzen, ohne unnötige Änderungen vorzunehmen.

Prüfen Sie, ob sowohl der Browser des Benutzers als auch der WOPI-Host den CODE-Dienst über HTTPS erreichen können und ob CODE den WOPI-Host erreichen kann. Für eine Nextcloud-Integration empfiehlt das zugehörige Handbuch zur Fehlerbehebung, die öffentlichen Endpunkte über einen Browser und mit `npm run dev` /hosting/capabilitieszu prüfen und anschließend den Nextcloud-Status-Endpunkt vom CODE-Server aus zu überprüfen. Diese Prüfungen bestätigen die grundlegende Erreichbarkeit; sie beweisen jedoch nicht, dass eine bestehende WebSocket-Verbindung zehn Minuten lang bestehen bleibt./hosting/discoverycurl

Überprüfen Sie die Reparatur mit einer zeitgesteuerten Sitzung.

1. Laden Sie die Proxy- oder Ingress-Konfiguration mithilfe des unterstützten Validierungsschritts neu und öffnen Sie anschließend eine neue Dokumentsitzung.
2. Lassen Sie das Dokument länger geöffnet als beim vorherigen Fehlerzeitraum. Testen Sie es einmal während der Bearbeitung und, falls das gemeldete Problem während der Inaktivität auftritt, einmal im Leerlauf.
3. /cool/.../wsPrüfen Sie im Netzwerk-Panel des Browsers, ob die Verbindung weiterhin besteht und ob das Dokument weiterhin über den WOPI-Host gespeichert wird.
4. Überprüfen Sie die Protokolle für denselben Zeitraum. Ein erfolgreicher Test bedeutet, dass kein passender Proxy-Timeout oder unerwarteter WebSocket-Verbindungsabbruch auftritt und die Änderungen nach dem erneuten Öffnen des Dokuments erhalten bleiben.

Falls die Verbindung weiterhin abbricht, stellen Sie die aufgezeichnete Fehlerzeit wieder her und vergleichen Sie sie mit den Protokollen der einzelnen Hops. Eine Schließzeit von 600 Sekunden am Ingress deutet auf diesen Ingress hin; eine andere Schließzeit oder ein serverseitiger Fehler deutet auf eine andere Ursache hin. Die genaue Ursache lässt sich allein anhand der Angabe „10 Minuten“ nicht ermitteln, und Timeout-Namen und -Standardwerte variieren je nach Proxy-Produkt und -Version. Dokumentieren Sie die funktionierende Konfiguration mit der CODE-Version und dem Proxy-Produkt, damit zukünftige Aktualisierungen anhand der aktuellen offiziellen Beispiele überprüft werden können.