Dacă un document Collabora Online Development Edition (CODE) se deschide normal, editările funcționează, iar apoi editorul se deconectează după aproape exact 10 minute, începeți cu calea WebSocket dintre browser și CODE. O limită repetabilă de 600 de secunde sugerează mult mai mult un timeout proxy invers, un controller de intrare, un echilibrator de încărcare sau un firewall decât temporizatoarele de inactivitate implicite documentate de CODE.
Această distincție este importantă deoarece modificarea mai întâi a setărilor de inactivitate ale CODE poate ascunde problema reală fără a remedia conexiunea care transportă traficul de editare. Șablonul de configurare Collabora actual documentează un timeout de inactivitate de 15 minute per vizualizare și un timeout de inactivitate de o oră pentru documente, nu o limită de 10 minute pentru sesiunile de editare. Consultați șablonul coolwsd.xml din amonte . Dacă utilizatorii tastează activ când are loc deconectarea, o setare CODE doar pentru inactivitate este o explicație și mai slabă.
Verificat: Exemplul Nginx publicat de Collabora folosește antete de actualizare WebSocket și o valoare long proxy_read_timeout 36000spentru WebSocket-ul principal. Nginx însuși documentează faptul că conexiunile WebSocket prin proxy sunt închise atunci când nu se primesc date în timpul de expirare configurat pentru citire, iar proxy_read_timeoutvaloarea implicită generică este de 60 de secunde. Consultați manualul SDK-ului Collabora Online și documentația proxy-ului Nginx WebSocket .
Dependent de mediu: un timeout de 600 de secunde poate fi introdus de un alt nivel proxy, chiar și atunci când gazda Nginx din fața CODE-ului pare corectă. Locurile comune includ Kubernetes Ingress, HAProxy, un echilibrator de încărcare în cloud, un WAF sau un proxy invers în amonte. Timeout-ul exact și cheia de configurare depind de componenta respectivă.
Nu este dovedit doar de simptom: „se deconectează după 10 minute” nu dovedește că Nginx este componenta responsabilă. Capturați WebSocket-ul defect și corelați timestamp-ul său cu jurnalele proxy și CODE înainte de a modifica mai multe straturi simultan.
Acțiune: reproduceți eroarea cu instrumentele de dezvoltare ale browserului deschise și înregistrați durata exactă de viață a solicitării WebSocket.
Deschideți un document, apoi deschideți instrumentele pentru dezvoltatori ale browserului și comutați la panoul Rețea. Filtrați pentru traficul WebSocket. Traficul de editare COD include în mod normal un WebSocket sub /cool/cale. Mențineți documentul deschis și după punctul de eroare.
Când sesiunea se deconectează, inspectați solicitarea WebSocket. Cele mai utile informații sunt durata acesteia, momentul închiderii, starea HTTP în timpul actualizării inițiale și dacă browserul raportează o eroare de rețea. O sesiune inițială curată, 101 Switching Protocolsurmată de o închidere de aproximativ 600 de secunde, indică o politică de durată de viață a conexiunii sau de inactivitate undeva în cale.
Dacă WebSocket nu se actualizează niciodată cu succes, aceasta nu este o problemă de „timeout de 10 minute”; remediați mai întâi rutarea și anteturile WebSocket. Dacă WebSocket rămâne conectat în timp ce editorul afișează o eroare de stocare sau salvare, investigați în schimb calea WOPI/storage.
Acțiune: notați ora de începere și ora de deconectare, apoi comparați aceste marcaje temporale cu jurnalele de acces/erori ale proxy-ului invers și cu jurnalele de container CODE sau de service.
Pentru Nginx, partea importantă este ca locația WebSocket să transmită anteturile de actualizare și să aibă un timeout de citire suficient de lung. Manualul SDK-ului Collabora prezintă acest model pentru WebSocket-ul principal:
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;
}Dacă TLS este terminat la Nginx și CODE servește intenționat HTTP simplu în spatele acestuia, este posibil să fie http://folosită schema din amonte. Nu copiați schema orbește: trebuie să corespundă modului în care este configurată instanța CODE.
O neînțelegere frecventă este că proxy_connect_timeoutcontrolează durata de viață a unei sesiuni de editare deja stabilite. Nu o face; se aplică în timpul stabilirii conexiunii la upstream. Setarea cea mai direct relevantă pentru un WebSocket proxy stabilit, cu perioade fără date upstream, este proxy_read_timeout. Nginx documentează acest comportament în referința modulului său de proxy HTTP .
Acțiune: localizați blocul Nginx real care corespunde adresei URL CODE WebSocket și confirmați că timeout-ul este setat acolo, nu doar într-un fișier location. fără legătură.
Începând cu octombrie 2026, notele de lansare actuale ale versiunii CODE 26.04 de la Collabora menționează CODE 26.04.4.2, lansat pe 24 septembrie 2026. Seria 26.04 a introdus un URL WebSocket mai compact. Collabora menționează că configurațiile proxy existente pot necesita actualizări; în versiunile ulterioare 26.04, CODE poate reveni la URL-ul vechi și poate emite un avertisment de audit atunci când proxy-ul nu este actualizat. Utilizatorilor Apache2 li s-a spus în mod specific să își actualizeze regula ProxyPass când a fost introdusă versiunea 26.04. Consultați notele oficiale de lansare ale CODE 26.04 .
Asta nu înseamnă că fiecare deconectare de 10 minute este cauzată de modificarea URL-ului compact. Înseamnă că, în versiunea 26.04, ar trebui să verificați regulile de reverse proxy în raport cu documentația versiunii pe care o executați efectiv, mai ales dacă problema a apărut după o actualizare.
Acțiune: verificați versiunea de COD în informațiile Despre ale produsului sau în eticheta imaginii containerului, apoi comparați configurația proxy-ului cu instrucțiunile actuale pentru proxy-ul Collabora. Nu presupuneți că o regulă copiată dintr-o implementare mai veche, versiunea 24.04, este încă ideală.
Dacă Nginx se află doar cu un strat în fața CODE-ului, extinderea timeout-ului său s-ar putea să nu fie suficientă. Pentru Kubernetes care utilizează ingress-nginx, proiectul documentează adnotările per Ingress numite nginx.ingress.kubernetes.io/proxy-read-timeoutși nginx.ingress.kubernetes.io/proxy-send-timeout. Ghidul său WebSocket recomandă valori mai mari de o oră pentru conexiuni de lungă durată. Consultați referința oficială pentru adnotările Ingress-Nginx și notele WebSocket .
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"Pentru HAProxy, exemplul SDK al Collabora folosește un timeout lung pentru tunel pentru traficul de tip WebSocket. Pentru Apache, timeout-ul generic al proxy-ului este controlat de , dar CODE 26.04 necesită, de asemenea, atenție la modelul WebSocket ProxyPass actual. Documentația mod_proxyProxyTimeout a Apache explică ce anume controlează.ProxyTimeout
Acțiune: desenați calea de conexiune de la browser la CODE și inspectați fiecare hop. O limită de 600 de secunde la orice hop poate totuși termina sesiunea.
După editarea configurației Nginx, testați-o înainte de reîncărcare:
sudo nginx -t
sudo systemctl reload nginxDacă Nginx rulează într-un container, utilizați procedura echivalentă de validare și reîncărcare bazată pe container în loc să presupuneți că systemctlexistă. Partea importantă este validarea sintaxei înainte de a înlocui configurația care rulează.
Acțiune: modificați câte un strat pe rând, înregistrați valoarea anterioară, validați configurația și apoi retestați același flux de lucru al documentului.
Nu opriți testarea când documentul se redeschide. Lăsați aceeași sesiune de editare conectată mult dincolo de punctul de eroare anterior. Pentru un simptom de 10 minute, o fereastră de validare de 20 până la 30 de minute este mai utilă decât un test de fum de două minute. Mențineți panoul Rețea deschis și faceți editări ocazionale pentru a putea distinge editarea activă de o filă complet inactivă.
Un rezultat bun are trei semne: WebSocket-ul rămâne stabilit după 10 minute, editorul continuă să accepte editări fără solicitări de reconectare și nu apare nicio expirare corespunzătoare în jurnalele intermediare sau CODE.
Dacă conexiunea se închide în continuare la exact 10 minute după ce ați mărit cel mai apropiat timeout proxy, aceasta este o dovadă utilă că un alt hop are încă o politică de 600 de secunde.
Acțiune: continuați urmărirea spre exterior până când este identificată componenta care emite închiderea sau timeout-ul.
Șablonul de configurare CODE din amonte documentează în prezent per_view.idle_timeout_secsca 900 de secunde sau 15 minute. Descrierea sa spune că vizualizarea este estompată și actualizările se opresc atunci când utilizatorul este inactiv. idle_timeout_secsValoarea implicită la nivel de document este de 3600 de secunde sau o oră înainte ca un document inactiv să fie descărcat.
Merită să verificați dacă aceste valori se potrivesc cu comportamentul dvs., dar niciuna dintre valorile implicite nu explică o deconectare exactă de 600 de secunde. Dacă cineva a personalizat anterior coolwsd.xml, variabile de mediu, valori Helm sau parametri ai containerului, implementarea dvs. poate diferi de valorile implicite.
Acțiune: inspectați configurația CODULUI efectivă numai după ce ați stabilit dacă eroarea este la nivel de rețea sau la nivel de aplicație. Nu creșteți fiecare valoare inactivă ca primă intervenție.
| Comportament observat | Cea mai utilă verificare următoare | Ce să nu presupunem |
|---|---|---|
| WebSocket se închide la aproximativ 600 de secunde în timp ce utilizatorul este activ | Expirare proxy, ingress, load balancer sau firewall | Acel COD are o limită de editor încorporată de 10 minute |
| WebSocket nu atinge niciodată HTTP 101 | Actualizarea antetelor, rutare, schemă TLS în amonte, căi proxy 26.04 actuale | Că doar creșterea timeout-urilor va ajuta |
| Eroarea a început după actualizarea la CODE 26.04 | Comparați regulile de proxy cu îndrumările actuale din 26.04 | Că o configurație proxy veche 24.04 este automat echivalentă |
| Doar filele inactive/în fundal sunt afectate | Comportamentul de inactivitate per vizualizare CODE plus timeout-uri intermediare de inactivitate | Că eșecurile sesiunii active și ale sesiunii inactive au aceeași cauză |
| WebSocket rămâne deschis, dar salvarea eșuează | Jurnale WOPI/de stocare și cereri de salvare | Că expirarea WebSocket este cauza principală |
Pentru o sesiune de editare CODE care se deconectează după 10 minute repetabile, cea mai eficientă secvență este: confirmarea erorii WebSocket, verificarea regulii de reverse-proxy corespunzătoare, inspectarea fiecărui timeout intermediar, luarea în considerare a modificărilor căii proxy din CODE 26.04, reîncărcarea în siguranță și testarea dincolo de vechea limită de utilizare. Modificați setările de inactivitate CODE numai atunci când comportamentul observat și configurația efectivă indică într-adevăr acest lucru.
Dacă timpul de eroare nu este repetabil sau dacă jurnalele CODE arată în același timp căderi, terminarea proceselor, suprasolicitare a memoriei sau erori WOPI, nu mai tratați problema ca pe un simplu caz de timeout. Aceste simptome necesită un diagnostic diferit.
Aflați cum să importați un fișier PST în Outlook 2010 sau să exportați e-mailuri, contacte, calendar și activități. Urmați meniurile corecte și evitați folderele lipsă sau duplicatele.
Aflați cum să ajustați înălțimea și lățimea grilei în Word 2010, să modificați frecvența liniilor vizibile și să setați spațierea orizontală și verticală subiacentă a grilei de desen.
Recuperează o parolă Outlook PST uitată cu pașii actuali ai Kernel, inclusiv cum să identifici fișierul corect, să faci o copie de rezervă și să verifici limitele instrumentului.
Utilizați programul de completare LiveWeb pentru a plasa un site web pe un diapozitiv PowerPoint, a seta dimensiunea și comportamentul de reîmprospătare și a verifica compatibilitatea înainte de prezentare.
Adăugați sărbători specifice fiecărei țări în noul Outlook, Outlook pe web sau Outlook clasic. Aflați cum să evitați evenimentele duplicate și să verificați dacă lipsesc datele din perioada 2026-2027.
Exportați un tabel Access 2010 în Excel 2010, alegeți dacă doriți să includeți formatarea, salvați pașii de export reutilizabili și verificați problemele comune legate de transferul de date.
Găsiți șabloane Word 2010 încorporate, începeți un document dintr-un fișier .dotx descărcat și salvați un șablon personalizat reutilizabil fără a suprascrie lucrarea.
Utilizați secțiunile PowerPoint 2010 pentru a grupa diapozitive corelate, a redenumi și a rearanja grupuri și a naviga printr-un pachet lung de diapozitive fără a modifica conținutul diapozitivelor.
Folosește Inspectorul de documente din Word pentru a revizui detaliile autorului, comentariile, modificările urmărite, textul ascuns și alte date înainte de partajare și pentru a afla ce poate omite scanarea.
Mutați filele personalizate din panglică și comenzile din bara de instrumente Acces rapid în Office 2010 cu un fișier .exportedUI și protejați setările deja existente pe PC-ul de destinație.
