Impedire che le sessioni di modifica del codice terminino dopo 10 minuti.

Se un documento CODE si disconnette sistematicamente dopo circa 10 minuti, è necessario innanzitutto verificare il percorso WebSocket attraverso ogni proxy inverso o bilanciatore di carico. Un timeout di inattività di 600 secondi è un indizio comune di configurazione, ma il solo tempo non dimostra che il proxy sia il responsabile; prima di modificare le impostazioni, verificare quale componente chiude la connessione. Nella maggior parte delle implementazioni, la soluzione pratica consiste nel mantenere l'aggiornamento Collabora WebSocket e impostare i timeout di lettura e invio del proxy su valori superiori alla durata massima prevista della sessione di modifica.

Innanzitutto, individua il punto in cui si verifica la disconnessione.

Collabora Online utilizza una connessione browser al server CODE, mentre l'integrazione dei documenti si basa anche sulla comunicazione WOPI con l'host, come Nextcloud. Le linee guida di Collabora relative al reverse proxy e gli esempi di Office attualmente disponibili su Nextcloud documentano un percorso WebSocket separato per le sessioni dei documenti. Se tale percorso non è presente, viene indirizzato al server sbagliato o è soggetto a un timeout di inattività, l'editor potrebbe perdere la connessione attiva, pur rimanendo la pagina accessibile.

Si tratta di un requisito architetturale verificato. Ciò non significa che ogni guasto di dieci minuti abbia la stessa causa: un bilanciatore di carico cloud, un controller di ingresso, un firewall, una VPN o un altro proxy potrebbero imporre un proprio limite. Considera l'intervallo di ripetibilità come un indizio, quindi controlla i log di accesso e di errore al momento del guasto.

1. Annotare l'ora esatta in cui si interrompe una sessione e se ciò avviene durante la digitazione attiva o solo quando il documento è inattivo.
2. Negli strumenti per sviluppatori del browser, apri il pannello Rete, filtra per "WS" e controlla la connessione il cui percorso termina con /ws. /cool/Prendi nota del suo stato e del codice di chiusura se il browser ne segnala uno.
3. Allo stesso orario, controlla i log del proxy inverso o di ingresso, i log del server CODE e i log dell'host WOPI. Cerca un timeout del proxy, un reset a monte, una chiusura anomala del WebSocket o un errore WOPI. La formulazione dei log varia a seconda del prodotto e della versione, quindi non dare per scontato che un messaggio sia universale.

Se la connessione WebSocket termina alla stessa soglia configurata di 600 secondi, correggi il proxy o l'intermediario responsabile di tale soglia. Se invece termina a un intervallo diverso o se i log mostrano un errore WOPI o un errore del server, segui queste indicazioni. La documentazione di Nextcloud per la risoluzione dei problemi raccomanda specificamente di verificare la connettività in entrambe le direzioni e di esaminare i log di Nextcloud e Collabora.

Mantieni aperta la connessione WebSocket tramite il proxy.

Prima di modificare un file proxy, identifica l'host virtuale attivo e lo schema e la porta upstream effettivi per CODE. Esegui un backup della configurazione e convalida la sintassi prima di ricaricarla. L'esempio seguente illustra il comportamento WebSocket richiesto per un proxy inverso NGINX; non si tratta di un host virtuale Collabora completo. Integralo nella configurazione ufficiale per la tua implementazione, preservando gli altri blocchi di posizione, le impostazioni TLS, la gestione degli URI e le regole di sicurezza.

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

Le intestazioni Upgradee Connectionconsentono alla richiesta HTTP di passare a WebSocket. I limiti di lettura e invio più lunghi impediscono a questo proxy di chiudere una connessione inattiva dopo un breve intervallo predefinito; non sono un comando per mantenere una sessione aperta indefinitamente. Regola l'indirizzo upstream e la verifica TLS in base alla tua installazione e non disabilitare i controlli dei certificati solo per far funzionare l'esempio.

