Remediați ecranul negru sau documentul gol din Collabora Online la încărcare

Începeți prin a verifica conexiunea WebSocket și accesibilitatea celor două servere. Un editor Collabora Online care se deschide pe un ecran negru, o pagină albă sau o pânză goală a documentului eșuează adesea înainte ca interfața cu utilizatorul să termine încărcarea. Dacă problema afectează toate fișierele, inspectați mai întâi ruta browser-Collabora, proxy-ul invers și conexiunea Nextcloud-Collabora. Dacă eșuează un singur fișier, testați un alt document și verificați permisiunile și formatul acelui fișier înainte de a modifica setările serverului.

Folosește această ordine: verifică browserul, testează punctele finale de descoperire Collabora, citește jurnalele de integrare și de server, apoi corectează doar setarea proxy sau WOPI la care indică dovezile. O resetare a memoriei cache a browserului poate ajuta cu resursele învechite, dar nu va repara un WebSocket defect sau o gazdă WOPI inaccesibilă. Imaginile interfeței de mai jos sunt exemple schematice; etichetele exacte și căile de solicitare variază în funcție de browser, platforma cloud, proxy și versiunea Collabora.

Diagnostic rapid prin simptom

1. Află dacă problema este la nivelul browserului sau la nivelul serverului

Mai întâi, deschideți un al doilea document despre care știți că poate fi citit și încercați același fișier într-un alt browser sau într-o fereastră privată. Dacă un document eșuează în timp ce altele se deschid, verificați dacă utilizatorul îl poate descărca sau previzualiza în continuare în platforma de fișiere. Un fișier deteriorat, un format neacceptat, o partajare expirată sau o permisiune lipsă pot părea o problemă a editorului, dar schimbarea proxy-ului invers nu va rezolva o problemă specifică fișierului.

Pentru o verificare din browser, deschideți Instrumente pentru dezvoltatori înainte de a reîncărca documentul gol. În browserele bazate pe Chromium, apăsați pe F12sau pe Ctrl+Shift+I, selectați Rețea , activați Păstrare jurnal și reîncărcați. Filtrați după ws, cool, sau browser. De asemenea, verificați fila Consolă pentru scripturi blocate, avertismente privind certificatele sau erori de politică de securitate a conținutului.

O solicitare eșuată sub /cool/…/ws[numele fișierului] indică o problemă de handshake WebSocket sau de proxy. Un [ 502numele fișierului] înseamnă de obicei că proxy-ul nu a putut obține un răspuns utilizabil din amonte; un [ numele fișierului 404] poate însemna că ruta nu este rutată; iar un [ 403numele fișierului] poate indica o gazdă sau o regulă de acces respinsă. Aceste coduri de stare restrâng căutarea, dar jurnalele proxy și Collabora corespunzătoare sunt necesare pentru a identifica cauza exactă. Dacă solicitările eșuate sunt fișiere JavaScript sau CSS sub [numele fișierului] /browser, verificați dacă proxy-ul redirecționează aceste resurse statice către serviciul Collabora.

Dacă solicitările de rețea reușesc într-o fereastră privată, dezactivați temporar extensiile de browser care blochează scripturile sau solicitările între site-uri, apoi ștergeți datele site-ului doar pentru numele de gazdă din cloud și Collabora. Testați din nou înainte de a modifica configurația serverului. Nu faceți din ștergerea memoriei cache soluția principală atunci când aceeași solicitare eșuează în continuare în fila Rețea.

2. Confirmați adresa URL Collabora și punctele finale de descoperire

Pentru o integrare Nextcloud, verificați adresa URL a serverului Collabora Online din setările de administrare Office. Folosiți adresa URL publică pe care browserele o pot accesa, cu numele de gazdă și portul corecte. Ghidul actual Nextcloud precizează că serviciile Collabora și Nextcloud ar trebui să utilizeze același protocol; se recomandă HTTPS. O nepotrivire, cum ar fi configurarea unui serviciu cu acesta, http://în timp ce celălalt este accesat prin acesta, https://poate cauza blocarea solicitărilor de conținut mixt sau apeluri inverse eșuate.

