Behebung des Problems, dass CODE-Dokumentbearbeitungssitzungen nach 10 Minuten getrennt werden

Wenn sich ein Collabora Online Development Edition (CODE)-Dokument normal öffnet, Änderungen funktionieren und die Verbindung dann nach fast genau 10 Minuten abbricht, überprüfen Sie zunächst die WebSocket-Verbindung zwischen Browser und CODE. Ein reproduzierbarer Abbruch nach 600 Sekunden deutet viel eher auf ein Timeout eines Reverse-Proxys, Ingress-Controllers, Load Balancers oder einer Firewall hin als auf die dokumentierten Standard-Leerlauf-Timer von CODE.

Diese Unterscheidung ist wichtig, da eine Änderung der Leerlaufeinstellungen von CODE das eigentliche Problem verschleiern kann, ohne die Verbindung zu reparieren, über die der Bearbeitungsverkehr läuft. Die aktuelle Collabora-Konfigurationsvorlage sieht ein Leerlauf-Timeout von 15 Minuten pro Ansicht und einer Stunde pro Dokument vor, nicht jedoch ein Limit von 10 Minuten pro Bearbeitungssitzung. Siehe die übergeordnete coolwsd.xml-Vorlage . Wenn Benutzer aktiv tippen, wenn die Verbindung getrennt wird, ist eine reine Leerlaufeinstellung von CODE eine noch schwächere Erklärung.

Was eine 10-minütige Unterbrechung normalerweise bedeutet

Bestätigt: Das von Collabora veröffentlichte Nginx-Beispiel verwendet WebSocket-Upgrade-Header und einen Long-Wert proxy_read_timeout 36000sfür den Haupt-WebSocket. Nginx selbst dokumentiert, dass Proxy-WebSocket-Verbindungen geschlossen werden, wenn innerhalb des konfigurierten Lese-Timeouts keine Daten empfangen werden. Der proxy_read_timeoutStandardwert hierfür beträgt 60 Sekunden. Siehe das Handbuch zum Collabora Online SDK und die Dokumentation zum Nginx-WebSocket-Proxy .

Umgebungsabhängig: Ein Timeout von 600 Sekunden kann durch eine andere Proxy-Ebene verursacht werden, selbst wenn der Nginx-Host vor CODE korrekt konfiguriert zu sein scheint. Häufige Ursachen sind Kubernetes Ingress, HAProxy, Cloud Load Balancer, Web Application Firewalls (WAF) oder Upstream-Reverse-Proxys. Der genaue Timeout und der Konfigurationsschlüssel hängen von der jeweiligen Komponente ab.

Das Symptom allein beweist nicht: „Verbindungsabbruch nach 10 Minuten“ beweist nicht, dass Nginx die Ursache ist. Erfassen Sie den fehlgeschlagenen WebSocket-Aufruf und vergleichen Sie dessen Zeitstempel mit den Proxy- und CODE-Logs, bevor Sie mehrere Komponenten gleichzeitig ändern.

Aktion: Reproduzieren Sie den Fehler mit geöffneten Entwicklertools des Browsers und protokollieren Sie die genaue Lebensdauer der WebSocket-Anfrage.

Schritt 1: Bestätigen Sie, dass tatsächlich der WebSocket abbricht.

Öffnen Sie ein Dokument, anschließend die Entwicklertools Ihres Browsers und wechseln Sie zum Netzwerk-Panel. Filtern Sie nach WebSocket-Datenverkehr. Der Datenverkehr bei der Codebearbeitung enthält üblicherweise einen WebSocket-Eintrag im /cool/Pfad. Lassen Sie das Dokument auch nach dem Auftreten des Fehlers geöffnet.

Untersuchen Sie nach dem Verbindungsabbruch die WebSocket-Anfrage. Besonders hilfreich sind die Dauer, der Zeitpunkt des Verbindungsabbruchs, der HTTP-Status beim ersten Verbindungsaufbau und ob der Browser einen Netzwerkfehler meldet. Ein problemloser Start, 101 Switching Protocolsgefolgt von einem Verbindungsabbruch nach etwa 600 Sekunden, deutet auf eine Verbindungslebensdauer- oder Inaktivitätsrichtlinie hin.

Wenn die WebSocket-Aktualisierung fehlschlägt, handelt es sich nicht um ein Problem mit einem „10-Minuten-Timeout“. Korrigieren Sie zuerst das WebSocket-Routing und die Header. Bleibt die WebSocket-Verbindung bestehen, während der Editor einen Speicher- oder Übertragungsfehler anzeigt, untersuchen Sie stattdessen den WOPI-/Speicherpfad.

