Een leeg Collabora-document traceren naar de falende laag

Begin met te controleren of het lege scherm slechts één bestand of alle bestanden betreft. Bekijk vervolgens de netwerk- en consolevensters van de browser, samen met de Collabora- en opslagplatformlogboeken. Een leeg scherm is een symptoom, geen diagnose: de editor is mogelijk wel geladen, maar de documentverbinding, WOPI-autorisatie of ingesloten resources zijn mislukt.

1. Bepaal of het probleem bij het bestand, de browser of de service ligt.

Open een document waarvan u zeker weet dat het goed werkt in dezelfde toepassing en probeer vervolgens het betreffende bestand in een andere ondersteunde browser of een privévenster. Bewerk het origineel niet tijdens de diagnose. Eén bestand dat niet werkt, wijst op een probleem met de bestandsindeling, de inhoud of de machtigingen; wijdverspreide problemen wijzen op gedeelde services of wijzigingen in het netwerk.

Een privévenster is een test, geen oplossing. Als het daar werkt, schakel dan extensies één voor één uit of wis de sitegegevens voor de betreffende website pas nadat je hebt gecontroleerd of er geen niet-gesynchroniseerde gegevens meer zijn. Het wissen van alle browsergegevens kan gebruikers uitloggen en irrelevante sitegegevens verwijderen.

2. Zoek het verzoek dat mislukte voordat de instellingen werden gewijzigd.

Open in Chrome of Chromium de ontwikkelaarstools ( F12 of Ctrl+Shift+I ), selecteer Netwerk , schakel 'Logboek behouden' in en vernieuw de pagina. Filter op WS (WebSocket) en inspecteer fouten; de netwerkreferentie in de Chrome-ontwikkelaarstools legt de aanvraagfilters en statusdetails uit. Controleer de console op CSP-, certificaat-, mixed-content- of JavaScript-fouten.

Interpreteer het bewijsmateriaal in plaats van een algemene, indirecte methode toe te passen:

• Foutmelding 404 voor editorbestanden of /browser/paden: controleer of de reverse proxy de huidige Collabora-paden correct doorstuurt naar de upstream-server.
• Bij een 502-fout, een time-out of een WebSocket die direct wordt verbroken: controleer de bereikbaarheid van de upstream-server, de proxy-logboeken, de afhandeling van de WebSocket en het aanvraagpad. Een bereikbaar /hosting/discoveryeindpunt bewijst alleen basis HTTP-toegang; het bewijst niet dat de live-verbinding van de editor werkt.
• 403 of "Unauthorized WOPI host" in de logboeken: controleer of de opslaghost die in de WOPI-URL wordt genoemd, overeenkomt met de door Collabora toegestane WOPI-hosts.
• CSP- of certificaatfout: corrigeer de exacte oorsprong van de inbedding of de certificaatketen. Schakel de browserbeveiliging niet uit en versoepel geen Content Security Policy om het scherm te laten laden.

Bij WebSocket-verzoeken is een succesvolle handshake het doel; de weergegeven status is afhankelijk van de HTTP-versie en het proxypad, dus beschouw één verwachte statuswaarde niet als universeel.

3. Stem de oplossing af op de defecte laag

Controleer beide richtingen en het URL-schema.

Volgens de huidige handleiding voor probleemoplossing van Nextcloud moet de browser van de gebruiker beide servers via HTTP(S) kunnen bereiken, moet Nextcloud Collabora kunnen bereiken en moet Collabora Nextcloud kunnen bereiken. Ook wordt er voorgeschreven dat beide services hetzelfde protocol moeten gebruiken. Test het openbare Collabora-adres vanuit een browser op https://office.example.com/hosting/discoveryen https://office.example.com/hosting/capabilities. Gebruik vanaf de Nextcloud-host het volgende:

curl -fsS https://office.example.com/hosting/discovery -o /dev/null

curl -fsS https://office.example.com/hosting/capabilities -o /dev/null