Dintr-un browser de pe clientul afectat, deschideți https://office.example.com/hosting/discoveryși https://office.example.com/hosting/capabilities, înlocuind numele de gazdă exemplu cu al dvs. Punctul final de descoperire ar trebui să returneze XML care să descrie acțiunile acceptate ale documentului; capacitățile ar trebui să returneze un răspuns de la serverul Collabora. O eroare de browser, o eroare de pagină de conectare, o eroare 404 cu proxy sau o eroare de gateway înseamnă că ruta publică nu ajunge la punctul final Collabora așteptat.

Apoi testați de pe gazda Nextcloud, deoarece testul browserului în sine nu dovedește că serverele pot comunica între ele:

curl -sS -o /dev/null -w "%{http_code}\n" https://office.example.com/hosting/discovery
curl -sS -o /dev/null -w "%{http_code}\n" https://office.example.com/hosting/capabilities

Înlocuiți office.example.comcu numele de gazdă Collabora configurat. Un răspuns HTTP reușit este o verificare utilă a accesibilității, în timp ce o expirare, o eroare DNS, o eroare TLS sau un răspuns 5xx trebuie rezolvat la nivelul de rețea, certificat, DNS sau proxy corespunzător. Pentru instalările în care serverul Collabora trebuie să apeleze înapoi la Nextcloud, testați și adresa URL de stare Nextcloud de la gazda Collabora:

curl -fsS https://cloud.example.com/status.php

Folosește numele tău real de gazdă Nextcloud. Instalările CODE încorporate pot utiliza o adresă URL proxy internă în loc de un nume de gazdă public Collabora separat, așadar urmează instrucțiunile pentru implementarea respectivă, în loc să aplici exemplul de server independent la propriu.

3. Verificați ruta WebSocket și proxy-ul invers

Collabora deservește resursele browserului și sesiunile de documente prin mai multe rute. Un proxy invers trebuie să redirecționeze căile așteptate de versiunea instalată, inclusiv resursele editorului, punctele finale de descoperire și capabilități și ruta WebSocket a documentului. Documentația actuală Collabora folosește /cool/…/ws; implementările mai vechi pot avea în continuare configurație pentru /loolcăile moștenite. Documentația de migrare Nextcloud menționează în mod specific modificările istorice ale căilor de la loleafletla browserla și de la loolla la cool.

În configurația proxy-ului, verificați dacă locația WebSocket se potrivește înaintea regulilor catch-all mai largi, dacă proxy-ul transmite anteturile de actualizare necesare pentru software-ul proxy și dacă upstream-ul indică serviciul și portul Collabora reale. De asemenea, confirmați că proxy-ul păstrează informațiile așteptate despre gazdă și schemă și permite conexiunilor de lungă durată să rămână deschise. Dacă TLS se termină la proxy, asigurați-vă că setările de terminare SSL ale Collabora corespund acelui design.

Extrasul de cod scurt de mai sus arată tipul de antete WebSocket de care ar putea avea nevoie un proxy în stil Nginx; nu este o configurație proxy completă. Nu o lipiți singură și nu combinați directive din versiuni diferite. Comparați configurația completă cu ghidul oficial Collabora pentru reverse-proxy pentru proxy-ul și versiunea Collabora pe care o rulați. După editarea unui fișier proxy, validați sintaxa acestuia cu comanda configuration-test a serverului respectiv înainte de a-l reîncărca.

4. Verificați validarea gazdei WOPI și jurnalele serverului

Collabora utilizează WOPI, Interfața pentru Platformă Deschisă pentru Aplicații Web, pentru a solicita un document de la un serviciu de stocare conectat, cum ar fi Nextcloud. Serverul Collabora trebuie să accepte gazda WOPI, iar serverul de stocare trebuie să poată accesa serviciul Collabora. În Nextcloud, verificați setările Office și lista de permisiuni pentru solicitările WOPI. Adăugați doar adresa serverului Collabora așteptată; nu dezactivați validarea gazdei și nu permiteți gazdelor arbitrare să facă să dispară un ecran gol.

