Restaurați conexiunea WebSocket a Collabora prin proxy

Când Collabora Online raportează că o conexiune socket s-a închis pe neașteptate, verificați mai întâi dacă solicitarea WebSocket a browserului ajunge coolwsdprin proxy-ul invers. Potriviți ruta proxy cu versiunea Collabora, păstrați actualizarea WebSocket și calea URL, apoi testați un document în timp ce urmăriți panoul Rețea al browserului și jurnalele serverului. Dacă problema a început după o actualizare CODE 26.04 în spatele Apache, verificați ProxyPassmai întâi regulile Apache: Notele de lansare Collabora 26.04 menționează o modificare pentru URL-ul WebSocket compact.

Un WebSocket este conexiunea bidirecțională, de lungă durată, pe care Collabora o folosește între browser și serverul său în timp ce un document este deschis. Un proxy invers este serviciul care acceptă solicitarea publică și o transmite către Collabora. Mesajul de eroare indică acea conexiune, dar nu dovedește că proxy-ul este cauza; o gazdă WOPI respinsă, o adresă URL publică incorectă, o nepotrivire TLS sau un backend greșit pot, de asemenea, opri sesiunea.

Înainte de a schimba ceva, identifică-ți traseul

Notați versiunea Collabora sau eticheta imaginii, software-ul proxy, numele public de gazdă Collabora și dacă TLS se termină la proxy sau la Collabora. Verificați numele serviciului și imaginea curentă fără a modifica implementarea:

docker compose ps collabora
docker compose images collabora

Înlocuiți collaboracu numele serviciului din fișierul Compose. Pentru un container care nu este Compose, utilizați docker psși docker inspectpentru a identifica containerul și imaginea. Nu presupuneți că latesteticheta indică în continuare aceeași versiune pe care ați testat-o ​​săptămâna trecută.

1. Vedeți unde se oprește strângerea de mână WebSocket

În browser, deschideți Instrumente pentru dezvoltatori, selectați Rețea , filtrați pentru WS sau WebSocket și încercați din nou să deschideți un document. Adresa URL a solicitării ar trebui utilizată wss://atunci când pagina publică este HTTPS. Selectați solicitarea eșuată și notați starea acesteia, calea URL și anteturile de răspuns. O strângere de mână reușită returnează în mod normal 101 Switching Protocolsși rămâne deschisă în timp ce sesiunea documentului este activă.

• Nu apare nicio solicitare WebSocket: verificați adresa URL Collabora a aplicației de integrare, consola browserului, DNS-ul și orice eroare de redirecționare sau conținut mixt înainte de a edita regulile serverului.
• Cererea returnează 400 sau 404: comparați calea solicitată cu ruta pe care o transmite proxy-ul dvs. și ruta acceptată de versiunea instalată de Collabora. Un cod 400 care coolwsdspune „Cerere invalidă sau necunoscută” poate însemna că solicitarea a ajuns la Collabora cu o cale pe care nu o acceptă.
• Cererea returnează 502 sau 504: verifică dacă proxy-ul poate ajunge la rețeaua Collabora configurată în amonte și dacă adresa și portul indică containerul sau gazda corectă.
• Cererea returnează 101, apoi se închide ulterior: se verifică timeout-urile de inactivitate pentru proxy, load-balancer, firewall și client-network. Un WebSocket are o durată lungă de viață, așa că un intermediar care închide conexiunile inactive prea devreme poate întrerupe o deschidere altfel reușită.

2. Comparați regula proxy cu versiunea dvs. Collabora

Folosește setările actuale de proxy invers din Collabora pentru software-ul proxy și versiunea pe care o rulezi. Verifică dacă ruta WebSocket este gestionată ca WebSocket, dacă proxy-ul redirecționează anteturile de actualizare și dacă păstrează calea și șirul de interogare codificat, în loc să le redirecționeze sau să le rescrie. De asemenea, proxy-ul trebuie să trimită gazda publică și schema în mod consecvent cu numele serverului extern configurat în Collabora și setările de terminare TLS.

Pentru Nginx, examinați locația specifică WebSocket și directivele sale HTTP/1.1, Upgradeși Connectionde redirecționare din exemplul curent al Collabora. Pentru Apache, comparați ProxyPassregula și ordinea cu exemplul curent; nu lipiți o /cool/…/wspotrivire veche neschimbată fără a verifica ce solicită acum versiunea instalată.

Această verificare a versiunii este importantă pentru CODE 26.04. Notele de lansare ale Collabora, publicate pe 8 iunie 2026, descriu un URL WebSocket mai compact și spun că utilizatorii Apache reverse proxy trebuie să se adapteze ProxyPassla acesta. Lucrările ulterioare la versiunea 26.04 au adăugat un comportament de rezervă pentru URL-urile vechi, astfel încât o regulă mai veche ar putea funcționa în continuare pe unele versiuni; raportul WebSocket rezolvat pentru versiunea 26.04 al Collabora documentează această monitorizare. Rezerva nu înlocuiește potrivirea configurației proxy curente cu versiunea instalată. Citiți împreună notele de lansare ale CODE 26.04 și exemplul SDK actualizat.

3. Capturați un eșec și faceți o schimbare specifică

Pornește un flux scurt de jurnal înainte de a reîncerca documentul. --sinceOpțiunea Docker limitează ieșirea inițială, în timp ce --followtransmite linii noi; consultați referința jurnalelor Docker Compose .

docker compose logs --since=2m --follow collabora

Înregistrați ora testului și căutați aceeași solicitare în jurnalele Collabora și proxy. Dacă browserul solicită o cale pe care proxy-ul o direcționează către backend-ul greșit, actualizați doar acea rută WebSocket folosind exemplul de versiune compatibilă al Collabora. Dacă solicitarea ajunge la Collabora, dar gazda, originea sau schema sunt respinse, comparați numele public al gazdei și portul cu numele serverului configurat și anteturile redirecționate. Dacă jurnalul arată în schimb o respingere a gazdei WOPI sau o solicitare eșuată de informații despre fișiere, verificați gazda permisă a serverului de integrare și accesibilitatea acesteia din containerul Collabora; acesta este un pas separat de handshake-ul WebSocket al browserului.

Reîncărcați proxy-ul după validarea configurației sale cu comanda de verificare a sintaxei proprie a proxy-ului respectiv. Evitați modificarea simultană a terminării TLS, a listelor de permisiuni pentru gazde și a rescrierilor URL: modificarea unei cauze per test face ca următorul rezultat să fie interpretabil. Nu dezactivați verificarea TLS și nu permiteți fiecare gazdă WOPI ca scurtătură.

4. Verificați remedierea din browser în document

Reîncercați același document. În Instrumente pentru dezvoltatori, confirmați că solicitarea WebSocket returnează 101 Switching Protocolsși rămâne deschisă. Confirmați că încărcarea documentului se termină, rămâne conectat și acceptă o mică modificare care se salvează cu succes. O stare sănătoasă a conexiunii nu este suficientă dacă accesul la fișierul WOPI sau salvarea eșuează în continuare.

Dacă procesul de handshake eșuează în continuare, comparați calea de solicitare a browserului, linia de acces/eroare proxy și coolwsdintrarea de jurnal corespunzătoare cu aceeași timestamp. Această comparație în trei puncte arată dacă browserul, proxy-ul, ruta Collabora sau gazda WOPI este următorul loc de investigat. Când solicitați ajutor, eliminați token-urile de acces, identificatorii de documente, numele de utilizator și numele de gazdă private atât din detaliile browserului, cât și din jurnalele de browser.