Gli esempi proxy ufficiali di Collabora rappresentano la fonte autorevole per la configurazione di routing completa e appropriata alla versione. Le loro linee guida attuali includono timeout proxy lunghi; anche l'esempio Docker di Nextcloud include una /cool/(.*)/wsmappatura WebSocket dedicata. Utilizzate questi esempi completi anziché sostituire l'intero host virtuale con questo piccolo estratto:

• Impostazioni del proxy inverso di Collabora Online
• Esempio di installazione Docker di Nextcloud 35

Per NGINX, esegui nginx -te ricarica solo dopo che il test ha esito positivo. Per Apache, utilizza il suo test di configurazione prima di ricaricare. Se CODE è in esecuzione dietro un ingress di Kubernetes o un bilanciatore di carico cloud, la modifica di NGINX sull'host CODE non risolverà un timeout più breve all'ingresso o al bordo del provider; aggiorna il componente identificato dai log.

Controlla ogni hop di rete, non solo il CODICE

Il traffico WebSocket può passare attraverso più di un intermediario: browser, CDN o firewall, bilanciatore di carico esterno, ingresso, proxy host e infine CODE. Un timeout lungo a un livello non può sovrascrivere un timeout più breve al livello successivo. Confronta il timeout di inattività o di connessione di ciascun livello e imposta il limite del percorso WebSocket più lungo del periodo di inattività previsto per le modifiche, entro i limiti e le policy di quella piattaforma.

Non confondere l'impostazione di scaricamento automatico di un documento con il timeout di rete del proxy. La prima controlla quando un processo di documento non utilizzato può essere scaricato; non ripara un WebSocket che un intermediario ha già chiuso. Allo stesso modo, impostare un timeout molto lungo non risolve un percorso di aggiornamento errato, traffico bloccato, configurazione HTTP/HTTPS non corrispondente o arresto anomalo di un processo CODE. Dopo ogni modifica, verificare che l'ora di chiusura si modifichi o che la causa registrata scompaia; questo restringe il livello responsabile senza introdurre modifiche non correlate.

Verifica che sia il browser dell'utente che l'host WOPI possano raggiungere il servizio CODE tramite HTTPS e che CODE possa raggiungere l'host WOPI. Per un'integrazione con Nextcloud, il relativo manuale di risoluzione dei problemi consiglia di controllare gli endpoint pubblici /hosting/capabilitiese da un browser e con , quindi di controllare l'endpoint di stato di Nextcloud dal server CODE. Questi controlli confermano la raggiungibilità di base; non dimostrano di per sé che una connessione WebSocket stabilita rimanga attiva per dieci minuti./hosting/discoverycurl

Verifica la riparazione con una sessione a tempo

1. Ricarica la configurazione del proxy o dell'ingresso utilizzando la procedura di convalida supportata, quindi apri una nuova sessione documento.
2. Mantieni il documento aperto per un periodo superiore alla finestra temporale in cui si è verificato l'errore precedente. Esegui un test una volta durante la modifica e, se il problema segnalato si verifica durante un periodo di inattività, esegui un test una volta con il documento inattivo.
3. Verificare che la /cool/.../wsconnessione rimanga aperta nel pannello Rete del browser e che il documento continui a essere salvato tramite l'host WOPI.
4. Esamina i log relativi allo stesso intervallo di tempo. Un test ha esito positivo se non si verificano timeout del proxy o chiusure WebSocket impreviste e se le modifiche persistono dopo la riapertura del documento.

Se la disconnessione persiste, ripristina l'orario di errore registrato e confrontalo con i log di ogni hop. Una chiusura di 600 secondi all'ingresso indica un problema a quell'ingresso; un orario di chiusura diverso o un errore lato server indicano un problema altrove. La causa precisa non può essere stabilita solo da "10 minuti" e i nomi e i valori predefiniti dei timeout variano a seconda dei prodotti proxy e delle versioni. Mantieni documentata la configurazione funzionante con la versione di CODE e il prodotto proxy in uso, in modo che i futuri aggiornamenti possano essere verificati rispetto agli esempi ufficiali correnti.