Citiți jurnalele în momentul în care reproduceți problema. Pentru o implementare Docker, ghidul de depanare Nextcloud documentează verificarea jurnalului containerului; utilizați numele sau ID-ul real al containerului:

docker logs --tail 100 collabora

Pentru o instalare bazată pe pachete, numele serviciilor și destinațiile jurnalelor depind de sistemul de operare și de versiunea pachetului. O verificare systemd obișnuită este:

sudo journalctl -u coolwsd -n 100 --no-pager

Căutați o marcă temporală potrivită și erori despre o gazdă WOPI neautorizată, CheckFileInfoo solicitare eșuată, o verificare TLS, un spațiu de stocare indisponibil sau un WebSocket eșuat. Un mesaj care indică faptul că nicio gazdă WOPI acceptabilă nu corespunde înseamnă de obicei că numele de gazdă al spațiului de stocare configurat pentru integrare nu corespunde cu gazda permisă de Collabora. Corectați numele de gazdă sau intrarea din lista de permise în loc să adăugați domenii fără legătură.

De asemenea, verificați jurnalul platformei de fișiere pentru aceeași oră de solicitare. Dacă Collabora nu poate ajunge la Nextcloud, verificați rezoluția DNS de la gazda Collabora, regulile firewall-ului, ruta publică sau internă și dacă serviciul încearcă să se conecteze la sine printr-un nume de gazdă care se rezolvă diferit în interiorul rețelei containerelor. Manualul de depanare Nextcloud recomandă verificarea conectivității în ambele direcții și utilizarea jurnalelor serverului pentru a identifica partea care a eșuat.

5. Testați din nou documentul și faceți doar modificări specifice

După remedierea unei rute, a unei adrese URL, a unui certificat sau a unei intrări în lista de permise, reîncărcați proxy-ul și serviciile afectate numai atunci când implementarea o necesită. Redeschideți Instrumentele pentru dezvoltatori, reîncărcați fișierul și confirmați că solicitarea anterioară eșuată s-a finalizat. Documentul ar trebui să redea paginile sau foile, să accepte o mică modificare și să salveze modificarea respectivă cu succes. O pagină goală care dispare, dar nu se poate salva, indică în continuare o conexiune WOPI sau de stocare nerezolvată.

• Descoperirea funcționează, dar WebSocket eșuează: concentrarea se face pe ruta WebSocket a proxy-ului, gestionarea actualizării, adresa upstream și timeout-ul conexiunii.
• Browserul poate accesa Collabora, dar Nextcloud nu poate: testa DNS, firewall, încredere TLS și rutare de la gazda Nextcloud.
• Collabora raportează o gazdă WOPI neautorizată: comparați numele exact al gazdei de stocare din setările de integrare cu lista de gazde WOPI permise.
• Doar instalările vechi eșuează după o actualizare: comparați căile proxy cu documentația versiunii instalate și actualizați rutele /loolsau /loleafletversiunile vechi, acolo unde este necesar.
• Doar un fișier eșuează după ce verificările de conectivitate trec cu succes: verificați accesul la fișier și testați o copie sau un alt format acceptat înainte de a modifica setările globale.

Cum arată o reparație reușită

Un rezultat fiabil înseamnă mai mult decât o simplă bară de instrumente a editorului. Conținutul documentului este redat, nu există solicitări persistente eșuate ale editorului sau WebSocket, iar o editare de test inofensivă este salvată și rămâne valabilă după o reîmprospătare. Dacă problema persistă, păstrați un extras scurt și redactat din rețeaua/consola browserului și liniile de jurnal Nextcloud, proxy și Collabora corespunzătoare. Jurnalele pot conține nume de gazdă, nume de utilizator, identificatori de fișiere sau token-uri, așadar eliminați valorile sensibile înainte de a le partaja.

Pentru pașii specifici implementării actuale, consultați ghidul de depanare Nextcloud Office , referința de configurare Nextcloud Office și notele de migrare Collabora . Verificările exacte pentru ownCloud, o altă gazdă WOPI, un serviciu CODE încorporat sau o platformă de containere pot diferi de exemplele Nextcloud.