If a Collabora Online Development Edition (CODE) document opens normally, edits work, and then the editor disconnects at almost exactly 10 minutes, start with the WebSocket path between the browser and CODE. A repeatable 600-second cutoff is much more suggestive of a reverse proxy, ingress controller, load balancer, or firewall timeout than of CODE's documented default idle timers.
That distinction matters because changing CODE's own idle settings first can hide the real problem without fixing the connection that carries editing traffic. The current Collabora configuration template documents a 15-minute per-view idle timeout and a one-hour idle-document timeout, not a 10-minute editing-session limit. See the upstream coolwsd.xml template. If users are actively typing when the disconnect happens, an idle-only CODE setting is an even weaker explanation.
Verified: Collabora's published Nginx example uses WebSocket upgrade headers and a long proxy_read_timeout 36000s for the main WebSocket. Nginx itself documents that proxied WebSocket connections are closed when no data is received within the configured read timeout, and its generic proxy_read_timeout default is 60 seconds. See the Collabora Online SDK manual and Nginx WebSocket proxy documentation.
Environment-dependent: a 600-second timeout can be introduced by a different proxy layer even when the Nginx host in front of CODE looks correct. Common places include Kubernetes Ingress, HAProxy, a cloud load balancer, a WAF, or an upstream reverse proxy. The exact timeout and configuration key depend on that component.
Not proven by the symptom alone: “disconnects after 10 minutes” does not prove that Nginx is the component responsible. Capture the failed WebSocket and correlate its timestamp with proxy and CODE logs before changing several layers at once.
Action: reproduce the failure with browser developer tools open and record the exact lifetime of the WebSocket request.
Open a document, then open the browser's developer tools and switch to the Network panel. Filter for WebSocket traffic. CODE editing traffic normally includes a WebSocket under the /cool/ path. Keep the document open beyond the failure point.
Quando la sessione si disconnette, è necessario esaminare la richiesta WebSocket. Le informazioni più utili sono la sua durata, l'orario di chiusura, lo stato HTTP durante l'aggiornamento iniziale e se il browser segnala un errore di rete. Un avvio senza problemi 101 Switching Protocolsseguito da una chiusura dopo circa 600 secondi indica la presenza di un problema con la durata della connessione o con una policy di inattività in qualche punto del percorso.
Se l'aggiornamento del WebSocket non va a buon fine, non si tratta di un problema di "timeout di 10 minuti"; prima di tutto, correggi il routing e le intestazioni del WebSocket. Se il WebSocket rimane connesso mentre l'editor mostra un errore di archiviazione o di salvataggio, esamina invece il percorso WOPI/di archiviazione.
Azione: annotare l'ora di inizio e l'ora di disconnessione, quindi confrontare tali timestamp con i log di accesso/errore del reverse proxy e con i log del container o del servizio CODE.
Per Nginx, l'aspetto importante è che la posizione WebSocket trasmetta le intestazioni di aggiornamento e abbia un timeout di lettura sufficientemente lungo. Il manuale dell'SDK di Collabora mostra questo schema per il WebSocket principale:
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;
}Se la terminazione TLS avviene su Nginx e CODE sta intenzionalmente servendo HTTP non crittografato dietro di esso, lo schema a monte potrebbe essere http://diverso. Non copiare lo schema ciecamente: deve corrispondere alla configurazione della tua istanza di CODE.
Un malinteso comune è che proxy_connect_timeoutcontrolli la durata di una sessione di modifica già stabilita. Non è così; si applica durante la creazione della connessione al server upstream. L'impostazione più direttamente rilevante per un WebSocket proxy stabilito con periodi senza dati upstream è proxy_read_timeout. Nginx documenta questo comportamento nella documentazione del suo modulo proxy HTTP .
Azione: individuare il blocco Nginx effettivo che corrisponde all'URL WebSocket CODE e confermare che il timeout sia impostato lì, non solo in un blocco non correlato location.
A ottobre 2026, le note di rilascio di Collabora per la versione CODE 26.04 riportano la versione CODE 26.04.4.2, rilasciata il 24 settembre 2026. La serie 26.04 ha introdotto un URL WebSocket più compatto. Collabora segnala che le configurazioni proxy esistenti potrebbero necessitare di aggiornamenti; nelle versioni successive della 26.04, CODE potrebbe tornare all'URL precedente ed emettere un avviso di controllo se il proxy non viene aggiornato. Agli utenti di Apache2 è stato specificamente consigliato di aggiornare la regola ProxyPass con l'introduzione della versione 26.04. Consultare le note di rilascio ufficiali di CODE 26.04 .
Questo non significa che ogni disconnessione di 10 minuti sia causata dalla modifica dell'URL compatto. Significa che sulla versione 26.04 è necessario verificare le regole del reverse proxy confrontandole con la documentazione della versione effettivamente in uso, soprattutto se il problema si è presentato dopo un aggiornamento.
Azione: verifica la versione del tuo CODE nelle informazioni "Informazioni" del prodotto o nell'etichetta dell'immagine del contenitore, quindi confronta la configurazione del proxy con le linee guida attuali di Collabora per i proxy. Non dare per scontato che una regola copiata da una precedente implementazione 24.04 sia ancora ideale.
Se Nginx si trova solo un livello davanti a CODE, estendere il suo timeout potrebbe non essere sufficiente. Per Kubernetes che utilizza ingress-nginx, il progetto documenta le annotazioni per Ingress denominate nginx.ingress.kubernetes.io/proxy-read-timeoute nginx.ingress.kubernetes.io/proxy-send-timeout. Le sue linee guida WebSocket raccomandano valori superiori a un'ora per le connessioni di lunga durata. Consultare il riferimento ufficiale alle annotazioni di Ingress-Nginx e le note WebSocket .
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"Per HAProxy, l'esempio SDK di Collabora utilizza un timeout del tunnel lungo per il traffico in stile WebSocket. Per Apache, il timeout proxy generico è controllato da ProxyTimeout, ma CODE 26.04 richiede anche attenzione al modello ProxyPass WebSocket corrente. La documentazione di Apache relativa a mod_proxy spiega cosa ProxyTimeoutcontrolla.
Azione: tracciare il percorso di connessione dal browser al CODE e ispezionare ogni passaggio. Un limite di 600 secondi in un singolo passaggio può comunque terminare la sessione.
Dopo aver modificato la configurazione di Nginx, testala prima di ricaricarla:
sudo nginx -t
sudo systemctl reload nginxSe Nginx è in esecuzione in un container, utilizzare la procedura di convalida e ricaricamento equivalente specifica per il container anziché presumere che systemctlesista. L'aspetto fondamentale è convalidare la sintassi prima di sostituire la configurazione in esecuzione.
Azione: modificare un livello alla volta, registrare il valore precedente, convalidare la configurazione e quindi ripetere il test dello stesso flusso di lavoro del documento.
Non interrompere i test quando il documento si riapre. Mantieni la stessa sessione di modifica attiva ben oltre il punto in cui si è verificato l'errore. Per un sintomo che persiste per 10 minuti, una finestra di validazione di 20-30 minuti è più utile di un test di base di due minuti. Mantieni aperto il pannello Rete ed effettua modifiche occasionali in modo da poter distinguere la modifica attiva da una scheda completamente inattiva.
Un buon risultato presenta tre segnali: la connessione WebSocket rimane attiva per più di 10 minuti, l'editor continua ad accettare modifiche senza richiedere la riconnessione e non compare alcun timeout corrispondente nei log intermedi o CODE.
Se la connessione si chiude ancora esattamente 10 minuti dopo aver aumentato il timeout del proxy più vicino, ciò rappresenta una prova utile del fatto che un altro nodo applica ancora una policy di 600 secondi.
Azione: continuare la tracciatura verso l'esterno fino a identificare il componente che emette il segnale di chiusura o di timeout.
Il modello di configurazione CODE a monte attualmente documenta per_view.idle_timeout_secsun intervallo di 900 secondi, ovvero 15 minuti. La sua descrizione afferma che la visualizzazione viene attenuata e gli aggiornamenti si interrompono quando l'utente è inattivo. L' idle_timeout_secsimpostazione predefinita a livello di documento è di 3600 secondi, ovvero un'ora, prima che un documento inattivo venga scaricato.
Vale la pena verificare questi valori se il tuo comportamento corrisponde, ma nessuno dei valori predefiniti spiega una disconnessione esatta di 600 secondi. Se qualcuno ha precedentemente personalizzato coolwsd.xmlle variabili d'ambiente, i valori di Helm o i parametri del container, la tua distribuzione potrebbe differire dai valori predefiniti.
Azione: esaminare la configurazione CODE effettiva solo dopo aver stabilito se l'errore è a livello di rete o a livello di applicazione. Non incrementare ogni valore inattivo come prima reazione.
| Comportamento osservato | Controllo successivo più utile | Cosa non dare per scontato |
|---|---|---|
| La connessione WebSocket si chiude dopo circa 600 secondi di attività dell'utente. | Timeout del proxy, dell'ingresso, del bilanciatore di carico o del firewall. | Quel CODICE ha un limite di 10 minuti per l'editor integrato |
| WebSocket non raggiunge mai HTTP 101 | Aggiorna intestazioni, routing, schema upstream TLS, percorsi proxy 26.04 correnti | Il solo fatto di aumentare i timeout aiuterà |
| Il problema è iniziato dopo l'aggiornamento a CODE 26.04 | Confronta le regole di delega con le attuali linee guida 26.04 | Che una vecchia configurazione proxy 24.04 sia automaticamente equivalente |
| Sono interessate solo le schede inattive/in background. | CODE comportamento di inattività per vista più timeout di inattività intermedi | Che i guasti delle sessioni attive e delle sessioni inattive abbiano la stessa causa |
| WebSocket rimane aperto ma il salvataggio fallisce | WOPI/registri di archiviazione e richieste di salvataggio | Il timeout del WebSocket è la causa principale |
Per una sessione di modifica CODE che si disconnette dopo 10 minuti, la sequenza più efficiente è: confermare l'errore WebSocket, verificare la regola del reverse proxy corrispondente, esaminare ogni timeout intermedio, tenere conto delle modifiche al proxy-path di CODE 26.04, ricaricare in modo sicuro e testare oltre il vecchio limite. Modificare le impostazioni di inattività di CODE solo quando il comportamento osservato e la configurazione effettiva lo indicano effettivamente.
Se il momento in cui si verifica l'errore non è ripetibile, o se i log di CODE mostrano arresti anomali, terminazioni di processo, problemi di memoria o errori WOPI nello stesso istante, smettete di considerarlo un semplice caso di timeout. Questi sintomi richiedono una diagnosi diversa.
Scopri come inoltrare automaticamente tutte o solo alcune email in Outlook 365 utilizzando le impostazioni di inoltro o le regole, oltre a come interrompere l'inoltro e risolvere i problemi relativi agli inoltri esterni bloccati.
Utilizza Microsoft Editor in Word per Microsoft 365 per controllare ortografia, grammatica, chiarezza e concisione, rivedere i suggerimenti e ottimizzare le impostazioni di correzione bozze.
Scopri come aggiungere un feed RSS a Outlook 365 nella versione classica di Outlook per Windows, trovare l'URL corretto del feed, gestire gli abbonamenti e risolvere i problemi più comuni relativi agli RSS.
Passa direttamente a qualsiasi pagina in Word per Microsoft 365 con Ctrl+G o F5, utilizzando i numeri di pagina relativi o il riquadro di navigazione, grazie alle scorciatoie di Windows e Mac.
Scopri come aggiungere contatti a Outlook sul web, al nuovo Outlook, a Outlook classico e ai dispositivi mobili, e come funzionano la sincronizzazione dei contatti e l'importazione di file CSV.
Cambiare il colore di una pagina di Word, aggiungere un'immagine di sfondo, rimuoverla e abilitare la stampa in background su Windows o Mac con istruzioni chiare e aggiornate.
Collega ONLYOFFICE Desktop Editors al tuo server ownCloud, accedi, apri i file nel cloud, gestisci la connessione e risolvi i problemi di configurazione più comuni.
Risolvere i problemi di utilizzo elevato della CPU di Collabora Online identificando i processi del kit che consumano troppe risorse, controllando metriche e log, ottimizzando la concorrenza e la pulizia e verificando la sicurezza delle correzioni.
Scopri come personalizzare ONLYOFFICE Docs con un logo nell'intestazione e i colori dell'interfaccia, inclusi i limiti di licenza, la configurazione del tema JSON, i percorsi Docker e i test.
Per correggere il testo di difficile lettura in LibreOffice Calc, controlla il tema dell'applicazione, il carattere delle celle, i colori di riempimento, gli stili e la formattazione condizionale, quindi verifica l'output di stampa.
