Opriți sesiunile de editare COD de la terminarea la 10 minute

Dacă un document CODE se deconectează în mod fiabil după aproximativ 10 minute, inspectați mai întâi calea WebSocket prin fiecare proxy invers sau echilibrator de încărcare. Un timeout de inactivitate de 600 de secunde este un indiciu comun de configurare, dar temporizarea în sine nu dovedește că proxy-ul este responsabil; verificați ce componentă închide conexiunea înainte de a modifica setările. În majoritatea implementărilor, soluția practică este de a păstra actualizarea Collabora WebSocket și de a seta timeout-urile de citire și trimitere ale proxy-ului mai lungi decât cea mai lungă sesiune de editare așteptată.

Mai întâi, confirmați unde are loc deconectarea

Collabora Online folosește o conexiune de browser la serverul CODE, în timp ce integrarea documentelor se bazează și pe comunicarea WOPI cu gazda, cum ar fi Nextcloud. Ghidul reverse-proxy oferit de Collabora și exemplele Office actuale ale Nextcloud documentează o rută WebSocket separată pentru sesiunile de documente. Dacă acea rută lipsește, este trimisă către upstream-ul greșit sau este guvernată de un timeout de inactivitate, editorul își poate pierde conexiunea live, în timp ce pagina în sine rămâne accesibilă.

Aceasta este o cerință arhitecturală verificată. Nu înseamnă că fiecare defecțiune de zece minute are aceeași cauză: un echilibrator de încărcare în cloud, un controler de intrare, un firewall, o VPN sau un alt proxy își poate impune propria limită. Tratați intervalul repetabil ca un indiciu, apoi verificați jurnalele de acces și de eroare în momentul defecțiunii.

1. Înregistrați ora exactă la care o sesiune se întrerupe și dacă acest lucru se întâmplă în timpul tastării active sau doar în timp ce documentul este inactiv.
2. În instrumentele pentru dezvoltatori de browser, deschideți panoul Rețea, filtrați după „WS” și inspectați conexiunea a cărei cale se termină în /wssub /cool/. Notați starea acesteia și închideți codul dacă browserul raportează una.
3. În același timp, verificați jurnalele de proxy invers sau de intrare, jurnalele serverului CODE și jurnalele gazdei WOPI. Căutați o expirare a proxy-ului, o resetare upstream, o închidere anormală a WebSocket-ului sau o eroare WOPI. Textul jurnalului variază în funcție de produs și versiune, așa că nu presupuneți că un mesaj este universal.

Dacă WebSocket-ul se termină la același prag configurat de 600 de secunde, remediați proxy-ul sau intermediarul care deține acel prag. Dacă se termină la un alt interval sau jurnalele arată o eroare WOPI sau de server, urmați în schimb acele dovezi. Documentația de depanare Nextcloud recomandă în mod specific verificarea conectivității în ambele direcții și revizuirea jurnalelor Nextcloud și Collabora.

Mențineți WebSocket-ul deschis prin proxy

Înainte de a edita un fișier proxy, identificați gazda virtuală activă și schema și portul upstream pentru CODE. Faceți o copie de rezervă a configurației și validați sintaxa înainte de reîncărcare. Exemplul de mai jos ilustrează comportamentul WebSocket necesar pentru un proxy invers NGINX; nu este o gazdă virtuală Collabora completă. Îmbinați-o în configurația oficială pentru implementarea dvs., păstrând celelalte blocuri de locație, setările TLS, gestionarea URI-urilor și regulile de securitate.

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

Anteturile Upgrade`and` Connectionpermit trecerea cererii HTTP la WebSocket. Limitele mai lungi de citire și trimitere împiedică acest proxy să închidă o conexiune silențioasă după un interval implicit scurt; acestea nu reprezintă o comandă pentru a menține o sesiune deschisă pentru totdeauna. Ajustați adresa upstream și verificarea TLS pentru a se potrivi instalării dvs. și nu dezactivați verificările certificatelor doar pentru a face exemplul să funcționeze.