Aktion: Notieren Sie die Startzeit und die Trennungszeit und vergleichen Sie diese Zeitstempel anschließend mit den Zugriffs-/Fehlerprotokollen des Reverse-Proxys sowie den Protokollen des CODE-Containers oder des Dienstes.

Schritt 2: Überprüfen Sie die CODE-Reverse-Proxy-Regel, bevor Sie die CODE-Leerlaufwerte ändern.

Für Nginx ist es wichtig, dass die WebSocket-Adresse die Upgrade-Header übergibt und ein ausreichend langes Lese-Timeout aufweist. Das SDK-Handbuch von Collabora zeigt dieses Muster für den Haupt-WebSocket:

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

Wenn TLS bei Nginx terminiert wird und CODE absichtlich unverschlüsseltes HTTP dahinter bereitstellt, kann das Upstream-Schema http://anders lauten. Kopieren Sie das Schema nicht einfach: Es muss mit der Konfiguration Ihrer CODE-Instanz übereinstimmen.

Ein häufiges Missverständnis ist, dass die proxy_connect_timeoutEinstellung die Lebensdauer einer bereits bestehenden Bearbeitungssitzung steuert. Das ist nicht der Fall; sie gilt während des Verbindungsaufbaus zum Upstream-Server. Die Einstellung, die für eine bestehende, über einen Proxy geleitete WebSocket-Verbindung mit zeitweiligen fehlenden Upstream-Daten am relevantesten ist, ist proxy_read_timeout. Nginx dokumentiert dieses Verhalten in seiner Referenz zum HTTP-Proxy-Modul .

Aktion: Suchen Sie den tatsächlichen Nginx-Block, der mit der CODE WebSocket-URL übereinstimmt, und vergewissern Sie sich, dass das Timeout dort festgelegt ist und nicht nur in einem unabhängigen Block location.

Schritt 3: Berücksichtigung der Proxy-Änderungen gemäß CODE 26.04

Die aktuellen Versionshinweise von Collabora zu CODE 26.04 (Stand: Oktober 2026) führen Version CODE 26.04.4.2 auf, die am 24. September 2026 veröffentlicht wurde. Die 26.04-Serie führte eine kompaktere WebSocket-URL ein. Collabora weist darauf hin, dass bestehende Proxy-Konfigurationen möglicherweise aktualisiert werden müssen. In späteren 26.04-Builds kann CODE auf die ältere URL zurückgreifen und eine Warnung ausgeben, wenn der Proxy nicht aktualisiert wird. Apache2-Benutzer wurden ausdrücklich aufgefordert, ihre ProxyPass-Regel mit der Einführung von 26.04 zu aktualisieren. Weitere Informationen finden Sie in den offiziellen Versionshinweisen zu CODE 26.04 .

Das bedeutet nicht, dass jede 10-minütige Verbindungsunterbrechung durch die Änderung der kompakten URL verursacht wird. Es bedeutet, dass Sie unter Windows 26.04 Ihre Reverse-Proxy-Regeln anhand der Dokumentation für die von Ihnen verwendete Version überprüfen sollten, insbesondere wenn das Problem nach einem Upgrade aufgetreten ist.

Maßnahme: Überprüfen Sie Ihre CODE-Version in den Produktinformationen oder im Container-Image-Tag und vergleichen Sie anschließend Ihre Proxy-Konfiguration mit den aktuellen Collabora-Proxy-Richtlinien. Gehen Sie nicht davon aus, dass eine aus einer älteren 24.04-Bereitstellung kopierte Regel noch optimal ist.

Schritt 4: Kubernetes Ingress, HAProxy, Apache und andere Middleboxes überprüfen

Wenn Nginx nur eine Schicht vor CODE ist, reicht eine Verlängerung des Timeouts möglicherweise nicht aus. Für Kubernetes mit ingress-nginx dokumentiert das Projekt die Ingress-spezifischen Annotationen `@Ingress` nginx.ingress.kubernetes.io/proxy-read-timeoutund ` nginx.ingress.kubernetes.io/proxy-send-timeout@WebSocket`. Die zugehörigen WebSocket-Hinweise empfehlen Werte von mehr als einer Stunde für langlebige Verbindungen. Siehe die offizielle Referenz der Ingress-Nginx-Annotationen und die WebSocket-Hinweise .

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

Für HAProxy verwendet das SDK-Beispiel von Collabora ein langes Tunnel-Timeout für WebSocket-ähnlichen Datenverkehr. Bei Apache wird das generische Proxy-Timeout durch die entsprechende Einstellung gesteuert , aber Code 26.04 erfordert auch die Berücksichtigung des aktuellen WebSocket-ProxyPass-Musters. Die DokumentationProxyTimeout von Apache mod_proxy erklärt, was diese Einstellung steuert.ProxyTimeout