Vervang de voorbeeldhostnaam door uw daadwerkelijke Collabora-URL. Deze controles bevestigen de HTTP-bereikbaarheid, niet of de bewerking is gelukt. Als de server wel verbinding maakt, maar de browser niet, controleer dan de openbare DNS, TLS, firewall of proxy-toegang. De handleiding voor probleemoplossing van Nextcloud Office beschrijft deze verbindingscontroles en raadt aan om de applicatielogboeken te raadplegen.

Repareer proxy-routering alleen wanneer de verzoeken dit vereisen.

Als statische editorbronnen een 404-foutmelding geven of de liveverbinding een 502-foutmelding, vergelijk dan uw reverse-proxy-routes met de officiële proxy-instellingen van Collabora . Zorg ervoor dat de proxy de vereiste Collabora-paden naar de juiste upstream-server stuurt en de WebSocket-verbinding ondersteunt die door de browser wordt gebruikt. Behoud de externe host- en HTTPS-informatie die uw implementatie verwacht. Kopieer geen configuratie voor een andere proxy, URL-prefix of Collabora-release zonder de onderliggende aannames te controleren. Een specifieke Collabora-hostnaam is vaak gemakkelijker te debuggen; padgebaseerde routing vereist een consistente afhandeling van prefixes.

Corrigeer WOPI-toegangslijsten zonder ze open te stellen.

WOPI is het protocol dat Collabora gebruikt om een ​​document op te halen en op te slaan via het opslagplatform. De WOPI-host is meestal de hostnaam van Nextcloud of een andere opslaglocatie, niet de hostnaam van Collabora. Als de logboeken aangeven dat No acceptable WOPI hosts foundde hostnaam van Collabora niet correct is, voeg dan de juiste hostnaam toe aan de WOPI-hostconfiguratie van Collabora of corrigeer deze. Controleer vervolgens of het serveradres van Collabora is opgenomen in de lijst met toegestane WOPI-verzoeken van het opslagplatform. Nextcloud raadt aan om WOPI-verzoeken te beperken tot verwachte IP-adressen van Collabora en Collabora zo te configureren dat het verwachte hosts vertrouwt, zoals beschreven in de Office-configuratiehandleiding .

Het toevoegen van een specifieke vertrouwde host is veiliger dan het uitschakelen van hostvalidatie of het toestaan ​​van brede domeinen. Noteer de huidige instelling, wijzig alleen de relevante vermelding en herstart of herlaad services alleen indien nodig voor uw implementatie. Als u Docker gebruikt, inspecteer dan de recente Collabora-uitvoer met docker logs --since=10m <collabora-container>; vervang de placeholder door de echte containernaam. Voor pakket- of Kubernetes-installaties kunt u in plaats daarvan de service- of podlogs gebruiken.

4. Controleer de editor, niet alleen het gezondheidseindpunt.

Herlaad hetzelfde document. Controleer of de assets correct laden, de liveverbinding open blijft, de inhoud verschijnt en de consolefouten verdwijnen. Test een tweede document en een andere gebruiker als het probleem zich bij die gebruiker voordoet. Sla een onschadelijke testbewerking op en heropen deze om te controleren of het lezen en opslaan correct verloopt.

Als het lege canvas blijft bestaan, maar verzoeken nu wel lukken, controleer dan de serverlogboeken op fouten bij documentconversie of bestandsspecifieke fouten en vergelijk het bestand met een ander bestand met dezelfde indeling. Als het probleem direct na een Collabora-, browser- of proxy-update is ontstaan, test dan een gecontroleerde terugdraaiing of een versie-specifieke proxywijziging tijdens een onderhoudsvenster in plaats van meerdere variabelen tegelijk te wijzigen. Het wissen van de browsercache is alleen nuttig als er aanwijzingen zijn voor verouderde clientgegevens; het kan geblokkeerde routes of geweigerde WOPI-verzoeken niet herstellen.