Exemplele oficiale de proxy de la Collabora reprezintă autoritatea pentru configurarea completă a rutării, adecvată versiunii. Îndrumările lor actuale includ timeout-uri lungi pentru proxy; exemplul actual Docker de la Nextcloud are, de asemenea, o /cool/(.*)/wsmapare WebSocket dedicată. Folosiți aceste exemple complete în loc să înlocuiți întreaga gazdă virtuală cu acest mic fragment:

• Setări proxy invers Collabora Online
• Exemplu de instalare a Nextcloud 35 Docker

Pentru NGINX, rulați nginx -tși reîncărcați numai după ce testul reușește. Pentru Apache, utilizați testul său de configurare înainte de reîncărcare. Dacă CODE rulează în spatele Kubernetes ingress sau a unui cloud load balancer, modificarea NGINX pe gazda CODE nu va remedia un timeout mai scurt la ingress sau la marginea furnizorului; actualizați componenta pe care o identifică jurnalele.

Verificați fiecare salt de rețea, nu doar CODUL

Traficul WebSocket poate trece prin mai mulți intermediari: browser, CDN sau firewall, echilibrator de încărcare extern, ingress, proxy gazdă, apoi CODE. Un timeout lung la un nivel nu poate suprascrie un timeout mai scurt la următorul. Comparați timeout-ul de inactivitate sau de conexiune al fiecărui nivel și faceți limita rutei WebSocket mai lungă decât perioada de editare de inactivitate așteptată, în limitele și politica platformei respective.

Nu confundați setarea de descărcare-inactivitate a unui document cu timeout-ul de rețea al proxy-ului. Prima controlează momentul în care un proces de document neutilizat poate fi descărcat; nu repară un WebSocket pe care un intermediar l-a închis deja. De asemenea, setarea unui timeout foarte lung nu remediază o rută de actualizare greșită, traficul blocat, o configurație HTTP/HTTPS nepotrivită sau o eroare a procesului CODE. După fiecare modificare, confirmați că ora de închidere se mută sau că cauza înregistrată dispare; acest lucru restrânge stratul responsabil fără a introduce modificări fără legătură.

Verificați dacă atât browserul utilizatorului, cât și gazda WOPI pot accesa serviciul CODE prin HTTPS și dacă CODE poate ajunge la gazda WOPI. Pentru o integrare Nextcloud, manualul său de depanare recomandă verificarea endpoint-urilor public /hosting/capabilitiesși /hosting/discoverydintr-un browser și cu curl, apoi verificarea stării endpoint-ului Nextcloud de pe serverul CODE. Aceste verificări confirmă accesibilitatea de bază; ele nu dovedesc în sine că un WebSocket stabilit supraviețuiește zece minute.

Verificați reparația cu o sesiune temporizată

1. Reîncărcați configurația proxy sau ingress folosind pasul de validare acceptat, apoi deschideți o nouă sesiune de documente.
2. Păstrați documentul deschis mai mult timp decât fereastra de eroare anterioară. Testați o dată în timpul editării și, dacă problema raportată apare în timpul inactivității, o dată cu documentul inactiv.
3. Confirmați că /cool/.../wsconexiunea rămâne deschisă în panoul Rețea al browserului și că documentul continuă să fie salvat prin gazda WOPI.
4. Revizuiți jurnalele pentru aceeași fereastră de timp. Un test reușit înseamnă că nu apare nicio expirare a proxy-ului corespondent sau nicio închidere neașteptată a WebSocket-ului, iar modificările persistă după redeschiderea documentului.

Dacă se deconectează în continuare, restaurați timpul de eroare înregistrat și comparați-l cu jurnalele de la fiecare salt. O închidere de 600 de secunde la intrare indică acea intrare; un timp de închidere diferit sau o eroare pe server indică o altă valoare. Cauza precisă nu poate fi stabilită doar din „10 minute”, iar numele și valorile implicite ale timeout-ului variază în funcție de produsele și versiunile proxy. Păstrați configurația funcțională cu versiunea CODE și produsul proxy documentate, astfel încât actualizările viitoare să poată fi verificate în raport cu exemplele oficiale actuale.