Maßnahme: Zeichnen Sie den Verbindungspfad vom Browser zu CODE und überprüfen Sie jeden einzelnen Schritt. Ein Limit von 600 Sekunden an einem beliebigen Schritt kann die Sitzung weiterhin beenden.

Schritt 5: Proxy validieren und sicher neu laden

Nach der Bearbeitung der Nginx-Konfiguration sollten Sie diese vor dem Neuladen testen:

sudo nginx -t
sudo systemctl reload nginx

Läuft Nginx in einem Container, verwenden Sie die entsprechende containerbasierte Validierungs- und Neuladeprozedur, anstatt von systemctleiner bestehenden Konfiguration auszugehen. Wichtig ist, die Syntax zu überprüfen, bevor die laufende Konfiguration ersetzt wird.

Vorgehensweise: Ändern Sie jeweils nur eine Ebene, notieren Sie sich den vorherigen Wert, überprüfen Sie die Konfiguration und testen Sie dann denselben Dokumentenworkflow erneut.

Schritt 6: Überprüfen Sie die Korrektur mit einem Test, der länger als der alte Grenzwert ist.

Unterbrechen Sie die Tests nicht, wenn das Dokument wieder geöffnet wird. Lassen Sie die Bearbeitungssitzung auch nach dem vorherigen Fehlerzeitpunkt aktiv. Bei einem 10-minütigen Symptom ist ein Validierungszeitraum von 20 bis 30 Minuten sinnvoller als ein zweiminütiger Funktionstest. Lassen Sie das Netzwerkfenster geöffnet und nehmen Sie gelegentlich Änderungen vor, um aktive Bearbeitung von einem inaktiven Tab zu unterscheiden.

Ein gutes Ergebnis hat drei Merkmale: Die WebSocket-Verbindung bleibt länger als 10 Minuten bestehen, der Editor akzeptiert weiterhin Bearbeitungen ohne Aufforderung zur erneuten Verbindung, und es erscheint kein entsprechender Timeout in den Zwischen- oder CODE-Protokollen.

Wenn die Verbindung genau 10 Minuten nach der Erhöhung des Timeouts des nächsten Proxys immer noch abbricht, ist das ein nützlicher Hinweis darauf, dass ein anderer Hop immer noch eine 600-Sekunden-Richtlinie hat.

Aktion: Setzen Sie die Verfolgung nach außen fort, bis die Komponente identifiziert ist, die das Schließen oder den Timeout auslöst.

Verwechseln Sie die Leerlauf-Timer von CODE nicht mit einer 10-minütigen Netzwerkabschaltung.

Die vorgelagerte CODE-Konfigurationsvorlage dokumentiert derzeit per_view.idle_timeout_secseinen Wert von 900 Sekunden bzw. 15 Minuten. Laut Beschreibung wird die Ansicht abgedunkelt und Aktualisierungen werden gestoppt, wenn der Benutzer inaktiv ist. Der Standardwert auf Dokumentebene idle_timeout_secsbeträgt 3600 Sekunden bzw. eine Stunde, bevor ein inaktives Dokument entladen wird.

Es lohnt sich, diese Werte zu überprüfen, um festzustellen, ob Ihr Verhalten damit übereinstimmt. Allerdings erklärt keiner der Standardwerte eine exakte Trennung nach 600 Sekunden. Falls zuvor coolwsd.xmlUmgebungsvariablen, Helm-Werte oder Containerparameter angepasst wurden, kann Ihre Bereitstellung von den Standardwerten abweichen.

Maßnahme: Überprüfen Sie die effektive CODE-Konfiguration erst, nachdem Sie festgestellt haben, ob der Fehler auf Netzwerk- oder Anwendungsebene auftritt. Erhöhen Sie nicht vorschnell alle Leerlaufwerte.

Schnelldiagnosetabelle

Fazit

Bei einer CODE-Bearbeitungssitzung, die nach wiederholbaren 10 Minuten die Verbindung trennt, ist folgende Vorgehensweise am effizientesten: WebSocket-Fehler bestätigen, die entsprechende Reverse-Proxy-Regel überprüfen, alle zwischenzeitlichen Timeouts prüfen, Änderungen des Proxy-Pfads in CODE 26.04 berücksichtigen, sicher neu laden und über den alten Grenzwert hinaus testen. Die Leerlaufeinstellungen von CODE sollten nur dann geändert werden, wenn das beobachtete Verhalten und die effektive Konfiguration dies tatsächlich nahelegen.

Wenn der Fehlerzeitpunkt nicht reproduzierbar ist oder wenn die CODE-Protokolle gleichzeitig Abstürze, Prozessbeendigung, Speicherengpässe oder WOPI-Fehler anzeigen, sollte man nicht länger von einem einfachen Timeout ausgehen. Diese Symptome erfordern eine andere Diagnose.